One of the central reasons that companies hire a Product Manager is to make sure that they have someone who sets and drives the direction of the product. In a world where there is never enough time to implement all the ideas that come along for great new features, you need to choose the right ones to put your development dollars into, or there’s always that potential that your product will lose its competitive edge.
I believe that when defining a Product Manager’s role in setting the product direction, most companies mistakenly consider the focus of that role to be choosing capabilities, when in fact the best contribution of a Product Manager is to provide a structure and mechanism for selecting new features. It’s the team as a whole that chooses the features, with the Product Manager ensuring that it all happens on schedule, consistently, and completely. And happens again and again.
Setting the product direction may sound like a highly strategic and conceptual activity, with no clear standards in the industry, similar to the Product Road Map, whose definition is “all over the map.” If you want it to bear results, however, you need to turn it into a tactical and somewhat mechanical effort.
Read on for more discussion of how to construct the mechanism for setting the product direction at your company.
Grist For the Mill
The first thing that you as Product Manager need to do is ensure the flow of raw materials into your software factory. In this case the raw materials are ideas for new functionality and improvements.
Realize that these ideas are, well, raw. They don’t have to be anything other than that when they reach your desk. You want to encourage a solid flow of incoming materials from which to work with. This is the equivalent of brainstorming. Like all brainstorming ideas, only a small number will wind up being appreciated as very good ideas that are worth following through with.
Make sure that your entire organization knows that Product Management is where all suggestions go for enhancements. Encourage input constantly. Thank people every time they make a contribution, and provide some explanation of what is going to happen to their ideas. Specifically, their idea will be noted, analyzed, and discussed, and they will be able to find it on the list of requirements.
It’s important to make it clear that while you gather all ideas with no questions asked, only a relatively small number of those ideas wind up being worked on in a given release. You have limited development resources.
Funnel
As Product Manager, you are nothing if not a giant funnel for the ideas that flow in for new capabilities. This is not the glitzy, strategic part of the job, it’s the mundane, tactical part.
Take the ideas that cross your desk in raw format and record them consistently. Make sure you note the little things that people who give you the ideas are going to care about, like the date, who submitted it, and any background information associated with the suggestion (for example: “This came up during a demo when we tried to navigate through the diagram on the fly, and the audience had lots of questions about the Legend.”)
Your job as funnel is to collect all suggestions, sort out duplicates, and organize the list into meaningful categories. By defining which categories to use, you influence future discussions on the product direction by promoting or demoting specific types of features. For example, creating a category for Partners, User Interface, or Reports, automatically elevates those aspects of your product’s functionality.
People throughout the company frequently focus on the collection and tracking of each suggestion as a prime candidate for automation. Do you want to automate this process? How would you prefer to do it? At its simplest, this can be done by collecting hundreds of pieces of paper into a file, then typing them up in a spreadsheet.
If you use the “hundred pieces of paper method” as I have, it’s extremely helpful to separate out each idea onto its own sheet of paper. This makes sorting, deduplicating, consolidating, and organizing the information so much easier when you go to put it in electronic form.
The automated solution is another way to go. In my experience, automating the system isn’t the problem. The problem is having someone to intelligently operate it. Chances are that automating the system will make more work for Product Management. But it will also make it easier for teammates throughout the organization to enter their suggestions and track their progress.
Gears and Levers
Once ideas have been funneled into your big requirements mechanism, it’s time to work the levers and turn the gears. Here’s one of the points where a Product Manager has the biggest hand in the product outcome.
In addition to using categories as explained above to affect how the team conceives of the various parts of your product and their relative importance, you as Product Manager have many levers you can apply to structure incoming requirements. Organizing requirements by the type of benefit they provide – sales appeal, architecture improvements, cost cutting, feature leadership, and partner appeal, to name a few – focuses any product direction discussions into those areas that you consider vital to the product’s future success.
Your input as Product Manager, and how you balance the benefits, gives you significant leverage here.
The Product Manager moves ideas through the gearworks by ensuring that they are channeled to the right individuals and groups for review and clarification. Your job is to make sure that the right requirements come out the other end of the machinery, packaged and ready for handoff to Development.
Greasing the Skids
It’s easy for requirements to get gummed up in the works. The whole mechanism is a sensitive one, and can easily grind to a halt. Future release dates get delayed, and suddenly nobody’s sure when the requirements are supposed to be ready, and they let the process stop. Marketing and Sales managers don’t take the time to understand the significance of architectural and technical requirements. Development managers don’t take the time to understand the business benefits of features that sound vague and silly to them. Each person has his or her own agenda of items to promote, while ignoring the bigger picture. And most of all, everybody is busy and it’s nobody’s job to move the requirements through to definition, analysis, prioritizing, and planning.
That is, it’s nobody’s job but the Product Manager’s. And the way the Product Manager greases the skids is through very mundane tactics: setting the calendar of meetings and communicating all updates to it, sending reminders, scheduling and facilitating meetings, and pushing for next steps at each and every turn. This also calls upon softer, strategic skills such as identifying and pointing out gaps and needs, forcing the discussion, and getting agreement.
Inspiration and Perspiration
Everyone sees the inspiration involved in setting the product direction. It’s the Product Manager’s role to sweat through all the perspiration involved, to take over the mechanical and tactical aspects.
In most situations, whether you are in a startup run by a visionary founder or a larger organization with influential leaders, there’s a certain fear of relinquishing control to the Product Manager to set the product direction. Somehow these leaders worry that nobody has a feel for the market like they do. They may very well be right.
That’s when it’s helpful to emphasize that the Product Manager isn’t there to supplant the visionaries with their inspiration. Rather, you are there to make sure that the many good ideas get all the way across the finish line and into the product.
In time, as Product Manager, you will gain credibility and a great perspective with the customer and prospect base. This will help you join the team in providing visionary ideas. But until then, there’s tremendous value in simply being the one who makes sure that requirements get completed properly (or done at all) and supplied to Development on time.
Putting It Through the Grinder
At some point in the runup to every release cycle comes the time to put requirements through the grinder. A Product Manager can look at suggestions with a cold, analytical eye. It’s important to run all the requirements through an analysis that scrutinizes and compares them along several dimensions that are meaningful to your business and to the product.
One such dimension is the competitive one. All the major proposed requirements should be analyzed to determine what they add to your product relative to a bevy of top competitors. It should be clear which competitors are targeted by each requirement. And the Product Manager needs to make sure that an important competitor isn’t missing from the list of those who will be put at a disadvantage by the new capability.
Another dimension is architectural. How in line or out of line with your architectural choices and direction is each feature?
Two more dimensions are overall value to the product and level of effort to develop.
Yet another dimension is market readiness. Is the market going to be ready for the feature? Will it appreciate and be able to implement it? How much of an uphill battle will you have to sell it?
Precision Tooled and Polished
The result of all this organizing, sorting, categorizing, analysis, and prioritizing is a set of requirements that are polished and complete. The management team can feel confident that they know what has been chosen, why the choices were made, and that they agree with the choices. The Marketing, Sales, and Development teams have a level of confidence in the value and balance of the upcoming improvements to the product.
Packaged and Crated
Once the requirements are complete, they can be handed to Development as a package to begin detailed estimating, planning and design. The whole package focuses on what Development is being asked to do. Development’s job is to determine how to do that.
But remember that requirements can’t be tossed over the wall. Before the final package is produced, certain members of Development have gotten involved in discussing options and estimating level of effort. The process to produce the requirements involves some loops and repetitions through the machining and polishing process. It may turn out that Development has a suggestion to produce a simpler version of a proposed feature in a way that takes one fifth of the time. So there’s back-and-forth with developers before the final package is boxed up and handed over.
Next On the Assembly Line
Finally, there’s the most important part of the requirements mechanism: resetting the process to start all over for the next release. As soon as Development gets to work on one set of requirements, a Product Manager begins turning the organization’s attention to the next release, soliciting suggestions and encouraging participation. This increases your product momentum and gets the requirements through that much more smoothly next time.
— Jacques Murphy, Product Management Challenges
ProductManagementChallenges.com