As a product manager, one of the most consistent questions I receive from either peer product managers or executives is, “How do we decide what to build and bring to market next?”
This challenge is universal, affecting companies of all sizes and at all stages of growth. Whether you’re a large company with multiple products in the market, most of which are doing reasonably well, or a startup that launched a product-led growth initiative with promising initial traction, common themes emerge when faced with this question. Typically, two key challenges are present: growth has likely slowed, prompting a need for improvement, and there’s often no established process for deciding on the product backlog or roadmap.
In my experience, a combination of the following factors is typically true:
- Strong Personality Influence: A dominant figure within the company, such as a charismatic founder with the original product idea, a strong technologist, or a visionary leader, has been making most decisions. The prioritization question arises when either the ideas from this leader cease or fail to achieve expected growth.
- Customer-Driven Direction: A major customer has heavily influenced product direction, shaping the roadmap for a considerable period. Once new clients come into the picture, there’s a lack of a robust process for prioritizing ideas or requests, leading to a product with a market size limited to the initial influential customer.
- Design by Committee: Decision-making is spread across a group of senior leaders who determine the roadmap based on their opinions. This approach often lacks a structured process, resulting in priorities influenced by individual perceptions rather than a well-defined strategy, leading to potential misalignment with the company’s growth objectives.
Given the abundance of ideas, far exceeding the team’s capacity to bring them to market, a process is attempted but is frequently undermined by the aforementioned factors, leading many to bypass it. Most companies have some form of a decision-making process, but it may vary across teams or divisions, be costly, burdensome, or so loose that it’s easily avoided.
So, how do you decide? The best solution I’ve found involves a combination of strategies. First, establish a relatively simple process for submitting and evaluating product ideas that the product team can manage. This process should cover internal and external sources, encompassing both big ideas (e.g., entering new markets, expanding an existing market vertically or horizontally with significant features) and small ideas. You can find various models for this process here.
If your company is new to this, I recommend adopting an Effort vs. Value method based on scoring from 1 to 5. The process should surface high-value items (the 5s) with low effort (the 1s). Given the likelihood of having more ideas than your organization can manage, the process should embrace a fail-fast mentality and be as cost-efficient as possible.
With this base prioritization process in place, create a cross-functional team (a product council) to review larger ideas during regular strategic planning cycles (quarterly or bi-annually). This group, often comprised of executive stakeholders, aims to eliminate unviable or low-value, high-cost items early in the process. All decisions made during this process should be documented and published for visibility.
Next, establish a stage-gate process to review bigger ideas with rough timeboxes, including at least two stages:
- Initial Ideation: The idea is brought to the product team, and a discussion along with a paper napkin exercise occurs to determine value and cost. The time allocated varies based on the complexity of the idea. Small ideas can generally be fleshed out in 15 minutes, while larger ones may take a week of discussions and research.
- Expanded Research: This stage involves conversations with engineering, impacted departments/teams, and customer interviews to refine effort vs. value estimates. I typically timebox each round of research to 1-2 weeks.
Agile companies may choose to proceed with two rounds and then authorize light experimentation (low-cost, minimum viable experimentation) before committing to broader development efforts. Ideas showing promise continue, while those that don’t are canceled. Less agile companies, or those dealing with substantial ideas, may iterate through the second phase multiple times over several weeks before committing to an item or a complete roadmap.
The final component is governance and a method for deviating from the process. Tiebreakers may be necessary, typically handled by the CEO or founder, but the process should be clear. Flexibility is crucial, allowing for decisions based on immediate needs or the introduction of new ideas by the founder.
Finally, provide flexibility for both your product teams (product managers, product owners, designers, and engineers) and extended product teams (key stakeholders in customer success/operations, sales, marketing, and business development) to allocate time for small to medium-sized items a few times a year. Allow the product team to decide on smaller matters with minimal outside involvement, empowering them to respond to direct customer requests without extensive research or documentation.
This is a concise overview of how I typically recommend structuring the initial product prioritization process when the existing process falls short of achieving goals. I can delve into specific aspects such as tracking ideas, documentation, conducting voting meetings, and other tasks that product managers need to undertake. If you’re interested in further insights, drop a comment or message me, and I’d be happy to explore these topics (after a lightweight effort vs. value paper napkin exercise).