Just because it’s a great idea doesn’t mean it will automatically turn into a great product. Not all ideas are all that great to begin with. With these truisms in mind, product management plays an integral role in bringing order to chaos and, eventually, products to market.
There is no universal playbook for the product management process. However, the basic order of operations for most organizations is fairly similar. It’s a lengthy path, with stakeholder participation throughout and contributions from multiple departments. But the product management process shepherds things along.
This piece will define the seven main stages of the product management process. And while the names and details may vary from one workplace to the next, nearly every product follows a similar journey.
Coming up with new ideas isn’t particularly difficult. Inspiration can strike anyone at any moment. Plus there are plenty of mechanisms for teasing them out, from brainstorming sessions to customer interviews to keeping tabs on your competitors.
But since you can’t implement them all, product management must separate the wheat from the chaff and figure out which ones move to the front of the queue. To sort through them all, product management must manage idea generation and organization.
Ideas come up on an ongoing basis via many channels. It’s essential to capture and manage them centrally, preferably with some useful organization and tagging for when you eventually evaluate them. In many organizations, this means they’ll end up in the product backlog, which is periodically refined to clean out what’s become irrelevant or redundant while validating the “keepers” that remain viable for future consideration.
Maintaining a transparent system for collecting, aggregating, and storing these ideas falls on product management. Because the team hasn’t yet passed judgment on these possible features and enhancements, they must keep those who offer up suggestions—be they internal stakeholders, customers, or even board members and investors—in the loop regarding the status of their ideas.
Education and visibility into the process are key to maintaining strong relationships and open channels. It helps stakeholders realize their idea isn’t the only one in the running for possible implementation.
Once you capture and categorize an idea, it’s time to figure out some of the details. This will accomplish a few things that will prove vital further along in the product management process.
Product specifications should be short and not overly technical documents that answer three important questions:
- What are we building, and why?
- What should this new product achieve?
- How do we measure success?
Teams should answer these questions collaboratively with input from a range of stakeholders to consider all angles and ensure that there’s agreement going forward on what exactly everyone has in mind. By removing as many vagaries as possible, it will be clear what’s under consideration when you prioritize and implement things later on.
Exactly how much level of detail should be included in these product specs depends on the product development style employed in your organization. This can range from waterfall environments where engineering expects down-to-the-pixel levels of detail to Agile workplaces where figuring out the implementation details is the responsibility of the development team.
Another goal of fleshing out the product requirements during this stage is to get a sense of just how big of an undertaking a given item or project might be. With a ballpark level of effort estimate, product management can plug things into the product roadmap with a realistic idea of what’s achievable during a given timeframe.
It might surprise you to see roadmapping fall earlier in the product management process than prioritization. How can you decide which features and enhancements to put on there when you haven’t prioritized them yet?
By roadmapping before the prioritization stage, product management can steer the conversation away from Feature X versus Feature Y debates and shift it to the higher-level goals, objectives, and themes that advance the product vision. This breaks the cycle of concentrating on individual enhancements and emphasizes meaningful outcomes that influence North Star metrics, KPIs, and strategic goals.
Selecting which high-level themes should be worked on during different time periods also lets the product team decide exactly which specific items will have the biggest impact and best ROI closer to the time of actual implementation, versus getting locked into very specific commitments months or even years in advance.
There’s still a coherent strategy and stakeholders can see which strategic areas are being addressed without making promises the company can’t or no longer wants to keep. It also provides some flexibility as you gather more information and make more technological advances.
Next, it’s time to decide which of those backlog items are worthy of making the cut and advances out of the idea stage. This is where one of the many available prioritization frameworks comes in handy.
Whether it’s using the fan-favorite product tree or a scoring model like RICE, this exercise determines which items should be worked on first, based on how they’ll impact the product’s vision, strategy, and KPIs. Any prioritization exercise should always include broad stakeholder participation, taking multiple viewpoints and opinions into account.
Regardless of the technique used, prioritization must balance the urgent, burning issues stakeholders are complaining about or clamoring for with the must-have items critical to executing against the medium-to-long term strategy for the product and company.
Unfortunately, not everyone always gets what they want. These decisions will be the most scrutinized part of the process (and your job as a product manager). But to do the right thing for the product, product managers will often have to say “no” to customers, salespeople, and even executives.
With a roadmap and set of prioritized items, it’s time to start building and shipping. This is often where product management takes a step back, serving in a more advisory or consulting role as engineers and project managers take the reigns.
How products get delivered can vary quite a bit from one organization to the next. At one extreme there’s the waterfall model, with tightly scripted, detailed project plans and releases are few and far between, only shipping when large chunks of functionality are completed and tested.
Agile organizations break their work up into much smaller chunks and complete as much as possible in sprints. This means there are iterative improvements to the product being made more frequently. However, it also makes things a little more unpredictable in terms of knowing exactly when a specific item will ship.
Some companies take this even further with continuous delivery, where new functionality, bug fixes, and other changes ship as soon as they’re completed and tested. In practice, this might result in multiple releases per day in some cases.
While some loyal fans of these various delivery models are ardent evangelists, there are good cases for any of them depending on the nature of the product and the team building it. Regardless of the particular delivery approach, product management’s role is to ensure what’s being built meets the requirements and expectations of the market and stakeholders. They must be available to define, clarify, and validate that the work being done will achieve the intended goals of the project.
Analytics and experiments
Once the product is released into the wild (or even as a controlled beta), product analytics offer a new opportunity for learning thanks to the flood of user data available when products are properly instrumented to capture it. Connections, causations, and correlations can all be deduced using this information, which can be incredibly illuminating.
Product management can do a few important things at this stage. First, they can see which behaviors drive key metrics the company values. For example, if conversion is paramount, they can see what most users do before they buy. If adoption and frequent usage is the goal, they can also look for what those cohorts have in common.
Based on this intelligence, the team can then prioritize initiatives lowering the barriers. They can then nudge users toward completing those tasks that turn them from dabblers to loyalists, be that changing the software and user experience itself or via education, onboarding, and in-app messaging.
Identifying the traits of successful/profitable customers can also inform which niches to invest in from both a product functionality perspective as well as on the sales and marketing side of the house. Product teams can build out or hone their target personas with this information to go after like-minded prospects.
Product analytics also enables product teams to conduct experiments. Teams can test all sorts of scenarios on different segments of the user base to measure their efficacy. The results then inform the roadmap and optimize the current user experience. With the right data available for analysis and a team to make it all happen, a culture of trials and ongoing learning can take hold and improve the product.
A shipped product also (hopefully) means a cadre of customers to collect and solicit feedback from. This is both exciting and terrifying. Helpful suggestions and insights are often accompanied by complaints, outlandish requests, and realizations that the product has fallen short of customer expectations.
Beyond swallowing your pride and remaining open to outside viewpoints, product management must institute a well-defined process for capturing and organizing this feedback that closes the loop with customers who take the time to offer their opinions. This brings things full circle with the start of this process—idea management—and that’s no coincidence. After “version 1.0” product management will get as many ideas from customers as anywhere else.
There are many methods for gathering this feedback. Some are more passive, such as offering in-app opportunities to provide suggestions from customer service and sales team interactions. But product management can—and should—be proactive about soliciting this input as well.
Customer feedback opportunities include surveys, customer advisory boards, focus groups, customer interviews, and usability tests. But there are plenty of other less-obvious methods for learning what’s on customers’ minds.
And don’t forget about ex-customer feedback. Analyzing what’s causing users to abandon the product might even be more useful than finding out why people stick around.
Your mileage may vary
The product management process laid out above may be the ideal. However, there are plenty of good reasons to wander off this particular proscribed path. You might need to prioritize things before you feel confident in your ability to roadmap or spend the time creating product specs. Or perhaps the team is confident to move forward on delivering finished products without some initial experimentation.
But even when teams complete them in a different order, each stage must be given its due. They’re all essential ingredients to bringing products to market that both delight customers and adhere to the product strategy.