“Everybody’s talking at me / I can’t hear a word they're sayin’”

-- Harry Nilsson

For NASA space flight missions, from the Mercury program of the 60s to today, the Capsule Communicator (CAPCOM) is generally the only person who communicates directly with a manned space crew. During much of the U.S. manned space program, NASA felt it was important for all communication with the astronauts in space to pass through a single individual in the Mission Control Center. That role was designated the Capsule Communicator (CAPCOM) and was filled by another astronaut, often one of the backup crewmembers. If you watched the movie “Apollo 13,” you saw the importance for clear, consistent communication from the ground to the flight. It’s important to communicate with one voice.

The agile product manager is CAPCOM of your product, speaking with one voice to those on the product team.

Maybe the role is called product owner or customer or market representative or product manager. It’s often referred to as “president of the product.” Many managers assume this role has something to do with power and control; instead it has more to do with focus. What is most important? Which items are the highest priorities?

How often does this happen? A development team, busily working on a set of features, is interrupted with new priorities. Kevin, the world’s worst sales person, needs a new feature to close a deal. The VP of Marketing says that we need to change the splash screen to incorporate our new logo and color schema. The president says, “God spoke to me in a dream.” Each feels that their idea is most important. But look at it from the development team’s point of view: What do you want me to work on? Which has the highest priority? Which comes first?

Let us speak with one voice to the product team

My developers used to employ a concept that we called “requirements aging.” They wouldn’t start on anything until it had remained unchanged for a month. And sure enough, each and every Monday, Satan, our VP of Development, would come in and say, “Stop what you’re working on. I’m getting new requirements.” So we’d pause our game of Warcraft for a few minutes until he left the room.

We have more on our plates than can be done so we must prioritize.

Maybe you’ve done this: you’ve grouped your requirements into must-have and nice-to-have, or mandatory and optional. And your lead developer says, “Good. Thanks for organizing these. We can eliminate the optional requirements. Which of the mandatory do you really want?”

The agile product manager maintains a backlog of all the desired items in priority order. One popular development planning method called Scrum uses the concept of a backlog. Make a list of everything that you want to work on, prioritize the list, and then start working from the top until you run out of time or resources. Every new idea gets assigned a priority and is inserted into the list in order. Do this for each feature. Is this more or less important than this existing item? Than this one? And this one?

The agile product manager also serves as a barrier, protecting the team from the rest of the company. Developers genuinely want to help the sales effort so when Kevin, the world’s worst sales person, requests a feature, the developers try to accommodate the request. But if every developer listened to every sales person, we’d never get a product into the market! And if we did, would it be any more than a hodge-podge of disconnected features?

The solution is draconian but simple: every request must come to the agile product manager. And any request that goes elsewhere is greeted with, “I don’t know. Ask the product manager.”

And not just features but dates too. Kevin, the world’s worst sales person, asked the agile product manager when a feature would be delivered and was told, “Next year.” Kevin then asked the lead developer who said, “I’ll be done next month.” Kevin, preferring the second answer, told the customer the feature would be available next month. But Kevin doesn’t know—and doesn’t appear to care—that the code must be tested and documented. And that the feature might be delayed if the priorities change yet again.

The agile product manager gives permission to all on the team: you do not have to talk to sales people. Ever. Always say, “I don’t know. Ask the product manager.”

A product manager was presenting a business plan to the executive team. She was asked what percentage of development resource was allocated to the hosted solution versus the packaged version. She replied that 75% was focused on the hosted solution—and the fight began. Some VPs agreed with the product manager; others thought she was wrong. Which matters most: our hosted solution or traditional packaged software? Which has the higher priority? And how does one decide?

When the executive team is unclear, they send mixed signals to the company. Mixed signals result in confusion and frustration. Hours are wasted in meetings with pre-meetings to decide what we’re going to say and post-meetings to complain about what was said. Here’s an easy test: look at how many people are copied on emails. Employees react to confusion by sending copies of emails to everyone.

Remember when you learned to drive a car? You were coming up on an intersection and your dad said, “Speed up to beat the yellow light” and your mom said, “Stop! The light is going to turn red.” Who do you listen to?

The product team wants to deliver the best product to the market. What features make the best product? Which is our top priority? If the execs don’t know, how can the product manager make the right decision? In the end, the agile product manager knows—or guesses—the company strategy, and prioritizes accordingly.

The agile product manager maintains a backlog of all the desired items in priority order. The agile product manager also serves as a barrier, protecting the team from the rest of the company. The agile product manager is CAPCOM of your product, speaking with one voice to those on the product team.

Steve Johnson is an expert in technology product management. He works for Pragmatic Marketing as an instructor for the top-rated seminars Practical Product Management, Requirements That Work and Pragmatic Roadmapping. Steve is a frequent presenter at technology marketing forums throughout the United States and Europe, author of many articles on technology product management, and the writer of the Product Marketing blog.