Roadmap Rodeo

Product Management Principles

Product management methodology

In the realms of product management there's a growing recognition of the limitations within current methodologies. Many frameworks overlook a critical aspect of success—product management effectiveness itself. While companies rightly focus on their products, they often fail to acknowledge that product management is a distinct discipline, akin to engineering or security. Consequently, just as in other disciplines, exemplary product management can lead to great success, while poor management can result in failure, drowned in irrelevant data and a cluttered backlog.

Our approach draws inspiration from various successful methodologies such as Lean Startup and Agile, openly embracing their naming conventions, techniques, and terms. However, we go a step further by introducing a new dimension: the quality of product management itself and how to continually enhance it. We firmly believe in the transformative potential of data-driven insights, but we understand that simply having data is not enough. It's about effectively leveraging this data to make informed decisions and drive tangible improvements.

Rather than accepting the status quo, we advocate for continuous improvement. By monitoring both product quality and management effectiveness, we aim to unlock new levels of success for businesses.

Our framework doesn't seek to dismantle existing standards; instead, it builds upon them. It's a rallying cry for embracing innovation and adopting a data-driven mindset in product management.

Join us as we embark on a journey towards excellence in product management. Together, let's shape a future where insights fuel progress, and success knows no limits.

In the 21st century, product management has undergone a significant evolution, driven by advancements in technology, changing consumer behavior, and a shift towards data-driven decision-making.

  • Agile Methodology: The Agile methodology revolutionized product development by promoting iterative and flexible approaches. Companies like Spotify and Google have embraced Agile principles to quickly adapt to market changes and deliver value to customers in smaller increments.
  • Lean Startup: Popularized by Eric Ries, the Lean Startup methodology emphasizes rapid experimentation and validated learning. Companies like Dropbox and Airbnb have utilized Lean Startup principles to test hypotheses, iterate on products, and minimize waste in the development process.
  • Data-Driven Insights: With the proliferation of big data and analytics tools, product managers now have access to vast amounts of data to inform decision-making. Companies like Netflix leverage data to personalize recommendations and optimize user experiences, driving customer satisfaction and retention.
  • User-Centric Design: Product management has shifted towards a user-centric approach, focusing on understanding user needs and preferences. Companies like Apple and Amazon prioritize user experience design to create intuitive and engaging products that resonate with their target audience.
  • Cross-Functional Collaboration: Collaboration between product management, design, engineering, and other departments has become increasingly important. Companies like Slack and Atlassian promote cross-functional teams to foster innovation, streamline communication, and accelerate product development cycles.

Overall, the evolution of product management in the 21st century has been characterized by agility, data-driven decision-making, user-centric design, and cross-functional collaboration, enabling companies to deliver innovative products that meet the evolving needs of customers in a rapidly changing landscape.

Now let's make a slight detour. During the COVID-19 pandemic, which began in early 2020 and persisted throughout subsequent years, numerous trends reshaped the landscape of product management. As people worldwide shifted to remote work and increased their reliance on digital solutions, IT companies experienced exponential growth.

Before jumping directly into product maturity stages, we need to first explain why product maturity stages or product maturity level, if you will, are important. Most product management methodologies speak about how to set up a priority, how to effectively describe the capabilities to be developed, etc. Very few methodologies describe its mechanism to be dependent on product maturity level. While this is one of the most important aspects of how to do product management effectively. Here are the key reasons why:

  1. Size and quality of the backlog: Both aspects dramatically change between the phase when you work on a new start-up like a product and the phase where you manage a product with thousands of users generating a massive amount of feedback every day.
  2. Prioritization: While in the early stage of product maturity, product managers have to prioritize from a smaller backlog of relevant points. In the later maturity stage, prioritization becomes harder due to a significantly larger amount of feedback, non-relevant feedback, duplicate feedback, or similarities.
  3. Fluctuate roadmap planning: Later in this document, we describe a product management quality parameter called "Rate of moving," which indicates how much replanning, reschedules, and changes you have in your roadmap.
  4. Estimates: While estimates are always a hot topic, there are certain trends you want to follow. Regardless of how you do them, the desired trend as product maturity goes is that estimates become more precise over time.

For the simplicity and further topics, we will use these four stages.

Some publications state there are 6 stages instead of 4. While the principle remains the same, the six-phase model provides more granular insight into product lifecycle management:

Six-Phase Product Maturity Model

  1. 1. Introduction - The product is launched to the market. Sales are low as customers are not yet aware of the product. Focus is on building awareness and establishing initial market presence.
  2. 2. Growth - Product gains market acceptance. Sales increase rapidly as more customers adopt the product. Competition begins to intensify and market share expands.
  3. 3. Maturity - Sales growth slows as the product reaches widespread acceptance. Market is saturated with competitors. Focus shifts to differentiation and maintaining market share.
  4. 4. Saturation - In every successful product lifecycle timeline, there will inevitably come a point when the market becomes saturated, leaving little to no room for growth. The market is fully penetrated, and sales plateau as most potential customers already own or use the product. This saturation is often a natural consequence of success—when a product proves to be successful, it attracts more and more competitors who want to participate in the market. As these similar projects and alternatives emerge, they collectively fill the available market space until saturation is reached. Competition becomes intense, profit margins decrease, and the focus shifts from growth to maintaining market position. This phase is not a failure, but rather an inevitable stage in any successful product's journey, signaling the need for strategic decisions about innovation, differentiation, or market expansion.
  5. 5. Decline - Sales begin to decrease as the product becomes outdated or replaced by newer alternatives. Market share shrinks and profitability declines.
  6. 6. Revival - Through innovation, repositioning, or finding new markets, the product experiences renewed interest and sales growth. Not all products reach this phase.

However, no matter how many phases there are, there are always just 2 important questions regarding product maturity phases:

  1. How to go through Introduction phase as fast and effective as possible and start growth
  2. How to have the Maturity stage as long as possible and delay any of the phases that come after it.

These are the questions we will try to answer in following chapters.

One of the very early product management methodologies described 4 basic stages of each capability within the product. We will stick with those. Each capability in your product progresses through these stages, and the distribution of capabilities across these stages has a direct impact on your overall product maturity.

The Four Capability Maturity Stages

0
Stage 0: Not Possible

The capability simply doesn't exist in the product. There is no way to achieve it—not through workarounds, not through dedicated features, not at all. Example: A project management tool where it's impossible to add multiple users to a workspace. The fundamental infrastructure or features required for this capability are completely absent from the product.

1
Stage 1: Possible

The capability can be achieved, but it requires effort, workarounds, or using features in unintended ways. It's technically feasible without touching code, but it's not straightforward or intuitive. Example: Adding multiple users by creating separate accounts and manually sharing files through export/import functionality. It works, but it's cumbersome and requires users to understand the workaround.

2
Stage 2: Easy for Someone

The capability is accessible and easy to use, but only for some of your target user personas—typically those with technical knowledge or specific expertise. A dedicated feature exists, but it requires skills or understanding that not all users possess. Example: A scripting interface or API that allows developers to add users programmatically. Power users and developers find this easy, but non-technical team members cannot use it without assistance.

3
Stage 3: Easy for Everyone

The capability is fully accessible and intuitive for all target user personas, regardless of their technical expertise. The feature is polished, well-documented, and designed with the entire user base in mind. Example: A simple "Invite User" button with an intuitive dialog that guides any user through adding team members with clear labels, validation, and helpful tooltips. Everyone can accomplish this task effortlessly.

Every, and I mean literally every single company struggles with how to effectively calculate priority. It oscillates between super complicated mechanisms that spit out some number (often random) at the end all the way to having 3 simplistic stages of priority - High, Medium, Low. Now, what is the correct approach? There is no correct answer to this question.

So let's dive deep into how to effectively choose the methodology for setting up a priority for your backlog. First of all, we need to realize what do we use priority for. That has a simple answer - to drive the order of the tasks in our backlog. So effectively, priority is a "tool" to have backlog well organised, understandable for the team and ideally for any external observer. In order to have the backlog well organised, we need have good understanding how the backlog is composed and how does the backlog composition depends on product maturity stage. Spoiler alert, it does depends on it a lot!

So let's have a look how the backlog distribution typically looks like depending on product maturity stage.

In the introduction phase, your backlog is small and tightly controlled—everything feels important because the dev team and PM team directly manage every task. The highest priority naturally goes to tasks that shift capabilities from "not possible" to "possible," building your product's foundation.

But here's the critical insight: While the vast majority (~85%) of your backlog comes from internal sources—your vision, technical requirements, and team insights—that small slice (~15%) coming from early adopters is disproportionately valuable. These brave users who adopt your product despite its rough edges provide the market validation, real-world use cases, and honest feedback you desperately need. Finding them, nurturing those relationships, and deeply understanding their feedback isn't just helpful—it's the key to transitioning from Introduction to Growth phase.

In the growth phase, your backlog evolves significantly—it's no longer just about building the foundation. Now you're juggling two critical priorities: expanding what your product can do (adding new capabilities) and refining what already exists (making features more usable).

The key insight: A healthy growth phase maintains a 60/40 balance. Roughly 60% of your effort should focus on moving capabilities from "Not Possible" to "Possible"—building out feature breadth and completeness. The remaining 40% should target moving capabilities from "Possible" to "Easy for Someone"—polishing UX, reducing friction, and enabling power users. This balance ensures you're both growing horizontally with new capabilities and vertically by deepening what already exists.

A common indicator of this phase? Your product is profitable, stable, and has a relevant and active user base. But here's the challenge: your backlog becomes a magnet for noise. Everyone has opinions, feature requests get duplicated across stakeholders, and irrelevant ideas accumulate faster than you can evaluate them.

The key to sustaining momentum: Active backlog curation. To keep this phase alive and prevent users from churning, you must stay above the competition—and that requires focus. A healthy mature backlog keeps "garbage items" (duplicates, irrelevant requests, out-of-scope ideas, stale tickets) below 15-20%. When garbage exceeds 50%, your backlog becomes toxic: teams waste time on noise, valuable work gets buried, and product momentum stalls. Saying "no" becomes as important as saying "yes".

Often overlooked linchpin is the quality of product management itself. The success of any product hinges not only on its technical finesse but also on the strategic direction, customer-centric approach, and effective decision-making brought forth by adept product management.

The "Garbage Backlog" is a critical parameter that sheds light on the health of a project's backlog over time. This metric encapsulates the accumulation of unused, unplanned, and stagnant tasks that linger within the backlog without progressing or contributing to the project's goals.

The key insight: While it's natural for your total backlog size to grow over time, what matters is the ratio between priority levels. A healthy backlog maintains proportional growth—if high-priority items are growing, medium and low-priority items should grow at a similar rate. When low-priority items accumulate significantly faster than high-priority items, you're seeing garbage accumulation.

Let's examine how healthy versus unhealthy backlog growth patterns look over time, using three basic priorities: High (P1), Medium (P2), and Low (P3).

First, let's establish a shared understanding of what "planned" means. A planned task has clear delineation of who will undertake it, when it will be executed (target sprint/release), and what its objective entails.

While it's perfectly natural to adjust timelines—priorities shift, dependencies emerge, estimates prove wrong—the frequency of these moves indicates planning health. The key metric is the movement ratio: total date/sprint changes divided by total planned items.

Why ratio instead of absolute numbers? Because your backlog and roadmap grow over time. If you have 100 items and make 18 moves per month, that's healthy (0.18 ratio). If you have 150 items and make 96 moves per month, that's chaos (0.64 ratio). The ratio reveals whether your planning discipline is improving, stable, or deteriorating.

Estimation is inherently uncertain—it's unrealistic to expect perfect accuracy. What matters isn't achieving 0% variance, but rather tracking how the variance trends over time.

The key metric is the percentage delta: the average difference between estimated and actual effort spent, expressed as a percentage. For example, if you estimated 10 hours but spent 13 hours, that's a +30% delta. By tracking the average monthly percentage delta across all completed tasks, you normalize for varying task sizes and backlog composition.

A stable delta (15-20%) is healthy and predictable. A declining delta signals continuous improvement in estimation accuracy. A growing delta signals systemic problems: increasing complexity, technical debt, unclear requirements, or capacity issues.

In the Space-Up methodology framework, the ground crew comprises team members who are currently unassigned to specific roadmap or backlog tasks. Rather than being "idle," these individuals handle critical activities that keep development healthy: bug fixes, support escalations, code reviews, infrastructure improvements, and technical debt reduction.

The key insight: Teams need capacity bufferto handle unpredictable work without constantly interrupting planned tasks. When ground crew drops to 0% (everyone assigned), urgent issues force context-switching and thrashing. When ground crew exceeds 35%, the roadmap is too thin and capacity is wasted.

The optimal range is typically 10-15%, though this varies by context. Early-stage products with frequent customer issues may need higher ground crew (15-25%). Mature products with robust monitoring may operate well at 10-15%. What matters is stability—if ground crew swings wildly month-to-month, it signals poor capacity planning.

Task stability measures how often planned or assigned tasks experience changes after being committed to a development or release cycle. Changes include reassignments (who implements it), estimate adjustments, start date shifts, and target date changes.

The key metric is average changes per task—total changes divided by total planned tasks. This metric reveals planning quality: if tasks constantly change after being planned, it signals unclear requirements, frequent re-prioritization, or poor estimation.

A declining trend is ideal, indicating improving planning maturity: requirements become clearer, estimates improve, and assignments stabilize. A flat or growing trend signals persistent planning problems that create constant context-switching and reduce team efficiency.

Every product manager aspires to be (or professes to be) data-driven. But how do you measure whether your roadmap is truly backed by evidence or just well-articulated assumptions? The answer lies in tracking confidence levels—a classification system that indicates how validated each roadmap item is. It is important to understand that this is not a measure of the feature's importance, but rather a measure of how well-founded the decision to include it in the roadmap is.

Confidence level measures how confident the product manager is that a feature is genuinely demanded by the market. While methodologies vary in sophistication (some use scores, others use categories), a simple three-level system works well for this type of demonstration:

  • Level 1 (Low Confidence): Features based purely on PM intuition, internal stakeholder opinions, or personal conviction—no market validation.
  • Level 2 (Medium Confidence): Features supported by some evidence like market research, competitive analysis, or industry trends—indirect validation.
  • Level 3 (High Confidence): Features validated by direct evidence: user research, analytics data, customer feedback, or launch experiments—direct market validation.

The key is the trend. Over time, Level 3 items should grow faster than Level 1 items—both in absolute count and as a percentage of your backlog. This signals that your organization is increasingly relying on data and user validation rather than hunches. If Level 1 grows faster than Level 3, your roadmap is becoming less data-driven over time.