Last week I asked Claude to run a TAM/SAM/SOM analysis for an AI ad automation product. I typed one sentence. Here's what came back.

Three web searches for live market data. A $18.1B TAM with sourced growth rates. A competitive landscape table mapping five categories of competitors. A sensitivity analysis with bull, base, and bear cases. An assumptions table with specific validation steps. And a strategic takeaway that identified platform-native AI (Google's Performance Max, Meta's Advantage+) as the real competitive threat.

Not a generic template. Not a ChatGPT-style paragraph that sounds smart but says nothing. A structured strategic analysis with real data, honest confidence levels, and questions designed to pressure-test every assumption.

That output came from strategy-mcp. An open source toolkit I built over the last two weeks. Today I'm shipping it.

Why I Built This

I've spent 20 years using product frameworks. RICE for prioritization. Jobs-to-be-Done for discovery. OKRs for execution. Wardley Maps for strategic positioning. These frameworks aren't optional. They're how good product decisions get made.

When I started building with AI coding tools like Claude Code and Cursor, I realized something frustrating. These tools are brilliant at writing code. They can scaffold an app in minutes. But ask them to apply a product framework and you get a surface-level response. You ask for a RICE score, you get a number with no reasoning. You ask for a competitive analysis, you get a generic 2x2 with no insight.

The frameworks exist. The AI capabilities exist. Nobody had connected them properly.

Then I discovered MCP. It lets you give AI assistants actual tools. Not prompts. Tools. With structured inputs, structured outputs, and built-in domain logic. When I understood what MCP could do, the idea clicked immediately.

I could encode the frameworks I've used for 20 years as tools that any AI assistant can call natively. Not describe them in a prompt. Encode them. With the expert judgment, the pressure-test questions, the follow-up recommendations, and the confidence indicators built in.

So I did. And I decided to do it in public.

I posted a teaser on LinkedIn two weeks ago. Just a short post explaining the idea. Encode product frameworks as MCP tools. Ship them open source. Let any PM use them. It got close to 100 likes and 30 comments. That told me that PMs feel this gap between AI capabilities and structured product thinking. It's not just me.

That early signal created accountability. I had an audience waiting for this to ship. So I built it properly.

What strategy-mcp Actually Does

Every tool in strategy-mcp returns four things. Structured analysis based on your specific inputs. Actionable next steps you can take right now. A confidence indicator that tells you how reliable the output is. And pressure-test questions designed to challenge your assumptions before you commit.

This is not "here's a template, go fill it in." This is "here's the analysis, here's what to do next, and here's how to challenge it."

There are 12 tools grouped across six categories.

• Prioritization. RICE scoring that doesn't just calculate a number. It flags when your confidence is low and tells you what to test first.

• Discovery. Assumption mapping and Jobs-to-be-Done analysis. These are the steps most teams skip. The tools force you through them.

• Positioning. Competitive positioning on custom axes you define. Not another generic SWOT.

• Business Model. Business Model Canvas review, TAM/SAM/SOM sizing, and pricing strategy analysis. This is the strategic depth layer.

• Execution. OKR generation and initiative scoping. Connecting strategy to the work that actually ships.

• Advanced. Wardley assessment, hypothesis builder, and a structured decision log. The expert-level tools that most PMs know about but rarely apply well.

See It In Action

Numbers and descriptions only go so far. Let me show you what this actually looks like when you use it.

If you asked a standard AI chatbot for a TAM/SAM/SOM, you'd get a paragraph. Maybe some round numbers pulled from training data. No sources. No assumptions table. No way to know if the numbers are current or three years old. You'd spend the next hour verifying everything yourself.

Here's what happened when I typed this into my terminal:

"I need a TAM SAM and SOM for an AI product that does automation for marketeers running campaigns on multiple ad networks."

One sentence. Here's what strategy-mcp did.

That's not a prompt response. That's a structured strategic analysis that would take a PM hours to put together manually. It came back in under a minute.

Every tool in strategy-mcp works this way. The RICE tool doesn't just give you a score. It challenges your confidence levels. The JTBD tool doesn't just list jobs. It maps the push and pull forces driving customer behavior. The hypothesis builder doesn't just format your guess. It tells you whether your hypothesis is actually testable.

The pattern is the same across all 12. Give the tool your context. Get back structured analysis, next steps, confidence levels, and the questions you should be asking.

What I Learned Building It

Three lessons stood out.

Frameworks need opinions, not just structure.

A RICE calculator is easy to build. A RICE tool that tells you "your confidence is low, here's what to test first" is hard. The difference is encoding expert judgment, not just the formula.

Every PM has used a framework and gotten a number that felt wrong but looked right on paper. You plug in high impact and high confidence because you're excited about the feature. The score comes back strong. You ship it. It flops. The framework didn't fail. Your inputs were wrong and nothing challenged them.

The value of a good framework isn't the math. It's the forcing function that makes you question your own inputs. That's what I tried to encode in every tool. Not just "here's your score" but "here's why you should or shouldn't trust it."

Output quality is the product.

In an MCP tool, there's no UI. No dashboard. No drag-and-drop interface. The text output IS the experience. Every word in every response had to earn its place.

I rewrote the RICE tool's output format five times. The first version gave you a score and moved on. Fine, technically correct, completely useless in practice. The second version added a breakdown of each factor. Better, but still just a calculator. The final version walks you through each factor, flags where your estimates are weakest, and suggests what to research before making a decision. It tells you when your reach estimate looks inflated relative to your confidence level. It warns you when effort seems underestimated for the scope you described.

Same framework. Completely different experience. The lesson was that in AI tooling, writing quality is product quality. They're the same thing. If you're building MCP tools, you're a writer whether you realize it or not.

MCP is the distribution layer for expertise.

This was the real insight for me. MCP doesn't just connect AI to tools. It lets domain experts ship their expertise as software.

Think about what that means. I spent 20 years learning when a RICE score is misleading. When a TAM estimate needs a tighter filter. When a hypothesis is testable versus just wishful thinking. That judgment used to live in my head. Now it lives in a tool that any PM can install and use inside any AI conversation.

If you're an expert in anything, you can encode your expertise into an MCP tool. Lawyers could encode contract review frameworks. Designers could encode accessibility audits. Marketers could encode campaign analysis. MCP turns domain expertise into portable, reusable software. That's a big deal.

What's Next

strategy-mcp is open source under MIT license. You can install it today. Contributions are welcome. If there's a framework you use regularly that isn't included, open an issue or submit a PR.

It's also the first of three open source tools I'm shipping in an 8-week build-in-public series.

strategy-mcp helps you think strategically. founder-mode (coming in two weeks) turns Claude Code into an AI co-founder for solo builders. agent-pm connects AI to your execution layer.

Think. Build. Execute. Three tools, one series.

I'll be documenting everything as I go. The decisions, the tradeoffs, the things that broke. If the LinkedIn teaser taught me anything, it's that PMs want to see how these tools get built, not just use the finished product.

Try It Now

Install strategy-mcp with one command. Open Claude Code or any MCP-compatible AI assistant. Ask it to run a RICE analysis on your current feature backlog. Or size a market you've been thinking about. Or map the assumptions behind your latest product bet. Or generate OKRs for next quarter.

Pick the framework you use most. Run it through the tool. Compare the output to what you'd get from a generic AI prompt. The difference will be obvious.

Then tell me what you think. I read every response.
https://github.com/sohaibt/strategy-mcp - more details on how to install in the read me file, you can install it locally using the below terminal commands:

git clone https://github.com/sohaibt/strategy-mcp.git
cd strategy-mcp
uv run python server.py

What expertise would you encode as a tool if you could? That question has been stuck in my head since I started this project. I'd love to hear your answer.

Leave a comment

Welcome to this week’s edition of Mastering Product! If you’ve been following the AI tooling space, you’ve heard the term MCP thrown around a lot. (FYI I am a building a strategy MCP, opensource, launching Monday) But most of the coverage focuses on developers. Today, I’m writing this for product managers. MCP and AI agents aren’t just engineering tools anymore. They’re about to fundamentally change how PMs discover customer problems, validate solutions, and make decisions. This is a practical guide to what MCP is, how PMs can use it today, and what it means for the future of product discovery. No engineering background required.

What MCP Actually Is (In PM Terms)

Think of MCP as a universal adapter that lets AI assistants plug into any tool or data source.

Before MCP, if you wanted an AI to access your analytics data, someone had to build a custom integration. Want it to read your Jira board? Another integration. Support tickets? Another one. Each connection was bespoke, brittle, and engineering-dependent.

MCP standardizes this. It’s an open protocol, like USB for AI agents. Once a tool has an MCP server (and hundreds now do), any MCP-compatible AI agent can connect to it. Configure it once, use it everywhere.

For PMs, this means: you can set up an AI assistant that has real-time access to your product data, customer feedback, analytics, project management tool, and codebase all at once. And you can do it yourself, without filing a single engineering ticket.

The PM’s MCP Stack: What to Connect

Here’s the stack I recommend PMs set up, in order of impact:

Tier 1: Connect First (Immediate value)

Customer Feedback Tools (LogRocket, Sentry, Intercom, Zendesk)

Connect your session replay and support tools. This lets you ask your AI agent: “What are the top 5 user frustrations this week?” and get an answer grounded in actual session data and support conversations, not your memory of the last team meeting.

Analytics Platforms (Amplitude, Mixpanel, PostHog)

Connect your product analytics. Ask: “How has onboarding completion changed in the last 30 days?” or “Which user segment has the highest churn risk?” Getting answers in seconds instead of waiting for an analyst cycle changes how quickly you can make decisions.

Project Management (Linear, Jira, Asana)

Connect your task tracker. Your AI agent can now understand your team’s current workload, sprint progress, and backlog, and factor that context into any analysis or recommendation.

Tier 2: Connect Next (Multiplier effect)

Your Codebase (GitHub, GitLab)

Connect your repo. Not to write code, but to understand it. Ask: “Where does the onboarding flow live in the codebase?” or “When was the checkout page last modified and by whom?” This context is invaluable for product decisions.

Communication Tools (Slack, Email)

Connect your team’s communication channels (with appropriate permissions). Your AI agent can surface relevant decisions made in Slack threads, unanswered questions, or recurring team concerns you may have missed.

Documentation (Notion, Confluence)

Connect your knowledge base. This lets the agent reference your existing PRDs, research findings, and strategy docs when helping you make decisions, ensuring consistency with prior thinking.

Tier 3: Advanced (For power users)

Database Access (Read-only)

If your company allows it, read-only database access via MCP lets your AI agent run ad-hoc queries on your behalf. This is the ultimate shortcut for data-driven PMs.

Design Tools (Figma)

Connect Figma to give your agent visibility into current designs, enabling it to reference visual context when discussing features.

Five PM Workflows Transformed by MCP

Workflow 1: Real-Time Customer Pulse

Before MCP: Wait for the weekly support digest. Read through manually. Compile themes into a doc. Present at the next team meeting. Total cycle: 5-7 days.

With MCP: Ask your agent: *”Scan the last 48 hours of support tickets and LogRocket sessions. What are the top 3 emerging issues by frequency? Include direct quotes and session links for each.”*

Total cycle: 5 minutes. And you can do it daily instead of weekly.

Prompt template:

Review the last [timeframe] of support tickets and session replays.

Identify the top [number] user issues by:

1. Frequency (how many users affected)

2. Severity (impact on user workflow)

3. Trend (is this increasing or stable?)

For each issue, include:

- A one-sentence summary

- 2-3 representative user quotes

- Links to relevant sessions or tickets

- Your assessment of whether this is a bug, UX issue, or missing feature

Workflow 2: Sprint-Ready Discovery

Before MCP: Discovery involved separate sessions for data analysis, user interview synthesis, competitive research, and technical feasibility, often spread across weeks.

With MCP: Run all of these in parallel through your agent:

• Pull behavioral data from your analytics tool

• Summarize recent user feedback on the topic from support

• Search for relevant prior research in your Notion docs

• Check the codebase to understand current implementation complexity

You can compress a two-week Discovery Sprint’s Gather phase into 2-3 days.

Workflow 3: Impact Estimation

Before MCP: Estimating the impact of a proposed feature required pulling data from multiple sources, building a spreadsheet model, and making assumptions about conversion rates and user behavior.

With MCP: Ask your agent: *”Based on our current analytics data, estimate the potential impact of reducing the checkout flow from 5 steps to 3. Use our current drop-off rates between steps and conversion data from the last 90 days.”*

The agent pulls real numbers, does the math, and gives you a grounded estimate- with the assumptions made explicit for you to validate.

Workflow 4: Competitive Intelligence

Before MCP: Manually browsing competitor products, reading their changelogs, monitoring their social media, and compiling findings into a slide.

With MCP (combined with web search): Ask your agent: *”What significant product changes have [Competitor A], [Competitor B], and [Competitor C] shipped in the last quarter? Focus on features relevant to our [specific product area]. Compare their approaches in a table.”*

Workflow 5: Stakeholder Preparation

Before MCP: Before a major product review, you’d spend hours assembling context - current metrics, recent customer feedback, engineering status, competitor moves, into a coherent narrative.

With MCP: Your agent has access to all of this context simultaneously. Ask it to generate a briefing document that synthesizes the current state across all dimensions. Then spend your prep time on what matters: sharpening your recommendation and anticipating questions.

Setting Up Your First MCP Connection

Here’s a step-by-step for PMs who’ve never configured an MCP tool:

Step 1: Choose your AI client

Claude Desktop, Claude Code, or Cursor all support MCP. Claude Desktop is the most PM-friendly starting point.

Step 2: Pick your first connection

Start with the tool that answers your most frequent question. For most PMs, that’s either analytics (Amplitude/Mixpanel) or customer feedback (Intercom/Zendesk).

Step 3: Install the MCP server

Most popular tools now have community-built MCP servers. Search for “[your tool] MCP server” on GitHub. Installation typically involves cloning a repo and adding a few lines to your Claude Desktop configuration.

Step 4: Configure authentication

You’ll need an API key from your tool. Most tools provide this in their settings under “API” or “Integrations.” Add the key to your MCP configuration.

Step 5: Test with a simple query

Start with something you already know the answer to: “How many support tickets did we receive last week?” If the number matches your dashboard, you’re correctly connected.

Step 6: Build your first real workflow

Now ask a question you don’t know the answer to. Something you’d normally wait for an analyst to answer. That’s the moment MCP becomes real for you.

The Agent-Powered Discovery Sprint

In an earlier article, I introduced the Discovery Sprint, a 2-week framework for rapid product validation. Here’s how MCP and AI agents transform each phase:

| Discovery Sprint Phase | Traditional Approach | Agent-Powered Approach |

| Frame (Days 1-2) | Team brainstorm, manual assumption mapping | Agent pre-populates assumptions from recent support data and analytics trends |

| Gather (Days 3-5) | Manual data pulls, scheduled interviews, desk research | Agent runs parallel data gathering across all connected sources in hours |

| Synthesize (Days 6-7) | PM manually cross-references evidence | Agent surfaces patterns, contradictions, and gaps across all evidence |

| Prototype (Days 8-10) | Designer builds mockup, engineering spikes | AI prototyping tools generate testable concepts in hours |

| Decide (Days 9-10) | PM compiles findings into recommendation | Agent drafts decision document from all evidence; PM makes the call |

The net effect: What takes two weeks in a traditional Discovery Sprint can now happen in 5-7 days with an agent-powered approach. Not because you skip steps, but because the data gathering and synthesis that used to consume most of the time is dramatically compressed.

Guardrails: When Not to Trust Your Agent

AI agents are powerful, but they’re not infallible. Here are the guardrails every PM should observe:

Never outsource judgment to an agent. The agent can surface that customer complaints about checkout increased 40% last month. Whether that’s the most important problem to solve right now is still your call.

Verify quantitative claims. If your agent tells you conversion dropped 12%, check the dashboard. AI agents can misinterpret data structures, apply wrong filters, or confuse metrics. Trust but verify, especially for numbers you’ll share with stakeholders.

Watch for hallucinated context. When agents synthesize across multiple data sources, they can occasionally create connections that don’t exist in the data. If a finding seems surprising, trace it back to the source.

Respect data access boundaries. Just because you can connect to a data source doesn’t mean you should. Follow your company’s data governance policies. Don’t connect customer PII-containing databases without appropriate approvals.

Don’t let speed replace rigor. The biggest risk of agent-powered discovery isn’t bad data, it’s premature closure. Because evidence arrives so quickly, teams can feel “done” with discovery before they’ve genuinely challenged their assumptions. Use the speed to go deeper, not to cut corners.

The PM’s Information Advantage

For fifteen years, a PM’s effectiveness was limited by how fast they could access and synthesize information. MCP and AI agents have effectively removed that limitation.

The PMs who learn to configure and work with these tools will have an information advantage that compounds every day. They’ll make faster decisions grounded in richer context. They’ll spot problems earlier. They’ll validate ideas before committing resources. And they’ll free up the time they used to spend on data gathering to invest in the strategic work that actually moves their products forward.

The toolkit has changed. The job- building products that solve real problems for real people, hasn’t.

---

Have you set up MCP connections for your PM work? What’s been the most valuable? Reply to this email to share your experience, I read every response and often feature reader insights in future newsletters.

Leave a comment

This is part of our series on the evolving PM role. Upcoming articles: “The Technical PM Playbook,” “The Death of the PM as Translator,” and “The 10x PM.”

Every product leader knows technical debt, those implementation shortcuts that slow down your engineering team over time.

But there's another form of debt that's just as damaging, and far less discussed: product debt.

Product debt builds up when you make expedient decisions about features, user experience, and product architecture. Each decision feels reasonable at the time. Collectively, they compound into a product that frustrates users, slows your team, and quietly erodes growth.

Left unmanaged, product debt doesn't just slow you down. It eventually makes meaningful progress nearly impossible.

How Product Debt Accumulates

It rarely happens all at once. It builds through a series of individually reasonable choices:

• Adding features to address specific requests without a coherent overall vision

• Creating new interaction patterns that don't align with existing ones

• Using different terms for the same concept across the product

• Building deeper navigation as the product expands

• Creating workarounds that force users into illogical paths

One day you realise that implementing a seemingly simple change requires untangling dozens of past decisions you barely remember making.

Why Product Debt Is Dangerous

Unlike technical debt, product debt directly impacts your users, not just your team.

It erodes user trust. Users develop mental models of how your product works. Inconsistencies force them to maintain multiple models, increasing cognitive load and reducing confidence in your product.

It creates hidden conversion barriers. Product debt often manifests as friction in critical journeys. These barriers rarely show up as errors in your analytics. They simply cause users to abandon.

It compounds over time. Every new feature built on top of existing product debt inherits and amplifies those inconsistencies. The longer you wait, the more expensive it becomes to fix.

It demoralises product teams. Teams want to build excellent experiences. Being forced to build on a shaky foundation gradually erodes their craft and pride in what they ship.

The Five Types of Product Debt

Each type accumulates differently and requires a different approach to fix.

1. Conceptual Debt

This occurs when your product's underlying model no longer matches how users think about the problem.

A classic example: a B2B SaaS platform built around individual users starts acquiring enterprise customers who think in terms of teams, departments, and roles. The product's entire conceptual model, permissions, billing, reporting, was designed for individuals. Retrofitting team-level thinking onto that foundation creates friction everywhere.

Detection signs:

• Users consistently misunderstand core concepts

• Support frequently explains "how to think about" your product

• New features require increasingly complex explanations

2. Navigational Debt

Navigation that grows organically - without intentional redesign - creates labyrinthine paths to important functionality.

Imagine a customer portal where key settings are buried four levels deep, not because they're unimportant, but because the navigation grew one feature at a time. Users contact support asking how to find things that have existed for years.

Detection signs:

• Important functionality requires multiple clicks to access

• Site search reveals users looking for features that already exist

• User journey mapping reveals unnecessarily complex paths

3. Interaction Debt

This builds when your product uses multiple patterns to accomplish similar tasks, forcing users to remember different interaction models for related operations.

A common example: a product where some sections auto-save, others have a persistent save button, and others require a modal confirmation. Users lose work constantly because they assume one model applies everywhere.

Detection signs:

• Users frequently lose work or make errors when moving between sections

• Training materials must explain multiple ways to perform similar actions

• User testing reveals hesitation when users encounter new sections

4. Visual Debt

Multiple rounds of redesigns, each only partially implemented, leave products looking fragmented. Three button styles. Multiple colour schemes. Inconsistent typography.

This matters more than aesthetics. Visual inconsistency signals to users that different parts of the product were built by different people with different standards. It reduces trust — even when the underlying functionality is solid.

Detection signs:

• Screenshots from different parts of your product could be from different applications

• Design teams spend excessive time debating which existing pattern to follow

• User research shows newer sections feel less trustworthy

5. Language Debt

When your product uses "booking," "reservation," and "stay" somewhat interchangeably, users genuinely can't tell if these are the same thing or represent different concepts. Neither can your support team. Neither can new engineers joining the codebase.

Detection signs:

• Support frequently clarifies terminology

• Internal teams debate what terms actually mean

• Localisation becomes increasingly difficult

Measuring Product Debt

You can't manage what you don't measure. Here's how to quantify yours.

Consistency Audit

Create an inventory of your product's patterns and count the inconsistencies:

• How many navigation models exist?

• How many ways can users perform similar actions?

• How many button styles, colour schemes, and typographic systems are in use?

• How many terms are used for similar concepts?

Most teams are surprised by what they find. A product that feels manageable often turns out to have 10+ button styles and 7+ navigation patterns once you map them out. That quantification makes the scale of the problem impossible to ignore.

User Journey Friction Analysis

Map your critical user journeys and identify where product debt creates friction:

• Count the steps required for key tasks

• Identify where users must carry information forward from previous steps

• Note where patterns change within a single flow

• Mark where users must backtrack to accomplish their goal

Support Request Analysis

Your support tickets tell you exactly where users are struggling. Categorise them by root cause and look for a pattern like this: 25-30% of tickets related to product confusion rather than bugs or missing features. That's product debt showing up in your support costs.

Strategies for Managing Product Debt

1. Debt-Conscious Development

The fastest way to control product debt is to stop accumulating it faster than you can pay it down.

• Require new features to use existing patterns. New patterns need explicit approval and must be added to your design system.

• Add a terminology review checkpoint to your development process.

• Before approving new features, explicitly evaluate how they affect existing user journeys.

These process changes are lightweight and significantly reduce the rate of new debt accumulation.

2. Incremental Refactoring

You can't fix everything at once. But you can make steady progress:

• The 20% rule: Dedicate 20% of each sprint to refactoring product debt in areas you're already working.

• The boy scout rule: Leave each area better than you found it. When working on a feature, clean up the surrounding experience.

• Journey-based refactoring: Focus on improving entire user journeys rather than isolated features. This creates consistent experiences for complete tasks.

3. Strategic Redesign

Sometimes incremental approaches aren't enough. You need a more substantial intervention:

• Create a clear experience vision that addresses your major sources of product debt.

• Break it into phases that deliver user value at each stage, rather than a "big bang" redesign.

• Design explicit migration paths to move users from old experiences to new ones.

4. Product Debt Sprints

Dedicate focused time specifically to debt reduction:

• Schedule sprints focused entirely on product debt in critical areas.

• Establish clear before/after metrics.

• Limit each sprint to a specific type of debt or a specific user journey.

Quarterly debt sprints not only reduce product debt — they give teams a renewed sense of craft.

What a Debt Paydown Actually Looks Like

Here's a concrete example of what tackling product debt at scale looks like in practice.

Imagine a marketplace product whose detail page, its most critical conversion point, has accumulated five years of experimentation-driven growth:

• 5 different design patterns for similar information

• 3 different ways to indicate availability

• 8 different call-to-action button styles

• Inconsistent terminology around item types and conditions

The symptoms are measurable: user research shows confusion, support contacts about key terms have increased 24% year-over-year, and A/B test velocity has slowed because changes frequently conflict with existing patterns.

The approach:

1. Comprehensive audit mapping every pattern, every terminology inconsistency, every friction point

2. Conversion impact estimate to secure resources for the work

3. Pattern rationalisation- one unified set of patterns for key information types

4. A six-month phased implementation plan, prioritised by user impact

5. A pattern review process to prevent new inconsistencies from forming

Six months later: conversion up 3.8%, support contacts related to the affected area down 17%, A/B test velocity up 30%, and a product team that reports higher satisfaction in their work.

The outcome isn't just a better product. It's a faster product team with a foundation they can actually build on.

Building a Product Debt-Conscious Culture

Processes and frameworks matter. But culture determines whether they stick.

Celebrate quality, not just ship dates. Add explicit quality metrics to team OKRs, giving them equal weight with delivery metrics.

Make debt visible. Create a debt map that highlights inconsistencies across your product. Make the problem tangible for everyone, not just the design team.

Empower teams to say "not like this." Give product teams the authority to push back when pressured into solutions that create excessive debt. This only works with leadership backing.

Build debt consideration into product reviews. Ask these questions explicitly:

• How does this feature integrate with existing patterns?

• What terminology does it use, and is it consistent?

• How might this create future limitations?

Share the cost. Help stakeholders understand what product debt actually costs in terms they care about: development velocity, support costs, conversion rates, and competitive disadvantage.

The most successful products aren't always the ones with the most features. They're the ones with a coherent vision, consistent execution, and deliberate evolution — products where teams manage debt rather than letting debt manage them.

What product debt is lurking in your product right now? And what's your plan to address it before it starts managing you?

Leave a comment

Why LLM Products Are Different

Building on top of LLMs isn’t like building traditional software features. The mental model that’s served you well as a PM, define requirements, build deterministic logic, test against expected outputs, ship - breaks down in fundamental ways when LLMs enter the picture.

Here’s why:

LLMs are non-deterministic. The same input can produce different outputs each run. This means you can’t write traditional test cases that check for exact matches. You need a new quality framework.

Requirements are expressed differently. Instead of writing logic in code, you’re writing instructions in natural language (prompts). The gap between “what you asked for” and “what you get” is wider and less predictable than with traditional software.

Failure modes are novel. LLM features don’t just break, they hallucinate, go off-topic, produce biased outputs, or confidently give wrong answers. Your users can’t always tell the difference between a good response and a plausible-sounding bad one.

Cost scales with usage in new ways. Every API call has a direct cost tied to token count. A chatty feature that generates long responses isn’t just slow, it’s expensive. Product decisions directly impact your infrastructure bill.

These differences don’t make LLM products impossible to manage, but they do require product managers to develop new skills and frameworks. That’s what this guide is about.

The LLM Product Stack: What PMs Need to Understand

You don’t need to train models, but you do need to understand the stack you’re building on. Here are the layers that matter for product decisions:

Layer 1: The Foundation Model

This is the LLM itself, GPT, Claude, Gemini, Llama, Mistral, etc. Your key product decisions at this layer:

Model selection. Different models have different strengths. Some excel at reasoning, others at creative writing, others at code generation. The right model depends on your use case, not on benchmarks. Always prototype with 2-3 models before committing.

Model size vs. cost tradeoff. Larger models are generally more capable but slower and more expensive per call. For many product features, a smaller, faster model delivers 90% of the quality at 20% of the cost. Map your quality requirements to the smallest model that meets them.

Hosted vs. self-hosted. API-based models (OpenAI, Anthropic, Google) are the fastest path to production. Self-hosted open-source models (Llama, Mistral) give you more control over cost, latency, and data privacy, but require ML infrastructure expertise. For most teams, start with APIs.

Layer 2: The Prompt Layer

This is where product requirements meet the model. Prompts are the new “business logic” for LLM features, and they deserve the same rigor you’d give to any core product component.

System prompts define the model’s persona, constraints, and behavioral guardrails. Think of them as the product spec the model follows on every interaction.

User prompts are what your users actually send. Your product design determines how structured or freeform these are, and that decision has massive implications for output quality.

Few-shot examples are sample input-output pairs you include in the prompt to guide the model’s behavior. They’re one of the most effective and underused techniques for improving output quality.

Layer 3: The Context Layer

LLMs are only as good as the context you give them. This layer is where most product differentiation happens.

Retrieval-Augmented Generation (RAG) pulls relevant information from your data sources and includes it in the prompt context. This is how you make a generic LLM knowledgeable about your specific domain, your product docs, customer data, internal knowledge bases.

Memory and conversation history determine how much prior context the model has access to. Managing this well is a core UX challenge too little context and the model forgets what was discussed; too much and you hit token limits and increase cost.

Tool use and function calling let the model take actions, querying databases, calling APIs, updating records. This is what turns a chatbot into an agent. It’s powerful but introduces new failure modes that require careful product guardrails.

Layer 4: The Evaluation Layer

This is the layer most teams build last but should build first. How do you know if your LLM feature is working well? Traditional software testing doesn’t apply. You need new approaches, and we’ll cover them in detail below.

Prompt Engineering: The PM’s Role

Prompt engineering has become its own discipline, but as a PM you don’t need to become a full-time prompt engineer. You do need to understand the principles well enough to set quality standards, review prompt designs, and have informed conversations with your engineering team.

The Prompt Design Principles That Matter Most

1. Be explicit, not implicit. LLMs follow instructions literally. If you want the model to respond in bullet points, say “respond in bullet points.” If you want it to stay under 200 words, say “keep your response under 200 words.” Vague instructions produce vague outputs.

2. Define the boundaries, not just the task. Tell the model what NOT to do as clearly as what TO do.

”Answer the user’s question about our product. If you don’t know the answer, say ‘I don’t have that information’ rather than guessing. Never discuss competitor products. Never make promises about future features.”

3. Use structured output formats. When you need consistent, parseable outputs (for downstream processing or UI rendering), specify the exact format: JSON schemas, markdown templates, or explicit field definitions. This dramatically reduces unpredictable outputs.

4. Iterate with real user inputs. Prompts that work perfctly with your carefully crafted test cases will break with real user inputs. Collect actual user queries early, even from beta users or internal testers, and optimize your prompts against those.

The Prompt Development Workflow

Here’s the workflow I recommend for product teams developing LLM features:

| Step | Who Leads | What Happens |

| 1. Define intent | PM | Describe what the feature should do, its constraints, and success criteria in plain language |

| 2. Draft prompt | PM + Engineer | Translate intent into an initial system prompt with examples |

| 3. Test with edge cases | Engineer + QA | Run the prompt against adversarial, ambiguous, and boundary inputs |

| 4. Evaluate outputs | PM + Domain expert | Score outputs on accuracy, relevance, tone, and safety |

| 5. Refine and version | Engineer | Iterate on the prompt based on evaluation results; version control every change |

| 6. Monitor in production | Engineer + PM | Track output quality metrics, user feedback, and failure patterns |

Key insight: Treat prompts like product copy, they need regular review, A/B testing, and iteration. A prompt that works well in March may degrade by June as user behavior evolves or the model provider ships updates. Build prompt maintenance into your sprint cadence.

Evaluation: The Make-or-Break Skill

If there’s one section of this article to internalize, it’s this one. Evaluation—knowing whether your LLM feature is actually good—is the single biggest gap in most AI product teams. Without a robust evaluation framework, you’re shipping blind.

Why Traditional Testing Falls Short

In traditional software, a test either passes or fails. The login button works or it doesn’t. But LLM outputs exist on a spectrum of quality. A response can be partially correct, technically accurate but unhelpfully verbose, factually right but tonally wrong, or perfectly helpful for one user segment but confusing for another.

You need a quality framework that captures these nuances.

The Three-Layer Evaluation Framework

**Layer 1: Automated Metrics (Run on every change)**

These are programmatic checks that run automatically on a test set of inputs:

• Format compliance: Does the output match the expected structure (JSON, bullet points, length limits)?

• Guardrail adherence: Does the output stay within defined boundaries (no competitor mentions, no hallucinated URLs, no PII leakge)?

• Factual grounding: For RAG-based features, does the output cite information actually present in the retrieved context?

• Latency and cost: Does the response meet performance SLAs?

Tools like Braintrust, Langsmith, and Promptfoo make automated evaluation pipelines practical to set up—and they’re worth the investment early.

Layer 2: LLM-as-Judge (Run on significant changes)

Use a separate LLM to evaluate the quality of your feature’s outputs. This sounds circular, but it’s surprisingly effective when done right:

• Define rubrics with clear scoring criteria (1-5 scale for accuracy, helpfulness, tone)

• Use a more capable model (e.g., Claude Opus or GPT) to judge outputs from a smaller model

• Include human-scored reference examples so the judge model is calibrated

This gives you scalable quality assessment without requiring human review of every output.

Layer 3: Human Evaluation (Run periodically and for high-stakes features)

Nothing replaces human judgment for catching subtle quality issues:

• Weekly sample review: PM and domain expert review a random sample of 20-50 production outputs

• User feedback loops: Thumbs up/down, explicit ratings, or follow-up surveys

• Adversarial testing: Dedicated sessions where the team tries to break the feature with edge cases

The Evaluation Cadence

| Frequency | Evaluation Type | Who’s Responsible |

| Every prompt change | Automated metrics against test set | Engineering |

| Weekly | LLM-as-judge on production sample | Engineering + PM |

| Bi-weekly | Human review of flagged outputs | PM + Domain expert |

| Monthly | Comprehensive eval + adversarial testing | Full product trio |

| Quarterly | Benchmark against newer models | Engineering + PM |

UX Patterns That Actually Work

LLM features introduce UX challenges that traditional product design doesn’t prepare you for. Here are the patterns that consistently work wel, and the anti-patterns to avoid.

Pattern 1: Set Expectations Transparently

Users need to understand they’re interacting with AI, what it can and can’t do, and when to trust (or verify) its outputs.

• Label AI-generated content clearly. Don’t try to pass off AI outputs as human-written.

• Show confidence indicators when the model is uncertain. Even a simple “I’m not fully confident in this answer” goes a long way.

• Provide source citations for factual claims, especially in RAG-based features. Let users verify.

Pattern 2: Constrain Input to Improve Output

Freeform text boxes are the enemy of consistent LLM quality. The more you guide user input, the better the outputs:

• Predefined action buttons (”Summarize this,” “Draft a reply,” “Find similar”) outperform open-ended “ask me anything” interfaces for task-specific features

• Structured forms with AI assist (fill in the blanks, then AI generates) produce more reliable results than pure generation

• Progressive disclosure that starts with a focused task and allows “go deeper” follow-ups

Pattern 3: Make Editing a First-Class Feature

AI-generated content should be a starting point, not a finished product. Design for human-in-the-loop editing:

• Inline editing of AI outputs (not just regenerate/accept)

• Multiple variations so users can pick and combine elements

• Edit history so users can undo AI suggestions without losing their work

Pattern 4: Design for Failure Gracefully

LLM features will produce bad outputs. Design for this inevitability:

• Easy reporting of bad outputs (thumbs down, flag button) that feeds back into your evaluation pipeline

• Graceful fallbacks when the model can’t help (”I’m not able to help with that, but here’s where you can find the answer”)

• Rate limiting and guardrails to prevent misuse and runaway costs

Anti-Pattern: The “Magic AI” Trap

The biggest UX mistake is promising too much. Products that present AI as omniscient (”Ask me anything!”) train users to expect perfection and then disappoint them. Products that position AI as a helpful assistant (”I can help you draft, summarize, and organize—here’s what I’m best at”) set appropriate expectations and delight users when the AI exceeds them.

Cost Management: The Hidden Product Decision

LLM API costs are a direct function of product decisions. As a PM, you influence the bill more than you might think.

Token-conscious design decisions:

| Design Choice | Cost Impact | Better Alternative |

| Long, detailed system prompts | Higher per-call cost | Keep prompts concise; move static context to cached prefixes |

| Unlimited conversation history | Grows with every turn | Summarize older turns; use sliding context windows |

| Always using the largest model | Highest per-token cost | Route simple queries to smaller models; use large models for complex tasks |

| Generating long responses by default | More output tokens | Set response length limits; let users request “more detail” |

| No caching of repeated queries | Redundant API calls | Implement semantic caching for common queries |

The model routing pattern: For many products, the smartest cost optimization is routing different types of requests to different models. Simple classification tasks go to a fast, cheap model. Complex reasoning goes to a more capable (expensive) model. A lightweight router model or rule-based classifier handles the routing decision. This can cut costs by 50-70% with minimal quality impact.

Shipping Your First LLM Feature: A Practical Playbook

If you’re shipping your first LLM-powered feature, here’s the sequence that minimizes risk:

Week 1-2: Discovery (use the Discovery Sprint from Part 1)

• Validate that the problem actually benefits from LLM capabilities

• Test whether users want AI-generated outputs or just better traditional UX

• Prototype with off-the-shelf tools before writing any code

Week 3-4: Prompt Development & Evaluation Setup

• Draft system prompts based on your product requirements

• Build a test set of 50-100 representative inputs (include edge cases)

• Set up automated evaluation metrics

• Benchmark 2-3 models against your test set

Week 5-6: Build the Feature

• Implement the feature with proper abstraction layers (don’t hardcode a single model provider)

• Add guardrails: input validation, output filtering, rate limiting

• Build the feedback mechanism (thumbs up/down at minimum)

Week 7-8: Internal Testing & Iteration

• Dogfood aggressively, get the whole team using it daily

• Run adversarial testing sessions

• Iterate on prompts based on real usage patterns

• Set up cost monitoring dashboards

Week 9-10: Controlled Rollout

• Ship to a small percentage of users (10-20%)

• Monitor quality metrics, cost per user, and user feedback daily

• Iterate on prompts and guardrails based on production data

• Expand gradually as metrics stabilize

Ongoing: Monitor, Evaluate, Improve

• Weekly output quality reviews

• Monthly model evaluations (newer models may perform better or cheaper)

• Quarterly prompt overhauls based on accumulated learnings

The PM Skills You Need to Develop

Building LLM products requires expanding your PM toolkit. Here’s what to invest in:

Learn to write prompts. You don’t need to be an expert, but you should be able to draft a working system prompt, understand why it produces certain outputs, and iterate on it. Spend a few hours experimenting with different prompting techniques, it’s the fastest way to develop intuition.

Understand tokenization and context windows. Know that models have finite input capacity, that longer inputs cost more, and that how you structure context affects output quality. This knowledge directly informs product decisions.

Get comfortable with probabilistic quality. Your LLM feature will never be 100% accurate. Your job is to define what quality threshold is acceptable, design the UX to handle failures gracefully, and build evaluation systems that catch degradation early.

Learn to read evaluation reports. You don’t need to build the evaluation pipeline, but you need to interpret the results, understand what accuracy, precision, recall, and quality scores mean for your users’ experience.

Stay current on model releases. The LLM landscape changes monthly. A model that didn’t exist when you started building may outperform your current choice by the time you ship. Build your product to be model-agnostic and review alternatives quarterly.

The New Product Management Discipline

Building products on top of LLMs is a genuinely new discipline within product management. The core PM skills, understanding users, defining problems, prioritizing ruthlessly, shipping iteratively, all still apply. But the tools, workflows, and quality frameworks need to evolve.

The PMs who will thrive in this era are the ones who develop fluency with prompts, build evaluation into their process from day one, design for AI’s inherent unpredictability, and stay relentlessly focused on user outcomes rather than getting dazzled by the technology.

LLMs are the most powerful building blocks we’ve ever had access to as product builders. But a building block without a blueprint is just a pile of potential. Your job as a PM is to provide the blueprin, to channel this capability into products that solve real problems, work reliably, and earn users’ trust.

That’s the craft. And it’s never been more exciting to practice it.

Are you building LLM-powered features? What’s been your biggest challenge, evaluation, prompts, UX, or cost? Reply to this email to share your experience, I read every response and would be happy feature reader insights in future newsletters.

This was Part 2 of our AI Product Strategy series. Missed Part 1? Read “AI-First Product Strategy: When to Build, Buy, or Partner” for the strategic framework that precedes the tactical guide above.

Leave a comment

Welcome to this week’s edition of Mastering Product! This is Part 1 of my AI Product Strategy series. Today, I am addressing the question every product leader is facing right now: should you build your own AI capabilities, buy off-the-shelf solutions, or partner with specialized AI providers? The answer isn’t as straightforward as it seems, and getting it wrong can cost your company years of runway. I’ll walk you through a decision framework that cuts through the hype and helps you make this call with confidence. In Part 2, we’ll go deeper into the tactical side of building products on top of LLMs. Let’s get into it.

The AI Capability Question

Every product roadmap in 2026 has some version of “add AI” on it. But behind that deceptively simple line item sits a decision that will shape your product’s competitive position, your team’s capabilities, and your company’s cost structure for years to come.

The real question isn’t whether to incorporate AI, that ship has sailed for most products. The question is how to incorporate it, and the answer depends on factors that most teams don’t evaluate rigorously enough before committing.

I’ve watched companies burn through millions building custom ML infrastructure they didn’t need, while their competitors shipped faster by leveraging third-party APIs. I’ve also seen the reverse: teams that outsourced their core AI capability to a vendor, only to find themselves locked into a commodity experience with no differentiation. Both mistakes stem from the same root cause, making the build/buy/partner decision based on excitement rather than strategy.

The framework I’m sharing today forces you to evaluate this decision through three lenses: strategic differentiation, organizational capability, and total cost of ownership. Get these three right, and the decision usually becomes clear.

The Build-Buy-Partner Spectrum

Before diving into the framework, let’s be precise about what each option actually means in the AI context:

Build means developing proprietary AI capabilities in-house. This ranges from fine-tuning foundation models on your proprietary data to training custom models from scratch. You own the model, the training pipeline, and the inference infrastructure.

Buy means using commercial AI products or APIs as-is. You’re consuming someone else’s AI capability through their interface, think integrating Anthropic’s API, using a pre-built AI customer service tool, or embedding a third-party recommendation engine. Minimal customization, fast time-to-market.

Partner sits in between. You work with an AI provider to create a solution tailored to your specific use case, often combining their model expertise with your domain data. This could mean working with an AI studio to fine-tune a model on your data, co-developing a solution with a specialized AI company, or establishing deep API integrations with significant customization.

Most real-world AI strategies end up being a blend of all three across different capabilities. The goal isn’t to pick one, it’s to make the right choice for each AI capability in your product.

The Three-Lens Decision Framework

Lens 1: Strategic Differentiation

The first and most important question: does this AI capability create meaningful competitive differentiation for your product?

Not every AI feature needs to be a moat. Some AI capabilities are table stakes, they need to exist, but they don’t define your competitive advantage. Others are core differentiators that, if done well, create compounding advantages over time.

High Differentiation → Build

If the AI capability is central to your value proposition and the quality of that capability directly impacts customer retention and willingness to pay, you should build. Custom-built AI capabilities create three types of moats:

• Data moats: Your proprietary data makes the model better than anything a competitor could buy off the shelf

• Experience moats: The AI behavior is so deeply integrated into your product’s UX that it can’t be replicated by swapping in a generic API

• Feedback loop moats: User interactions continuously improve the model, creating a flywheel that widens your advantage over time

Medium Differentiation → Partner

If the capability matters to your users but the underlying AI technology isn’t your core advantage, your differentiation comes from domain expertise, data, or workflow integration rather than the model itself, then partnering makes sense. You contribute the domain knowledge; the AI partner contributes the model expertise.

Low Differentiation → Buy

If the capability is expected by users but doesn’t influence their choice between you and a competitor, buy it. Internal chatbots, document summarization, basic content generation, spam filtering, these are solved problems. There’s no strategic advantage in building them from scratch.

The Differentiation Test: Ask yourself: ”If a competitor used the exact same AI provider we’re considering, would our product still be meaningfully different?” If yes, buying is fine. If no, you need to build or partner.

Share Mastering Product

Lens 2: Organizational Capability

The second lens is an honest assessment of your team’s ability to execute on each option.

Building AI capabilities requires skills that many product organizations don’t have and that are expensive and time-consuming to develop. Be brutally honest about where your team stands:

| Capability | Build Requires | Buy Requires | Partner Requires |

| ML/AI Engineering | Deep expertise (hiring 6-12 months) | Basic API integration skills | Moderate; ability to collaborate with external ML teams |

| Data Infrastructure | Robust training/serving pipelines | Basic data formatting | Shared data pipelines; governance maturity |

| Domain Expertise | Internal subject matter experts | Ability to evaluate vendor quality | Ability to translate domain knowledge for AI teams |

| Ongoing Investment | Continuous model monitoring, retraining, optimization | Vendor management, cost monitoring | Relationship management, joint roadmap planning |

The Capability Gap Audit: For each AI capability you’re considering, map your current team against these requirements. If you’re more than two major hires away from being able to build, the time cost alone may make building impractical for your current planning horizon.

A modern nuance: AI coding assistants like Cursor, GitHub Copilot, and Claude Code have meaningfully lowered the bar for building AI-powered features. A strong full-stack engineer with good AI tooling can now prototype and ship AI features that previously required a dedicated ML engineer. Factor this into your capability assessment, but don’t overestimate it. Prototyping an AI feature and operating it reliably at scale are very different challenges.

Lens 3: Total Cost of Ownership

The third lens is financial, but it extends well beyond the obvious costs.

Build Costs (Often Underestimated):

• Hiring and retaining ML talent (market rates are still 1.5-2x general engineering)

• GPU/compute infrastructure for training and inference

• Data labeling, cleaning, and pipeline maintenance

• Ongoing model monitoring, evaluation, and retraining

• Opportunity cost: your engineering team building AI infrastructure instead of product features

Buy Costs (Often Underestimated Differently):

• Per-API-call pricing that scales with usage (this can spike dramatically)

• Vendor lock-in and switching costs

• Limited customization leading to workarounds and technical debt

• Dependency on vendor’s roadmap, pricing changes, and reliability

• Data privacy and compliance exposure from sending data to third parties

Partner Costs (The Middle Ground):

• Initial co-development investment

• Ongoing revenue share or licensing

• Coordination overhead and slower iteration cycles

• Shared IP ownership complexity

• Dependency on partner’s viability and priorities

The 3-Year TCO Model: Don’t make this decision based on Year 1 costs alone. Model the total cost over 3 years, including scaling scenarios. API costs that seem cheap at 1,000 daily calls can become prohibitive at 100,000. Conversely, build costs that seem expensive upfront amortize significantly if the capability becomes central to multiple product lines.

The Decision Matrix: Putting It All Together

Here’s how the three lenses combine into a decision:

The last row is critical. When the strategic value of an AI capability is unclear, which is more often than teams admit start by buying. Use a third-party API to validate that the capability actually moves your product metrics before investing in building or partnering. This is the Discovery Sprint mindset applied to AI capabilities: validate before you commit.

The AI Capability Portfolio

In practice, most products need a portfolio approach, different decisions for different capabilities. Here’s what a healthy AI capability portfolio might look like for a mid-stage B2B SaaS product:

Build (1-2 capabilities):

• Your core predictive model that uses proprietary customer data

• A recommendation engine whose quality directly impacts retention

Partner (1-2 capabilities):

• Natural language understanding tuned to your industry’s vocabulary

• Computer vision capability requiring domain-specific training data

Buy (3-5 capabilities):

• In-app chat assistant (powered by a foundation model API)

• Document summarization and extraction

• Content moderation

• Search and semantic retrieval

• Email and notification personalization

The key insight: most of your AI capabilities should be bought, not built. The buy category should always be the largest. Teams that try to build everything end up building nothing well.

When to Revisit the Decision

The build/buy/partner decision isn’t permanent. Set explicit triggers for revisiting:

Move from Buy to Build when:

• The AI capability has proven its strategic value through metrics

• API costs are exceeding what a custom solution would cost to operate

• You need customization that the vendor can’t or won’t provide

• You’ve accumulated proprietary data that would significantly improve a custom model

Move from Build to Buy when:

• Maintaining the custom model is consuming disproportionate engineering time

• Commercial alternatives have caught up to your custom model’s quality

• Your team’s ML talent is being pulled toward more strategic work

• The capability has become table stakes in your market

Move from Partner to Build when:

• The partnership has validated the strategic importance of the capability

• Your team has developed enough ML capability through the partnership to go independent

• The partner’s incentives are diverging from yours

Common Mistakes in AI Strategy

1. Building for Ego, Not Strategy

“We should build our own model” often comes from engineering pride rather than strategic analysis. The most sophisticated AI teams in the world, including many at Google, Meta, and Amazon, use third-party models for non-core capabilities. If it’s good enough for them, it’s good enough for you.

2. Ignoring the Speed Advantage of Buying

In a market where AI capabilities are evolving monthly, being 6 months late with a custom-built solution often means being 6 months late to learn what your users actually want. Buy first, learn fast, build later if the data justifies it.

3. Underestimating Vendor Risk

When you buy, you inherit your vendor’s risks: pricing changes, API deprecation, data handling controversies, outages. Mitigate this by maintaining abstraction layers in your codebase. Never hardcode a single AI vendor’s API throughout your product. Use adapter patterns that let you swap providers with minimal refactoring.

4. Treating “AI Strategy” as a One-Time Decision

The AI landscape is shifting faster than any technology wave in recent memory. What was build-worthy 12 months ago may now be available as a commodity API. What was impossible to buy 6 months ago may now be a turnkey solution. Review your AI capability portfolio quarterly.

5. Forgetting About Data Governance

Whichever path you choose, data governance is non-negotiable. Before sending customer data to any external AI provider, evaluate: What data are you sharing? Where is it stored? Who else can access it? Does it comply with your users’ expectations and your regulatory requirements? This isn’t a nice-to-have, it’s a prerequisite.

Getting Started: Your First AI Capability Decision

If you’re making your first significant AI capability decision, here’s a practical starting sequence:

1. List all AI capabilities on your current or planned roadmap. Be specific, ”add AI” is not a capability. “Generate personalized onboarding recommendations based on user behavior” is.

2. Score each capability on the differentiation scale (1-5). Be honest about which ones actually drive competitive advantage versus which ones are just expected.

3. Audit your team’s capability for each item. Do you have the skills to build? To manage a vendor? To collaborate with a partner?

4. Model the 3-year TCO for your top 2-3 capabilities. Compare build vs. buy vs. partner for each.

5. Default to buy for anything scoring below 3 on differentiation. Validate first, invest later.

6. For high-differentiation capabilities, build a 90-day plan that starts with a bought or partnered proof of concept before committing to a full build.

Conclusion: Strategy Before Technology

The most important AI product decision you’ll make isn’t which model to use or which framework to adopt, it’s how you structure your approach to AI capabilities across your product portfolio. Build where it creates lasting differentiation. Partner where you need domain-specific AI but lack the ML expertise. Buy everything else.

The companies winning with AI aren’t the ones building the most models. They’re the ones making the smartest decisions about where to invest their limited resources. In a landscape where foundation model capabilities improve quarterly and new AI tools launch weekly, your competitive advantage increasingly comes not from the AI technology itself, but from how well you integrate it into a product experience your users can’t get elsewhere.

Be strategic. Be honest about your capabilities. And above all, be willing to change your mind as the landscape evolves.

Stay tuned for Part 2 of this series: “The PM’s Guide to Building Products on Top of LLMs” where we’ll go deep on the tactical side of shipping AI-powered features, from prompt engineering to evaluation frameworks to UX patterns that actually work.

How is your team approaching the build vs. buy decision for AI? Leave a comment below.

Leave a comment

Welcome to this week's edition of Mastering Product! Today, we're tackling one of the most common traps in product management: spending months building something your customers never asked for. I'm going to walk you through a framework I've used and refined over many years leading product teams, the Discovery Sprint. It's a structured 2-week process that helps teams go from fuzzy opportunity to validated direction with speed and confidence. And with the AI tools available to product teams today, each phase of this sprint can move faster and deeper than ever before. Let's dive in.

The Validation Gap

Here's a scenario I've seen play out too many times: a product team spends an entire quarter building a feature based on a compelling internal thesis, ships it, and then watches the adoption numbers flatline. The post-mortem reveals what everyone suspected but nobody tested, the problem they were solving wasn't the problem users actually had, or it wasn’t as big as they thought it is.

Teams that run structured discovery consistently outperform those that don't, not by a small margin, but by a factor of 3x in terms of features that hit their success metrics. The ones that take two weeks to validate before building save months of wasted development effort.

The root cause is always the same: teams jump from opportunity to solution without a disciplined validation step in between.

The Discovery Sprint fills that gap. It's not a replacement for continuous discovery or long-term research programs. It's a focused, time-boxed intervention you deploy when you need to make a high-stakes product decision and don't yet have sufficient evidence to do so confidently.

What's changed in 2025-2026 is the toolkit. AI has compressed what used to take days into hours, interview synthesis, competitive research, rapid prototyping, even preliminary concept testing. The discipline of the sprint still matters. But the speed at which you can gather and act on evidence has fundamentally shifted.

When to Deploy a Discovery Sprint

Not every decision warrants a 2-week sprint. Use this framework when:

• The stakes are high: You're committing engineering resources for a quarter or more

• Uncertainty is high: You have strong opinions but weak evidence (Level 1-2 on the Pyramid of Evidence)

• Alignment is low: Stakeholders disagree on the problem, the solution, or the priority

• The opportunity is ambiguous: Customer signals are mixed or contradictory

A good rule of thumb: if a feature would take more than 6 weeks of engineering effort, it should survive a Discovery Sprint before entering the backlog. This single policy can prevent dozens of wasted initiatives per year.

The Discovery Sprint Framework: 2 Weeks, 5 Phases

The Discovery Sprint compresses the essential elements of product discovery into a structured 2-week cadence. Each phase builds on the previous one, creating an escalating body of evidence. This 2 week cadence can be reduced drastically with AI, read below to see how.

Phase 1: Frame (Days 1-2)

The first two days are about getting crystal clear on what you're trying to learn—not what you're trying to build.

Key Activities:

1. Problem Statement Workshop: Bring the product trio (PM, designer, tech lead) together to articulate the problem in a single sentence. Use this template: "We believe [user segment] struggles with [problem] when trying to [goal], which results in [negative outcome]."

2. Assumption Mapping: List every assumption embedded in your current thinking. Categorize them into:

   • Desirability assumptions: Do users actually want this?

   • Viability assumptions: Does this create business value?

   • Feasibility assumptions: Can we actually build this?

3. Risk Prioritization: Rank assumptions by two dimensions, how critical they are to the initiative's success, and how little evidence you currently have. The assumptions that score high on both dimensions become your sprint's investigation targets.

4. Success Criteria Definition: Define what "validated" and "invalidated" look like before you gather any evidence. This prevents post-hoc rationalization.

Output: A Discovery Sprint Brief containing your problem statement, the top 3-5 riskiest assumptions, and clear validation/invalidation criteria for each.

How AI accelerates this phase: Use tools like Miro AI or FigJam AI to facilitate assumption mapping workshops, they can auto-cluster sticky notes, suggest missing assumption categories, and generate initial problem statement drafts from messy brainstorm inputs. You can also feed your product brief into Claude and ask it to play the role of a critical product reviewer: "What are the top 10 assumptions embedded in this product brief that we haven't validated?" You'll be surprised how many blind spots surface in minutes.

Phase 2: Gather (Days 3-5)

With your riskiest assumptions identified, you now go find evidence. This phase uses a multi-method approach because no single evidence source is sufficient.

Key Activities:

1. Existing Data Audit: Before collecting anything new, mine what you already have analytics data, support tickets, previous research, NPS verbatims, session recordings. You'd be surprised how often the answer is already sitting in your data warehouse.

2. User Interviews (5-8 participants): Conduct problem-focused interviews. The goal is to understand the user's world, not to pitch your solution. Use the "tell me about the last time..." technique to uncover actual behaviors rather than hypothetical preferences.

3. Competitive & Analogous Analysis: Study how others have solved similar problems not just direct competitors, but analogous solutions in adjacent domains.

4. Quantitative Signal Check: Pull relevant behavioral metrics. What are users actually doing today that relates to this problem space?

Output: An Evidence Board organized by assumption, showing what you found across each evidence source.

How AI accelerates this phase: This is where AI tools create the biggest time savings:

• Interview analysis: Record your user interviews (with consent) and run the transcripts through Dovetail AI or Grain. These tools auto-tag themes, extract key quotes, and surface patterns across multiple interviews in minutes instead of hours. You can also paste raw transcripts into Claude and ask: "What are the top 5 unmet needs expressed across these interviews, ranked by frequency and emotional intensity?"

• Competitive analysis at scale: Use Perplexity or Claude with web search to map how competitors and analogous products solve the problem you're investigating. What used to take a full day of browsing can now be a 30-minute structured analysis. Ask: "How do the top 10 [category] products handle [specific problem]? Compare their approaches in a table."

• Support ticket mining: Feed a sample of support tickets or NPS verbatims into an LLM and ask it to categorize complaints, identify recurring themes, and quantify frequency. Tools like MonkeyLearn or simple Claude prompts can process hundreds of tickets in minutes.

• Synthetic user validation: Tools like Synthetic Users let you simulate early user reactions to problem statements before you invest time in live interviews. These aren't a replacement for real users—but they're a useful directional signal that can sharpen your interview guide.

Pro Tip: Assign each evidence source a confidence weight using the Pyramid of Evidence levels. An insight supported by behavioral analytics (Level 4) carries more weight than one based solely on user interviews (Level 3), which in turn outweighs competitive analysis (Level 2). AI-generated insights from synthetic users sit at Level 1-2 at best, useful for hypothesis generation, never for validation.

Phase 3: Synthesize (Days 6-7)

This is the most intellectually demanding phase and the one teams most often skip. Gathering evidence without synthesizing it is just data hoarding.

Key Activities:

1. Assumption Verdict Review: For each of your target assumptions, lay out all gathered evidence and make a call: Validated, Invalidated, or Inconclusive. Apply your pre-defined criteria from Phase 1.

2. Pattern Triangulation: Look for insights confirmed by multiple evidence types. A finding that shows up in user interviews AND behavioral data AND competitive analysis is far more reliable than one that appears in a single source.

3. Contradiction Analysis: Pay special attention to evidence that conflicts. These contradictions often reveal the most interesting insights. A classic example: users say they want more options (qualitative) but behavioral data shows that adding options reduces conversion. The synthesis often reveals that users want better defaults, not more controls.

4. Opportunity Reframing: Based on what you've learned, reframe the original problem statement. It's common for the real opportunity to be adjacent to but different from where you started.

Output: A Synthesis Document with assumption verdicts, key insights, and an updated problem statement.

How AI accelerates this phase: Feed all your evidence (interview summaries, data findings, competitive analysis) into Claude or ChatGPT as a single context and ask it to identify contradictions, patterns, and gaps. Prompt example: "Here is evidence from 3 sources about [assumption]. Source 1 suggests X, Source 2 suggests Y, Source 3 suggests Z. Where do these converge? Where do they contradict? What's the most likely truth?"

A critical warning here: AI is excellent at pattern-matching across large bodies of evidence. It is terrible at judgment calls. The synthesis tool should surface patterns and contradictions—but the product trio makes the verdict. Never outsource assumption verdicts to an AI. The team's contextual understanding of the business, users, and technical constraints is irreplaceable.

Phase 4: Prototype & Test (Days 8-10)

Now and only now do you start exploring solutions. This phase is about testing direction, not building product.

Key Activities:

1. Solution Sketching: Generate multiple solution concepts. Aim for at least three distinct approaches. Involve the full product trio to ensure diversity of thinking.

2. Rapid Prototyping: Build lightweight prototypes of the top 1-2 concepts. These should be the minimum fidelity needed to test your key assumption, sometimes that's a clickable mockup, sometimes it's a spreadsheet, sometimes it's a concierge version you run manually.

3. Concept Testing (5-8 participants): Put prototypes in front of users and observe. Focus on:

   • Does the user understand what this is?

   • Does it address the problem they actually have?

   • Would they use this in their real workflow?

   • What's missing or confusing?

4. Feasibility Check: Have your tech lead assess the top concept's technical complexity, dependencies, and risks.

Output: Tested prototype(s) with user feedback, a feasibility assessment, and a recommended direction.

How AI accelerates this phase: This is where the 2025 AI toolkit has been transformative:

• From sketch to prototype in hours: Tools like Replit, Bolt, and Lovable can generate working front-end prototypes from text descriptions or rough wireframes. Describe your concept in natural language and get a clickable prototype you can test with real users in a single afternoon instead of 2-3 days of designer/developer time.

• AI-assisted design: Figma AI features and plugins can generate UI variations from a single design concept, helping you explore multiple directions without starting from scratch each time.

• Unmoderated concept testing: Tools like Maze allow you to set up unmoderated prototype tests that users complete asynchronously. Combined with AI-generated prototypes, you can go from concept to user feedback within 24 hours.

• Feasibility estimation: Have your tech lead use AI coding assistants like Cursor or GitHub Copilot to spike on the most uncertain technical components. A few hours of AI-assisted exploration can reveal complexity that would otherwise only surface weeks into development.

The mindset shift: With AI prototyping tools, the bottleneck is no longer "how fast can we build a prototype?" It's "how clearly can we define what to test?" This makes the Frame and Gather phases even more critical. Teams that rush to prototype with AI tools before framing the right question just build the wrong thing faster.

Phase 5: Decide (Days 9-10)

The final phase converts your evidence into a decision and a plan.

Key Activities:

1. Evidence-Based Recommendation: Present a structured recommendation using this format:

| Element | Detail |

|---------|--------|

| **Recommendation** | Proceed / Pivot / Kill |

| **Confidence Level** | High / Medium / Low |

| **Key Evidence** | Top 3 supporting findings |

| **Remaining Risks** | What we still don’t know |

| **Next Steps** | Specific actions with owners and timelines |

2. Stakeholder Alignment Session: Walk key stakeholders through the evidence journey not just the conclusion. When people see the evidence path, they're far more likely to support the decision, even if it contradicts their initial expectations.

3. Scope Definition: If proceeding, define the smallest meaningful first release (what I call the "evidence-based MVP") that will generate the next layer of learning.

4. Measurement Plan: Define the success metrics, tracking approach, and decision points for the build phase.

Output: A Sprint Decision Document and, if proceeding, an evidence-based MVP scope.

How AI accelerates this phase: Use AI to draft your Sprint Decision Document. Feed it the synthesis findings, assumption verdicts, and prototype feedback, and ask it to structure a stakeholder-ready recommendation. Tools like Gamma or Beautiful.ai can turn your findings into a polished presentation deck in minutes. But remember: the recommendation itself must come from the team, not the tool.

The Discovery Sprint Canvas

To keep the sprint organized, I use a one-page canvas that the team references throughout the two weeks:

| Section | Content |

|---------|---------|

| **Problem Statement** | Single-sentence problem definition |

| **Target Assumptions** | Top 3-5 riskiest assumptions |

| **Evidence Sources** | What data/research you’ll gather |

| **Validation Criteria** | Pre-defined pass/fail for each assumption |

| **Key Findings** | Updated as evidence comes in |

| **Assumption Verdicts** | Validated / Invalidated / Inconclusive |

| **Recommended Direction** | Proceed / Pivot / Kill with rationale |

| **Evidence-Based MVP** | Smallest first release that drives learning |

This canvas serves as both a planning tool and a communication artifact. Pin it in your team's Slack channel or Notion workspace and update it daily. It keeps the sprint focused and transparent.

The AI-Augmented Discovery Stack

Here's a quick reference of AI tools mapped to each sprint phase:

| Phase | Tool | What It Does |

|-------|------|-------------|

| **Frame** | Claude / ChatGPT | Stress-test assumptions, generate blind-spot analysis |

| **Frame** | Miro AI / FigJam AI | Facilitate and cluster brainstorm workshops |

| **Gather** | Dovetail AI / Grain | Auto-analyze interview transcripts |

| **Gather** | Perplexity / Claude | Rapid competitive and market analysis |

| **Gather** | Synthetic Users | Directional signal before live interviews |

| **Synthesize** | Claude / ChatGPT | Cross-reference evidence,surface contradictions |

| **Prototype** | v0 / Bolt / Lovable | Generate working prototypes from descriptions |

| **Prototype** | Cursor / Copilot | Spike on technical feasibility |

| **Test** | Maze | Unmoderated, asynchronous concept testing |

| **Decide** | Gamma / Beautiful.ai | Auto-generate stakeholder presentations |

A word of caution: AI tools accelerate each phase, but they don't replace the thinking that connects them. The sequence Frame before you Gather, Gather before you Synthesize, Synthesize before you Prototype exists for a reason. I've watched teams use AI to prototype in hours, only to discover they were prototyping the wrong thing because they skipped framing. Speed without direction is just expensive chaos.

Common Pitfalls (And How to Avoid Them)

After running dozens of Discovery Sprints across different organizations, I've seen the same mistakes repeatedly:

1. Solution Bias in the Frame Phase

Teams jump to "how might we build X?" instead of "what problem are we solving?" The fix: ban solution language in the first two days. If someone mentions a feature, redirect them to the underlying need.

2. Confirmation Bias in Evidence Gathering

Teams unconsciously seek evidence that supports their preferred direction. The fix: assign a "devil's advocate" role to someone in each interview and data review session. Their job is to actively look for disconfirming evidence. You can also prompt AI with: "Give me the strongest argument against this assumption" LLMs are surprisingly good at playing devil's advocate.

3. Skipping Synthesis

Teams collect evidence and jump straight to prototyping without synthesizing. The fix: make the Synthesis phase a formal, time-boxed session with the full product trio. No prototyping until assumption verdicts are complete.

4. Over-Scoping the Prototype

Teams build too much fidelity into prototypes, wasting time and creating attachment to a specific solution. The fix: set a hard rule if the prototype takes more than one day to build, it's too complex. With AI tools like v0 or Bolt, there's no excuse to spend more than a few hours on a testable concept.

5. Ignoring the "Kill" Decision

Teams treat Discovery Sprints as a validation exercise rather than a genuine learning exercise. The most valuable outcome is sometimes "we should NOT build this." The fix: celebrate kill decisions. A well-evidenced kill can save hundreds of thousands in development costs and free the team to pursue higher-impact opportunities.

6. Over-Trusting AI Outputs

This is a newer pitfall. Teams feed messy data into an LLM, get a confident-sounding synthesis, and treat it as ground truth. AI-generated insights are a starting point for discussion, not a conclusion. Always verify AI-surfaced patterns against your raw evidence. If the AI claims a pattern exists, go check the transcripts yourself.

Measuring Discovery Sprint Effectiveness

To continuously improve your discovery practice, track these metrics:

| Metric | What It Measures | Target |

|--------|-----------------|--------|

| **Assumption Hit Rate** | % of assumptions correctly predicted by the sprint | >70% |

| **Decision Confidence** | Team’s confidence in the go/no-go decision (1-10) | >7 |

| **Build Success Rate** | % of post-sprint builds that hit success metrics | >60% |

| **Time to Decision** | Calendar days from sprint start to decision | ≤10 |

| **Kill Rate** | % of sprints resulting in a kill decision | 20-40% (healthy range) |

If your kill rate is below 20%, you're probably only running sprints on safe bets. If it's above 40%, your opportunity identification process may need attention.

Getting Started: Your First Discovery Sprint

If you've never run a Discovery Sprint before, here's how to start:

1. Pick a live decision. Choose an upcoming initiative where the team has high conviction but low evidence. This gives you a real scenario with genuine stakes.

2. Assemble the core trio. You need a PM, a designer, and a tech lead committed for the full two weeks. Other stakeholders participate in specific sessions but don't need to be full-time.

3. Block the calendar. Protect the sprint time aggressively. The biggest enemy of discovery is "just this one meeting." Two focused weeks beats two months of fragmented effort.

4. Set up your AI toolkit. Before the sprint starts, make sure the team has access to the tools they'll need an LLM for analysis, a prototyping tool, and a user testing platform. Don't waste Day 1 on procurement.

5. Set expectations. Be explicit with stakeholders that the sprint may result in a kill decision, and that this is a valid, valuable outcome.

6. Use the canvas. Pin it in Slack, update it daily. It creates accountability and visibility.

Discovery as a Product Superpower

The best product teams share one trait: they treat validation as a non-negotiable step, not a nice-to-have. The Discovery Sprint makes this practical by giving teams a repeatable, time-boxed process that fits into real-world product development cadences.

Two weeks of structured discovery can save months of building the wrong thing. AI tools make those two weeks dramatically more productive but they don't replace the discipline of asking the right questions first. The teams that discover fast, build with conviction. The teams that skip discovery, build with hope.

Hope is not a product strategy. And in 2026, with the tools available to you, there's no excuse for it.

Have you used AI tools in your product discovery process? What worked and what didn't? Reply to this email to share your experience I read every response and often feature reader insights in future newsletters.

Leave a comment

The past decade of product management was dominated by a single North Star: growth. Fueled by allot of venture capital and low interest rates, tech companies prioritized user acquisition, engagement, and retention above all else, often with profitability as a distant future concern.

In my opinion, that era has ended!

I've watched this shift happen in a few cases, companies that I advise and in industry news and it's been both surprising, in terms of how fast things shifted and also how necessary. The companies are are no longer asking "How fast can we grow?" but rather "How can we grow sustainably?" The difference between those two questions is everything.

Today's economic realities demand a more balanced approach. Investors, boards, and executives are asking tougher questions about unit economics, payback periods, and paths to profitability. Product teams accustomed to optimizing solely for growth and engagement are being asked to deliver revenue impact, often without sacrificing the growth metrics they've been measured on for years.

This isn't about abandoning growth. It's about adopting what I call a "revenue-centric product strategy" that thoughtfully balances growth initiatives with profitability drivers1.

The Ground Has Shifted Beneath Us

Let me paint you a picture of how dramatically things have changed. Rising interest rates have fundamentally altered the economics of tech companies. When capital was nearly free, the present value of distant future profits justified years of losses. Today's higher costs of capital demand closer-term returns.

Think of Uber's journey. Their 2019 IPO prospectus literally stated “We expect our operating expenses to increase significantly in the foreseeable future, and we may not achieve profitability.” Fast forward to 2023, and their investor communications center on "Profitable growth at scale." This isn't just corporate speak, it reflects both market maturity and completely transformed investor expectations.

The market has reset expectations about what companies are worth, with greater emphasis on sustainable unit economics and profitability. Buy-now-pay-later provider Affirm saw its valuation drop from over around $28 billion to under $3 billion as interest rates rose and the market recalibrated expectations for fintechs without clear paths to profitability (it has recovered to about $19 Billion in 2025).

After years where growth could hide fundamental business challenges, there's more focus on durable business models and sustainable competitive advantages. Netflix's transition from subscriber growth at all costs to a more balanced approach involving ad-supported tiers, password-sharing crackdowns, and content efficiency demonstrates this shift to business fundamentals.

A New Framework for Product Thinking

A revenue-centric product strategy doesn't abandon growth—it integrates revenue and profitability considerations into your product thinking at every level. The framework I've developed centers on three core principles.

First, segment by revenue potential instead of treating all users equally. You have current high-value users who generate significant revenue, potential high-value users who match the profile but aren't monetizing fully, value-constrained users who derive value but have legitimate constraints on monetization, and low-probability users unlikely to generate significant revenue in the foreseeable future.

Slack evolved their product strategy from treating all workspace users similarly to identifying "economic buyers" within organizations and developing specific features for them. This segmentation approach increased conversion to paid plans without sacrificing overall user growth.

Second, evaluate initiatives across a Revenue Impact Matrix with two dimensions: revenue impact timeline and revenue impact mechanism. Timeline includes immediate impact within a quarter, near-term impact within a year, and long-term impact beyond a year. Mechanism covers direct revenue through pricing and packaging, conversion from free to paid, retention of paying customers, and expansion of revenue from existing customers.

Third, create a profitability-adjusted roadmap that adds economic profile as a critical third dimension alongside traditional impact and effort considerations. By adding this dimension, you can make more detailed prioritization decisions that balance growth, user experience, and financial health.

Five Strategies That Actually Work

The first strategy is value pathway optimization. Instead of optimizing isolated conversion points, map and optimize the entire pathway from initial value to revenue. Map value moments where users realize significant value, connect value to monetization through natural transitions, reduce friction in revenue flows, and measure value-to-revenue velocity.

Notion observed that users who created multiple different types of content were more likely to convert to paid plans. Instead of immediately pushing free users to upgrade, they focused on helping users discover diverse use cases—accelerating the "value realization" that naturally leads to conversion.

In her SaaStr talk, Notion’s CRO Olivia Nottebohm explains that early on Notion “put templates on our website so that users could quickly get into the flow of the product and immediately understand how they could use it, how they could find the usability quickly and how that product was going to work for them.” In other words, instead of gating features behind paywalls, they leaned into a gallery of diverse, community-created templates, spanning docs, wikis, project boards, calendars, etc.—so users would experience multiple distinct use cases right away.

The second strategy involves pricing and packaging innovation. Rethinking how you package and price your product can often deliver faster revenue impact than new feature development. Structure tiers around distinct use cases and user segments, design packages that naturally expand as customer usage grows, thoughtfully distribute features across tiers based on user willingness to pay, and incorporate consumption-based elements that scale with value delivered.

Airtable transformed their business by shifting from simple per-user pricing to a sophisticated model combining user seats, workflow automations, and interface usage. This approach better captured value from different customer segments while creating natural expansion paths.

The third strategy focuses on targeted feature development. Not all features are created equal from a revenue perspective. Prioritize conversion catalysts that address reasons users hesitate to pay, expansion enablers that increase usage and justify higher tiers, retention strengtheners that reduce churn risk for high-value segments, and revenue accelerators that shorten the time from initial use to payment.

The fourth strategy builds revenue experimentation systems. Apply the same experimental repetition to revenue that you apply to product experience through A/B testing infrastructure for pricing, offer optimization, revenue feature testing, and segment-specific experiments.

The fifth strategy involves value capture rebalancing. Ensure you're capturing appropriate value while delivering customer value through regular free-paid boundary reviews, value-based feature prioritization, monetization timing optimization, and pricing power assessment.

Maintaining Balance

The most successful companies maintain balance between revenue focus and product vision through the 70/20/10 investment rule: 70% to optimizing current revenue streams, 20% to emerging opportunities with clear revenue potential, and 10% to exploratory initiatives that might open future revenue streams.

Rather than treating innovation as separate from revenue considerations, integrate them by connecting innovation initiatives to future revenue hypotheses, establishing clear graduation criteria for moving ideas from exploration to core roadmap, and setting explicit timelines for innovation initiatives to demonstrate revenue potential.

The Human Side of Change

Transitioning to a revenue-centric approach requires thoughtful change management, especially for teams accustomed to focusing solely on growth and engagement. Help your team understand that revenue isn't opposed to user value, it's a measure of sustainable value creation that enables continued investment in the product.

Atlassian frames their revenue growth not as a business goal but as an enabler of their mission to help teams work better together. This framing helps their product teams see revenue initiatives as aligned with, not opposed to, their user focus.

From day one, Atlassian’s corporate materials lead with their mission “to unleash the potential of every team” and only then discuss financials. For example, their S-1/424B4 filing opens by explaining the company was founded “to help software teams work better together” and presents revenue as a means to scale that mission, not the end goal itself

Incorporate revenue metrics into your definition of success without abandoning engagement and satisfaction metrics. Create balanced scorecards that combine user metrics, experience metrics, and revenue metrics.

What This Means for You

To begin implementing a more revenue-centric approach, assess your current state by examining how explicitly revenue considerations factor into your roadmap decisions, what percentage of your roadmap directly impacts revenue metrics, and how sophisticated your understanding of unit economics and revenue drivers is.

For quick wins in the next 30 days, create a simple revenue impact assessment for your current roadmap items, identify one high-potential pricing or packaging experiment to run, and partner with finance to build a basic revenue impact model for product decisions.

A revenue-centric product strategy isn't about sacrificing growth or user experience for short-term profit. It's about creating sustainable value that benefits both users and the business. By thoughtfully balancing growth initiatives with profitability drivers, you can build products that thrive in today's more demanding economic environment.

The most successful product leaders won't be those who simply chase revenue at all costs, they'll be those who find the sweet spot where user value and business value reinforce each other, creating virtuous cycles of sustainable growth.

What shifts have you made toward a more revenue-centric approach? What challenges have you encountered?

Leave a comment

"We should look at the data."

Sound familiar? If you've spent any time in product management, you've probably heard this phrase more times than you can count—maybe you've even said it yourself. And hey, it sounds smart, responsible, and totally professional. But here's the thing: most teams are absolutely drowning in data while somehow still starving for insights that actually help them make better decisions.

If you're a junior product manager, the world of product analytics probably feels pretty intimidating right now. You know data matters (everyone keeps telling you that), but turning a bunch of numbers into meaningful action? That's way harder than it looks. I've watched so many promising PMs get stuck right here—either avoiding data like the plague or getting completely lost in metrics without ever finding anything they can actually act on.

Let me share a practical approach to product analytics that's specifically designed for people early in their PM journey. This isn't about turning you into a data scientist overnight. It's about developing the kind of analytical thinking that separates the really exceptional product managers from everyone else.

Stop Staring at Dashboards: The Decision-First Approach

Here's the biggest mistake I see junior as well as some senior PMs make: they start with whatever data happens to be available instead of starting with the decisions they actually need to make. They'll spend hours clicking through dashboards, hoping some magical insight will just appear. Spoiler alert: it almost never works that way.

Instead, try what I call the "decision-first" approach:

Start with the specific decision you need to make → Figure out what information would actually help → Go find or create that specific information → Run the right analysis to extract insights → Connect those insights directly to action

Take Booking.com, for example. When a product team responsible for search experience and they wanted to improve their search-booking experience, that team doesn’t just start poking around at random metrics. They begin with specific decisions: Which parts of our booking flow should we redesign first? What exact friction points should we tackle? This focused approach guides everything they did with data, leading to targeted improvements that boosted conversion.

The Five Types of Questions Your Data Can Actually Answer

To make this decision-first approach work, you need to understand what kinds of questions analytics can realistically answer. I've found that pretty much every product analytics question falls into one of five buckets:

1. Descriptive: What's happening right now?

These are your baseline questions—the ones that help you understand what users are actually doing with your product.

Think questions like:

• How many users finished onboarding last month?

• What's the average time people spend in our app per session?

• Which features get used the most (and least)?

The techniques here are pretty straightforward: basic metrics tracking, breaking users into segments, and creating feature usage heat maps.

Pictory did this well- They used detailed user segmentation based on location, behaviors, industry, and job title to create an Ideal Customer Profile, resulting in a 16% increase in conversions and 15% reduction in churn

2. Diagnostic: Why is this happening?

Once you know what's happening, you naturally want to understand why.

Questions like:

• Why did our conversion rates tank after the last release?

• Why do users bail out at step 3 of checkout?

• Why do power users love feature X but completely ignore feature Y?

For this, you'll use funnel analysis, compare different user groups, look for correlations, and dive into user session recordings.

Duolingo noticed that many users felt too much pressure to maintain daily streaks, which led to frustration and drop-off. By redesigning their streak system so that completing just one lesson per day would maintain the streak, they made learning less stressful. This change resulted in a 40% increase in users maintaining a 7-day streak or more, significantly boosting retention and engagement.

3. Predictive: What's likely to happen next?

These questions help you get ahead of problems before they become real problems.

Like:

• Which users are probably going to churn next month?

• How will this feature change likely impact our key metrics?

• What usage patterns predict long-term retention?

You'll use trend analysis, retention cohort analysis, and when you have enough data, some predictive modeling.

Spotify discovered through data analysis that users with more diverse listening habits (listening to a wider variety of genres and artists) have significantly lower churn rates than users who listen to narrow, specialized content. Among the least active users, specialists churn at a rate 30 percentage points higher than the global average, while generalists churn only 5 percentage points above average. This insight helps Spotify understand which user segments are at higher risk of cancellation.

4. Comparative: Which option works better?

These help you choose between alternatives—super important for making good product decisions.

Questions like:

• Which design variant performs better for our target users?

• How do we stack up against industry benchmarks?

• Which user segment responds better to this feature?

This is where A/B testing, multivariate testing, and competitive benchmarking really shine.

Netflix famously tests multiple thumbnail images for the same content and sometimes sees conversion differences of 20-30% between variants. This comparative analysis directly shapes how they promote content to maximize engagement.

5. Prescriptive: What should we actually do?

These are the money questions—the ones that help you figure out your next moves based on everything you've learned.

Like:

• Which features should we prioritize in our next release?

• How should we change our onboarding flow to improve activation?

• Which user segments should we target with this new capability?

You'll use impact modeling, opportunity sizing, and data-informed prioritization frameworks.

Slack employs product analytics to segment users based on team size, industry, and usage patterns, enabling them to personalize communications, feature recommendations, and support interactions for different user groups. They combine user behavior analysis with A/B testing of user interfaces and feature implementations to measure impact on engagement. For instance, Slack experiments with different notification presentation methods to determine which approach leads to higher user responsiveness, then uses these insights to refine their notification system

Getting Your Analytics Foundation Right

Before you can extract meaningful insights, you need to set up the right foundation. Here's what every junior PM should establish:

Define Your North Star and Supporting Metrics

Start by getting crystal clear on:

• North Star Metric: The single most important metric that shows you're delivering value to users and achieving business success

• Supporting Metrics: The key metrics that actually drive your North Star

• Counter Metrics: Metrics you watch to make sure you're not improving your main metrics at the expense of other important stuff

Dropbox focuses on user retention as a core North Star in the highly competitive cloud storage market. They employ advanced analytics to track supporting metrics such as frequency of file uploads, sharing activities, and collaboration patterns. By understanding these behaviors, Dropbox segments users into different cohorts and tailors experiences for each group—frequent collaborators receive enhanced sharing features, while users who primarily use Dropbox for storage get improved file organization tools.

Get Your Metric Definitions Straight

For every important metric, document:

• Exactly what it means

• How it's calculated

• What "good" looks like

• Any known limitations

• Who's responsible for it

This prevents the super common problem where different team members interpret the same metrics completely differently.

Leading tech companies create detailed metric definition documents for every key metric, specifying exactly what each metric means, how it's calculated, what "good" looks like, any known limitations, and who's responsible for it. This prevents the common problem where different team members interpret the same metrics completely differently.

Practical Techniques That Don't Require a PhD in Data Science

With your foundation in place, here are specific analytical techniques that work great for PMs:

Funnel Analysis: Finding Where Users Get Stuck

Funnel analysis tracks users through a sequence of actions and shows you exactly where they drop off.

Here's how to use it:

1. Define the steps in your key user journeys

2. Calculate conversion rates between each step

3. Identify steps with unusually high drop-off rates

4. Dig deeper into those specific problem areas

Cohort Analysis: Understanding How Users Evolve

Cohort analysis groups users based on when they started using your product and tracks their behavior over time.

How to make it work:

1. Group users by when they joined (weekly or monthly cohorts)

2. Track key metrics for each cohort over time (retention, engagement, etc.)

3. Compare cohorts to spot trends or improvements

4. Use cohort analysis to measure the real impact of product changes

Segmentation: Finding Patterns Across Different User Groups

Segmentation means dividing your user base into meaningful groups to identify differences in behavior and needs.

Here's the process:

1. Identify potential ways to segment (acquisition source, user role, usage frequency, etc.)

2. Compare key metrics across segments

3. Look for significant differences that suggest different needs or behaviors

4. Use these insights to tailor experiences for different segments

From Numbers to Stories: Making Data Compelling

Having data isn't enough—you need to transform it into compelling insights that actually drive action. Here's how:

Structure Your Data Story

When you're presenting analytics insights, follow this structure:

• Context: What question were we trying to answer and why does it matter?

• Observation: What pattern did we see in the data?

• Insight: What does this tell us about user behavior or product performance?

• Action: What specific steps should we take based on this insight?

Visualize Effectively

Choose visualizations that actually highlight your key points:

• Line charts: For trends over time

• Bar charts: For comparing different categories

• Funnel charts: For conversion processes

• Scatter plots: For exploring relationships

• Heat maps: For engagement patterns

Keep it simple and focused on the main insight.

Effective data visualization guidelines emphasize clarity over complexity, using consistent color schemes where red indicates problems and green indicates positive outcomes, making insights immediately recognizable.

Avoiding the Traps That Trip Up Junior PMs

Being aware of these common pitfalls will help you build credibility fast:

Don't Confuse Correlation with Causation

Just because two metrics move together doesn't mean one causes the other. Look for natural experiments or A/B tests that actually isolate variables. Be careful with your language—say "associated with" rather than "caused" unless you have real causal evidence.

Watch Out for Selection Bias

Always consider who isn't in your dataset. Be particularly careful with feedback, survey responses, and power users, which often represent only a tiny segment of your user base.

Spotify initially thought their service was already effective for music discovery, focusing on features that worked well for early adopters and music enthusiasts within the company. However, they discovered this approach didn't serve mainstream "lean-back" users who lacked the time or knowledge that power users had. This led Spotify to shift from a model where users did the work by following people and playlists, to a recommendations-based model where the service does the work based on listening history.

Building Your Analytics Skills: A 30-Day Action Plan

Here's a practical plan to strengthen your analytics capabilities over the next month:

Days 1-7: Assessment and Foundation

• Identify your product's current North Star and supporting metrics

• Document any gaps or inconsistencies in measurement

• Schedule time with a data analyst to understand current capabilities

• Create a list of the top 5 decisions your team needs to make

Days 8-14: Data Exploration

• Learn to use your company's analytics tools

• Create basic dashboards for your key metrics

• Analyze one key user journey using funnel analysis

• Compare behavior across 2-3 key user segments

Days 15-21: From Data to Insights

• Identify one unexpected pattern in your product data

• Form a hypothesis about what's causing this pattern

• Design a simple test of your hypothesis

• Present your findings to your team for feedback

Days 22-30: Driving Action

• Connect your insights to a specific product decision

• Create a simple data story that makes the case for action

• Implement a measurement plan for your next feature

• Establish a weekly analytics review routine

The Real Goal: Better Decisions, Not Better Dashboards

Here's the thing—product analytics isn't really about mastering tools or memorizing techniques. It's about developing an analytical mindset that makes all aspects of your work better:

Ask better questions: Move from vague stuff like "How are users liking our product?" to specific, actionable questions like "Which user segments struggle with feature X, and what specific behaviors show us their difficulties?"

Get comfortable with uncertainty: Product data is always incomplete and imperfect. Learn to make good decisions with imperfect information while continuously improving your understanding.

Stay healthily skeptical: Question surprising results, check your assumptions, and look for alternative explanations before acting on data.

Balance data and intuition: Use data to inform decisions, not make them for you. The best product managers combine analytical insights with domain expertise and user empathy.

Your Analytics Journey Starts Now

As PM, developing strong analytics skills will absolutely accelerate your career growth. But remember—the goal isn't to become a data analyst. The goal is to make better product decisions that create real value for users and your business.

The most successful product managers I've mentored don't just report metrics—they transform data into insights and insights into action. They know which questions to ask, which analyses to run, which patterns to look for, and most importantly, how to tell compelling data stories that actually drive decisions.

By following the approaches in this article, you'll avoid the common traps of either ignoring data completely or getting totally lost in it. Instead, you'll develop the analytical mindset that turns data from a buzzword into a genuine superpower for your product career.

What analytics questions are you wrestling with right now in your product role? What obstacles have you faced in turning data into action? I'd love to hear about your experiences.

Leave a comment

The most consequential chart in global technology today may not show stock prices, GDP growth, or even semiconductor production—it shows electricity generation. As artificial intelligence transforms from experimental technology to critical infrastructure, the nations that can generate the most power will increasingly dictate the future of human civilization. The stark reality depicted in recent electricity generation data reveals a truth that policymakers and technologists are only beginning to grasp: the AI race is fundamentally an energy race.

The Exponential Energy Appetite of AI

Artificial intelligence systems, particularly large language models and training infrastructure, consume electricity at scales that would have been unimaginable just a decade ago. Training GPT-3 reportedly consumed approximately 1,287 MWh of electricity—enough to power 120 American homes for an entire year. GPT-4's training likely required several times more energy, and this represents just a single model from a single company.

The energy demands extend far beyond training. Each ChatGPT query consumes roughly 10 times more electricity than a Google search. As AI becomes embedded in everything from smartphones to autonomous vehicles to industrial systems, these individual consumption figures multiply across billions of daily interactions. Conservative estimates suggest that AI could account for 3-8% of global electricity consumption by 2030, with more aggressive projections reaching as high as 15-20%.

But these figures tell only part of the story. The real challenge lies not just in absolute consumption, but in the concentration of that consumption. AI training and inference require massive data centers operating at full capacity, creating unprecedented localized electricity demands. A single hyperscale AI data center can consume 100-300 megawatts continuously—equivalent to a small city.

China's Commanding Energy Position

The electricity generation chart reveals China's overwhelming advantage in what may be the most critical infrastructure race of the 21st century. China's electricity generation has surged from roughly 400 TWh in 1985 to over 10,000 TWh in 2024—a 25-fold increase that dwarfs every other nation and region.

This isn't merely about current capacity; it's about trajectory and capability. While the United States has maintained relatively flat electricity generation around 4,000-4,500 TWh over the past two decades, China has added the equivalent of the entire U.S. electricity grid multiple times over. Even more starkly, China currently adds electricity generation capacity equivalent to the entire United States' annual production every 18 months—a pace of infrastructure development that has no historical precedent. The European Union, despite its 27 member states, generates less than half of China's total output and shows limited growth potential given environmental constraints and public opposition to new power infrastructure.

China's energy dominance translates directly into AI capability. The nation can support massive AI training clusters that would strain the electrical grids of other countries. Chinese technology companies don't need to worry about power availability when designing their next-generation AI systems—a luxury that increasingly eludes their American and European competitors.

The Infrastructure Reality Check

The comfortable assumption in Silicon Valley and other Western tech hubs has been that superior algorithms, chip design, and software engineering would maintain competitive advantages in AI. This perspective fundamentally misunderstands the nature of modern AI development, which has shifted from clever algorithmic innovations to brute-force scaling of compute and data.

The scaling laws that govern AI performance are ruthlessly mathematical: model capability generally improves predictably with increased compute, data, and parameters. This means that the country that can deploy the most computational resources—which requires the most electricity—will likely develop the most capable AI systems.

Current data center construction reveals this reality starkly. The United States is struggling to find locations with sufficient electrical grid capacity for planned AI facilities. Major tech companies report that power availability, not real estate or workforce, has become the primary constraint on data center expansion. Permitting processes for new electrical generation can take 5-10 years, creating a structural disadvantage against countries with more centralized energy planning.

Meanwhile, China continues expanding both renewable and traditional electricity generation at unprecedented scales. The nation adds more solar capacity each year than most countries have in total, while simultaneously building new nuclear reactors and maintaining robust coal-fired generation for baseline power. To put this expansion in perspective: China adds electricity generation capacity equivalent to the entire United States' annual output every 18 months. This means that by the time Western nations complete environmental impact studies for a single power plant, China has added generation capacity exceeding that of entire developed nations. This diverse, rapidly expanding energy portfolio provides the foundation for AI infrastructure that other nations simply cannot match.

The Semiconductor Efficiency Mirage

A common counterargument suggests that advances in semiconductor efficiency could level the playing field—that better chips requiring less power per operation could compensate for limited electricity generation. While chip efficiency improvements are real and important, they're insufficient to overcome the fundamental scaling advantages that abundant electricity provides.

Moore's Law improvements in chip efficiency occur gradually over years and face physical limits as transistors approach atomic scales. Meanwhile, the scale of AI training runs increases exponentially, with leading models requiring 10-100 times more compute each generation. Even dramatic improvements in chip efficiency get overwhelmed by the exponential growth in model size and training requirements.

Furthermore, the most advanced semiconductor manufacturing remains concentrated in Taiwan and South Korea—regions with limited electricity generation capacity relative to demand. As AI chips become larger and more complex, they also become more power-hungry in absolute terms, even if they're more efficient per operation.

The stark reality is that you cannot run a massive AI training cluster on efficient chips alone—you need massive amounts of electricity, period. Efficiency improvements might reduce the gap slightly, but they cannot eliminate the fundamental advantage that abundant power generation provides.

Geopolitical Implications of Energy-Constrained AI

The electricity-AI nexus creates profound geopolitical implications that extend far beyond technology competition. Nations with limited electricity generation capacity may find themselves increasingly dependent on AI systems developed elsewhere, creating new forms of technological dependency.

Consider the implications for national security. Military AI systems, intelligence analysis, economic modeling, and strategic planning all require substantial computational resources. Countries that cannot generate sufficient electricity to run these systems domestically must either forgo advanced AI capabilities or rely on foreign providers—neither option offers strategic independence.

The economic implications are equally stark. As AI becomes embedded in manufacturing, logistics, financial services, and countless other sectors, countries with limited AI capabilities will find themselves at systematic disadvantages in productivity and innovation. The electricity constraint doesn't just limit AI development—it constrains the entire economy's ability to benefit from AI advancement.

European nations face a particularly acute version of this challenge. Environmental regulations, public opposition to new power plants, and complex multinational coordination make rapid electricity generation expansion extremely difficult. The European Union's electricity generation has remained essentially flat for years, even as AI demands explode. This creates a structural ceiling on European AI ambitions that no amount of regulatory framework or ethical guidelines can overcome.

The Coming Infrastructure Crisis

The timeline mismatch between AI development and electricity infrastructure creates an approaching crisis that most analysts underestimate. AI capability advances happen on software timelines—months to years. Electricity infrastructure operates on civil engineering timelines—decades.

Major AI labs are already planning models that will require exascale computing resources, potentially consuming as much electricity as small countries. These models are expected within 3-5 years. Meanwhile, building new power generation capacity typically requires 10-15 years from planning to operation, assuming no regulatory delays or public opposition.

This timeline mismatch means that countries not already expanding electricity generation will find themselves fundamentally constrained in AI development by the late 2020s. The window for addressing this infrastructure gap is rapidly closing, and most Western nations show little urgency in expanding generation capacity. Consider the mathematical impossibility: China adds the equivalent of total U.S. electricity production every 18 months, while the U.S. struggles to add meaningful capacity over entire decades. Even if the United States began an aggressive infrastructure program today, China would add multiple times America's total generation capacity before any new U.S. plants came online.

The United States faces additional complications from its aging electrical grid and fragmented utility structure. Even if sufficient generation existed, transmitting large amounts of power to data centers requires substantial grid upgrades that face their own regulatory and logistical challenges.

Strategic Responses and Implications

The electricity-AI connection demands fundamental reconsideration of national technology strategies. Countries serious about AI competition must treat electricity generation as a national security priority equivalent to semiconductor manufacturing or research funding.

This requires several strategic shifts. First, environmental regulations must be balanced against technological competitiveness. While renewable energy development should continue, countries may need to maintain or expand reliable baseline power generation to support AI infrastructure. Second, electrical grid modernization must accelerate to support concentrated, high-demand data center operations. Third, international cooperation on energy infrastructure may become necessary for smaller nations to maintain AI capabilities.

The private sector response is already visible in major technology companies' energy strategies. Microsoft, Google, Amazon, and Meta are all investing heavily in direct energy generation and long-term power purchase agreements. Some are exploring on-site nuclear reactors for data centers. These investments represent recognition that electricity access, not just chip access, determines AI capability.

The Path Forward

The intersection of electricity generation and AI development represents one of the most critical strategic challenges of the coming decades. Nations that recognize this connection early and invest accordingly will maintain technological leadership and economic competitiveness. Those that treat it as secondary to other technology policies will find themselves increasingly marginalized in the AI-driven economy.

China's commanding position in electricity generation provides a structural advantage in AI development that cannot be easily overcome through software innovations or chip efficiency improvements alone. The scale of this advantage—generating more than twice the electricity of the United States and European Union combined—creates possibilities for AI infrastructure deployment that other nations simply cannot match.

The window for addressing this infrastructure gap remains open, but it's closing rapidly. The decisions made in the next 5-10 years about electricity generation capacity will determine which nations lead AI development for decades to come. The chart showing global electricity generation isn't just an energy statistic—it's a preview of the AI-powered world order.

In an era where artificial intelligence increasingly determines economic productivity, military capability, and technological leadership, the nations that can generate the most electricity may indeed inherit the earth. The power behind the intelligence will ultimately determine who controls the intelligence itself.

Leave a comment

Few responsibilities strike more fear into the heart of a new product manager than being asked to "create the roadmap." It's no wonder—roadmaps sit at the intersection of strategy and execution, requiring you to balance stakeholder expectations, team capabilities, market needs, and business goals, all while providing clarity without overcommitting.

For junior product managers, this challenge is particularly daunting. You're expected to create a document that will guide work for months ahead, often before you fully understand all the moving pieces.

Having worked with many product managers through this process, I've developed a step-by-step approach to building your first roadmap—one that will earn stakeholder trust while giving your team the direction they need without painting you into a corner.

What a Roadmap Is (And Isn't)

Before diving into roadmap creation, let's clarify what we're actually building:

A roadmap is:

• A strategic communication tool that shows how near-term work connects to longer-term goals

• A prioritized view of opportunities your team will pursue

• A flexible guide that adapts as you learn more

• A tool for alignment across stakeholders

A roadmap isn't:

• A project plan or release schedule with fixed dates

• A list of feature commitments

• A comprehensive catalog of everything you might build

• A document that never changes

Many roadmap problems stem from confusion about these distinctions. For example, sales teams may treat roadmaps as commitment documents, while engineering might view them as fixed project plans. A key part of roadmap success is setting these expectations correctly from the start.

Industry example: Basecamp famously uses "betting table" language rather than "roadmap" to make clear that they're making educated bets on what to build next, not issuing guarantees—language that helps set appropriate expectations with all stakeholders.

Step 1: Gather Your Inputs

A good roadmap isn't created in isolation—it synthesizes inputs from multiple sources. Start by collecting:

Strategic Inputs

Company strategy: What are the organization's top-level goals for the year? Product vision: Where is your product headed in the longer term? Key metrics: What numbers are you responsible for moving?

Customer Inputs

User research: What problems and needs have you identified? Feature requests: What are users explicitly asking for? Usage data: How are people actually using your product? Customer feedback: What themes emerge from support tickets and sales conversations?

Recommended practice: Run monthly feedback synthesis sessions where you analyze patterns from user research, support tickets, and community forums before each roadmap planning cycle.

Market Inputs

Competitive analysis: What are competitors building? Industry trends: How is your market evolving? Technological developments: What new capabilities might you leverage?

Recommended practice: Check if your company maintains a living competitive analysis document that product teams review during roadmap creation to ensure their plans respond to market movements. If not available, well now you have an initiative to drive that will not only benefit you but the wider product team.

Implementation Inputs

Technical debt: What infrastructure work is required? Dependencies: What must happen before certain initiatives can begin? Team capacity: How many people-hours are realistically available? Team capabilities: What can your team execute effectively?

Industry example: Shopify product teams start roadmap planning by reviewing technical architecture documents with engineering leads to understand infrastructure needs that might affect feature sequencing.

Step 2: Create Your Strategic Framework

Before listing specific initiatives, establish the strategic foundation that will guide prioritization:

Define Your Planning Horizons

Different timeframes require different levels of specificity:

Now (Current quarter): Specific initiatives with clear scope Next (Following 1-2 quarters): Defined problem areas with general solution approaches Later (Beyond 6 months): Strategic themes and opportunity areas

Industry example: Atlassian uses a "Now, Next, Later" framework where items become progressively less specific as they move further into the future, giving teams flexibility to adapt to new information.

Establish Your Strategic Themes

Group potential work into 3-5 key themes that represent your major focus areas. These might be:

User-centered: Different user journeys or problems (e.g., onboarding, daily usage, advanced workflows) Strategic: Areas of strategic focus (e.g., monetization, expansion, acquisition) Architecture-based: Major system components (e.g., frontend experience, data layer, API)

Industry example: Slack organizes their roadmap around strategic themes like "speed and reliability," "enterprise security," and "platform expansion" that remain consistent even as specific initiatives evolve.

Define Success Metrics

For each strategic theme, define:

• What metrics will indicate success?

• How will you measure progress?

• What targets are you aiming for?

Recommended Practice: Every roadmap theme must have an explicit success metric paired with a target, creating clear criteria for evaluating potential initiatives. If your company uses OKRs, initiatives should link to a key result it is impacting.

Step 3: Prioritize Ruthlessly

With your inputs gathered and framework established, now comes the challenging part—deciding what actually makes it onto the roadmap.

Create Your Candidate Initiative List

List all potential initiatives from your input gathering, including:

• Feature ideas and enhancements

• Problem areas to explore

• Technical investments

• Experiments to run

Don't filter yet—aim for comprehensiveness.

Apply a Consistent Prioritization Framework

Evaluate each initiative using a consistent framework:

RICE Framework:

• Reach: How many users will this impact?

• Impact: How much will it improve their experience?

• Confidence: How certain are we about our estimates?

• Effort: How much work is required?

Calculate a RICE score by multiplying Reach × Impact × Confidence, then dividing by Effort.

Industry example: Intercom popularized the RICE framework and uses it to evaluate hundreds of potential initiatives each quarter, ensuring consistent prioritization criteria across different teams.

Alternative Framework: Weighted Shortest Job First (WSJF)

For teams following a more agile approach, consider using the WSJF method:

• Calculate the Cost of Delay (by examining business value, time criticality, and risk reduction)

• Divide that by job size or effort

• Prioritize the highest values first

This helps identify initiatives that deliver the most value for the least effort, particularly when dealing with technical debt or infrastructure work alongside customer-facing features.

Consider Your Portfolio Balance

Beyond raw prioritization scores, ensure your roadmap maintains balance across:

Time horizons: Quick wins vs. longer-term investments Risk profile: Safe bets vs. higher-risk experiments User segments: Different customer types or personas Business goals: Growth vs. retention vs. monetization

Industry example: Netflix maintains explicit portfolio targets for their roadmap—a certain percentage of work must address existing user needs, while another portion explores new opportunities, ensuring both optimization and innovation.

Make the Hard Cuts

Roadmaps are as much about what you don't include as what you do. Be prepared to:

• Cut good ideas that aren't great

• Defer work that doesn't align with current priorities

• Say no to stakeholder pet projects that don't rank highly

• Acknowledge things that won't happen this planning cycle

Industry example: Spotify uses a "painless postponement" technique where ideas not making the cut go into a visible "not now" list that's revisited each planning cycle, acknowledging good ideas while maintaining focus.

Step 4: Structure Your Roadmap

Now it's time to structure your prioritized initiatives into an actual roadmap document.

Choose the Right Format

Different roadmap formats serve different purposes:

Timeline-based: Shows rough sequencing across months or quarters Now/Next/Later: Groups work by time horizon without specific dates Objective-based: Organizes initiatives by the goals they support Theme-based: Groups initiatives under strategic themes

Select a format that matches your organization's planning style and tolerance for uncertainty.

Set the Right Level of Detail

A common mistake is including too much detail, which makes the roadmap brittle. Follow this guide:

Now (Current quarter):

• Initiative names with brief descriptions

• Key deliverables

• Expected outcomes

• Owner

• Dependencies

Next (Following 1-2 quarters):

• Problem statements

• Potential solution directions

• Business objectives

• Dependencies

Later (Beyond 6 months):

• Strategic themes

• Opportunity areas

• Expected business impact

Focus on Outcomes, Not Outputs

A key principle of modern product management is focusing on the outcomes you want to achieve rather than specific features or outputs. When structuring your roadmap:

• Clearly articulate the customer problems being solved

• Define what success looks like in measurable terms

• Express initiatives in terms of desired outcomes rather than features

• Include success metrics for each major initiative

This approach gives teams more flexibility in how they solve problems while keeping everyone aligned on what really matters.

Include Key Context

Don't just list initiatives—provide the context that makes your roadmap understandable:

Vision statement: Where is the product headed long-term? Strategic objectives: What key goals is this roadmap supporting? Scope clarification: What areas does this roadmap cover? Current focus: What are the immediate priorities? Key metrics: What will success look like? Assumptions and risks: What factors might affect this plan?

Industry example: Asana's internal roadmaps always begin with a "context" section that aligns readers on strategy before showing specific initiatives, ensuring everyone interprets the roadmap through the same strategic lens.

Step 5: Communicate Effectively

A roadmap that sits in a document without effective communication is worthless. Thoughtful communication is what transforms your roadmap from a document into an alignment tool.

Tailor Communication to Different Audiences

Different stakeholders need different perspectives:

Executive leadership:

• Focus on strategic alignment and expected outcomes

• Show how initiatives support key company metrics

• Highlight major investments and trade-offs

Sales and customer-facing teams:

• Emphasize customer problems being addressed

• Provide high-level timing without specific dates

• Include "why" behind prioritization decisions

Engineering and design:

• Include more detail on solution direction

• Clarify dependencies and technical considerations

• Show how work connects to user and business outcomes

Set Proper Expectations

Be explicit about the nature of your roadmap:

• Clarify the level of commitment (what's firm vs. directional)

• Explain how and when the roadmap will be updated

• Be transparent about what might cause changes

• Describe how stakeholders can provide input for future cycles

Tell a Cohesive Story

Don't just present a list of initiatives—weave them into a narrative:

• Start with the strategic context and vision

• Explain key customer problems you're addressing

• Show how initiatives build on each other

• Connect work to meaningful outcomes

• Acknowledge trade-offs and rationale

Industry example: When Spotify presents roadmaps internally, they structure them as stories—"Here's where users struggle today, here's our vision for the future, and here's how these initiatives will move us toward that vision step by step."

Step 6: Manage the Roadmap Over Time

A roadmap isn't a static document—it requires ongoing management to remain valuable.

Establish a Regular Review Cadence

Set a consistent schedule for roadmap reviews:

• Weekly: Track progress against current initiatives

• Monthly: Assess whether assumptions still hold

• Quarterly: Major roadmap refresh and reprioritization

Industry example: Atlassian conducts "roadmap refinement" sessions every two weeks, where teams assess progress, review new information, and make small adjustments without waiting for major planning cycles.

Create a Process for Handling Change

Changes will happen—have a process ready:

• Define criteria for when the roadmap needs updating

• Establish who can approve changes at different levels

• Create a communication plan for notifying stakeholders

• Document the reasoning behind significant changes

Industry example: When Basecamp needs to change direction mid-cycle, they write a "change case" that documents what's changing, why it's changing, what the impact will be, and who's affected—creating transparency around roadmap adjustments.

Track and Share Progress

Make roadmap progress visible:

• Create a dashboard showing initiative status

• Regularly communicate completions and learnings

• Connect delivered work to original strategic objectives

• Celebrate achievements along the way

Embrace Continuous Discovery

Modern product teams practice continuous discovery alongside delivery. This means:

• Allocating time for ongoing research and validation

• Running experiments to test assumptions behind roadmap items

• Adjusting course based on learnings

• Maintaining a healthy balance between discovery and delivery work

Continuous discovery helps ensure your roadmap evolves based on validated learning rather than just initial assumptions.

Common Roadmap Pitfalls for Junior PMs

As you create your first roadmaps, watch out for these common traps:

Pitfall 1: The Feature Factory Roadmap

The trap: Creating a roadmap that's just a list of features without clear connection to user problems or business outcomes.

The solution: For each initiative, explicitly document:

• The user problem being solved

• The expected business outcome

• How success will be measured

Recommended practice: Add roadmap item to include a "problem statement" section that precedes any solution description, ensuring teams stay focused on problems rather than features.

Pitfall 2: The Overcommitment Calendar

The trap: Filling every available moment with work, leaving no buffer for the unexpected.

The solution:

• Budget only 60-70% of theoretical capacity

• Include explicit time for discovery and research

• Account for maintenance, bug fixes, and unplanned work

Industry example: Basecamp famously plans six-week cycles with two weeks of cool-down between them, acknowledging that creative work can't be scheduled at 100% efficiency.

Pitfall 3: The Stakeholder Pleaser

The trap: Trying to make everyone happy by including a little something for each stakeholder.

The solution:

• Ground prioritization in objective criteria

• Show stakeholders the full demand list so they see trade-offs

• Focus on company strategy as the ultimate arbiter

Liking what you read in Mastering Product? Become a free subscriber to get every new post in your inbox—and help power the work that goes into it.

Pitfall 4: The Perfection Paralysis

The trap: Delaying roadmap creation while seeking perfect information and certainty.

The solution:

• Start with your best current understanding

• Be explicit about assumptions and confidence levels

• Plan regular updates as you learn more

Industry example: Amazon teams use a "working roadmap" approach where they acknowledge that early versions will be imperfect but start with their current best understanding, clearly flagging areas of uncertainty for further investigation.

Tools for Roadmap Creation

While process matters more than tools, having the right software can help, especially for distributed teams. Consider these options:

For Beginners (Simple Tools)

• Spreadsheets: Excel or Google Sheets can work well for simple roadmaps

• Presentation software: PowerPoint or Google Slides provide visual flexibility

• Trello: Simple, visual organization of initiatives by time horizon

Industry example: Smaller teams at companies like Buffer have successfully used Trello boards with "Now/Next/Later" columns as simple, visual roadmaps that can be easily shared and updated.

For Growing Teams (Dedicated Roadmap Tools)

• Aha!: Comprehensive product planning with strategy connections to OKRs.

• Productboard: Purpose-built for product management with strong prioritization features

• Roadmunk: Visual roadmapping with multiple view options

• Airfocus: Flexible prioritization and roadmapping

Roadmap Templates for Different Contexts

Different product contexts call for different roadmap approaches. Here are templates for common situations:

For New Products in Discovery Phase

Focus on:

• Learning objectives

• Hypothesis testing

• Key milestones toward product-market fit

• Decision points rather than delivery dates

Example format:

• Phase 1: Problem validation

• Phase 2: Solution exploration

• Phase 3: MVP definition

• Phase 4: Initial launch

Industry example: When Airbnb was developing their Experiences product line, their early roadmaps focused on learning goals and validation milestones rather than feature delivery, reflecting the discovery nature of the work.

For Established Products with Regular Releases

Focus on:

• Themes grouped by release

• Problem areas being addressed

• Expected user and business outcomes

• Approximate timeframes (quarters, not dates)

Example format:

• Q1 Focus: Theme A (Initiatives 1,2,3)

• Q2 Focus: Theme B (Initiatives 4,5,6)

• Q3-Q4: Directional themes

Industry example: Spotify organizes their roadmaps around release themes that may span multiple sprints, focusing teams on cohesive problem areas rather than individual features.

For Platform Products with Multiple Stakeholders

Focus on:

• Capabilities being developed

• Integration points

• Dependencies between components

• Sequencing of platform improvements

Example format:

• Infrastructure layer: Initiatives A, B

• Core services: Initiatives C, D

• APIs and integration: Initiatives E, F

• User-facing features: Initiatives G, H

Industry example: Twilio's platform roadmaps explicitly show the progression from core infrastructure to developer tools to end-user capabilities, helping stakeholders understand dependencies.

Special Considerations for Junior PMs

As a junior PM, you face unique challenges in roadmap creation. Here's how to navigate them:

When You're New to the Domain

If you're still building domain expertise:

• Leverage subject matter experts heavily during input gathering

• Have technical leads review feasibility assumptions

• Focus on problems rather than prescribing solutions

• Acknowledge knowledge gaps transparently

• Ask clarifying questions about business and technical context

When Your Authority Is Still Developing

If you're still establishing credibility:

• Ground recommendations in data and user research

• Show your work—explain the process that led to your conclusions

• Socialize ideas informally before formal presentations

• Leverage your manager for visibility and support

• Focus on areas where you have the most knowledge first

When Stakeholders Try to Bypass the Process

If stakeholders are trying to force their priorities:

• Bring them into the prioritization process rather than fighting them

• Ask them to help evaluate their request against existing criteria

• Show the trade-offs required to accommodate their request

• Enlist your manager to reinforce the prioritization approach

• Find compromises that address their core needs

Industry example: At Atlassian, new PMs are encouraged to invite vocal stakeholders to prioritization sessions where they must evaluate all initiatives (not just their own) using consistent criteria, creating buy-in for the process.

From Creation to Influence: Making Your Roadmap Matter

Creating a roadmap document is only the first step. The real value comes from using it to influence organizational direction and decision-making.

Build Advocacy Through Involvement

Include key stakeholders in the roadmap creation process:

• Gather their input during the planning phase

• Invite them to prioritization sessions

• Share early drafts for feedback

• Give credit for their contributions

This creates advocates who feel ownership in the final result.

Industry example: Slack product teams hold "roadmap collaboration sessions" where stakeholders from sales, marketing, customer success, and engineering actively participate in shaping priorities, creating shared ownership of the outcome.

Connect to What Others Care About

Frame your roadmap in terms that resonate with different stakeholders:

• For executives: Strategic alignment and business outcomes

• For sales: Customer problems and competitive positioning

• For engineering: Technical direction and architecture evolution

• For customer success: Pain point resolution and experience improvements

Industry example: When presenting roadmaps, product teams at Zendesk create different "lenses" that highlight the aspects most relevant to each audience—customer impact for support teams, technical evolution for engineering, and business outcomes for executives.

Use the Roadmap to Drive Decisions

Reference your roadmap in day-to-day decision making:

• When new opportunities arise: "How does this compare to what's already on our roadmap?"

• When scope discussions happen: "Does this align with the problem we're trying to solve?"

• When resources are requested: "Which roadmap item would this support?"

This reinforces the roadmap as a living decision-making tool rather than a document that's created and forgotten.

Industry example: Product teams at Asana start feature kickoff meetings by explicitly showing how the initiative connects to their roadmap priorities, reinforcing the strategic context for tactical decisions.

Your First 30 Days with a New Roadmap

Once your roadmap is created, focus on these activities in the first month:

Days 1-7: Socialization and Refinement

• Present the roadmap to key stakeholder groups

• Gather feedback and make necessary adjustments

• Ensure your team understands the reasoning behind prioritization

• Create accessible versions for different audiences

Days 8-15: Execution Kickoff

• Start detailed planning for immediate priorities

• Establish progress tracking mechanisms

• Set up regular check-ins on roadmap initiatives

• Begin discovery work for upcoming items

Days 16-30: Learning System Setup

• Create feedback loops for early initiatives

• Document assumptions that need validation

• Establish leading indicators for roadmap success

• Schedule the first roadmap review session

Industry example: Shopify has a formal "roadmap activation" process for the 30 days following roadmap creation, with specific checkpoints to ensure the roadmap transitions from planning document to active guide for team activities.

Integrating the Roadmap with Other Product Artifacts

Your roadmap doesn't exist in isolation—it should connect with other key product documents:

Product Strategy Connection

Your roadmap should clearly trace back to your product strategy, showing how each initiative supports strategic objectives. Create explicit links between strategy statements and roadmap items.

OKRs and Goal Alignment

If your organization uses OKRs (Objectives and Key Results) or similar goal-setting frameworks, connect roadmap initiatives to specific objectives and key results. This creates a clear line of sight from daily work to organizational goals.

Discovery Outcomes Integration

As your continuous discovery activities yield insights, they should feed directly into roadmap refinement. Create a process for capturing discovery learnings and evaluating their impact on roadmap priorities.

User Journey Mapping

Connect roadmap initiatives to specific points in your user journey maps, showing how each improvement addresses friction points or enhances key moments in the customer experience.

The Roadmap as a Learning Tool

As a junior PM, remember that your first roadmap won't be perfect—and that's OK. The roadmap is as much a learning tool as it is a planning document. Each cycle of creating, communicating, and updating your roadmap will improve both the document itself and your skills as a product manager.

The best roadmaps evolve as you learn more about your users, your market, and your team's capabilities. By approaching roadmap creation as an ongoing process rather than a one-time deliverable, you'll create a tool that genuinely guides product development while building your credibility as a strategic product thinker.

What challenges are you facing with your first roadmap? Are you struggling with prioritization, stakeholder management, or finding the right level of detail? Share your experiences in the comments, and let's learn from each other's roadmap journeys.

Leave a comment

Product managers today face a critical challenge: building products that can rapidly scale while maintaining quality and user satisfaction. The traditional feature-focused approach—where we continuously add capabilities based on user requests and market trends—has proven insufficient for sustainable growth.

Enter platform thinking: a strategic approach that views your product not just as a collection of features, but as a foundation upon which value can be created, both by your team and by external parties. This shift in perspective has enabled companies like Slack, Shopify, and Stripe to achieve exponential growth while maintaining focus.

In this article, I'll explore how platform thinking transforms product strategy, the fundamental principles behind successful platform products, and practical steps for implementing this approach in your organization.

The Limitations of Feature-Based Product Thinking

Before diving into platform thinking, let's understand why the traditional feature-based approach often falls short:

The Feature Treadmill
Many product teams find themselves trapped in an endless cycle of feature development, where each new capability creates maintenance debt, increases complexity, and dilutes the core value proposition. As MongoDB's former CPO Eliot Horowitz noted, "Adding features is easy; creating a cohesive platform is hard."

Diminishing Returns
Feature development typically follows a law of diminishing returns. Early features drive significant growth, but over time, each new feature delivers less impact while increasing system complexity.

Limited Scalability
Feature-based products scale linearly with your team's capacity to build. This creates a fundamental constraint: growth depends directly on headcount and development resources.

What Is Platform Thinking?

Platform thinking reimagines your product as an ecosystem that enables value creation beyond what your team builds directly. It focuses on establishing a foundation with clear interfaces, standards, and extension mechanisms that allow others (internal teams, partners, or even users) to build upon.

Core Components of Platform Thinking:

1. Base Layer: The foundational technologies, data models, and infrastructure

2. Extensibility Layer: APIs, SDKs, webhooks, and integration points

3. Value Creation Layer: How different participants can create value on the platform

4. Governance Layer: Rules, standards, and policies that maintain platform integrity

Why Platform Thinking Matters Now

Several market forces make platform thinking particularly relevant in 2025:

1. Increasing Integration Requirements: The average enterprise now uses over 130 SaaS applications, making integration capabilities non-negotiable

2. Ecosystem Competition: Competition is no longer just between products but between ecosystems

3. Specialized Use Cases: Customer segments increasingly demand tailored solutions for their specific needs

4. Resource Constraints: Economic pressures demand more value creation with fewer internal resources

The Platform Thinking Maturity Model

Based on my experience with product teams at various stages, I've developed a four-stage platform thinking maturity model:

Stage 1: Feature-Focused Product

• Product serves a specific use case with fixed functionality

• Changes require direct development by your team

• Value is created exclusively by the product team

Stage 2: Extensible Product

• Core functionality augmented by integration capabilities

• Limited API access for data exchange

• Some customization options for users

• Value primarily created by product team, with some user configuration

Stage 3: Product Platform

• Robust API layer with well-documented endpoints

• Developer tools for building extensions

• Marketplace for add-ons or integrations

• Value created by both product team and developers/partners

Stage 4: Platform Ecosystem

• Multi-sided marketplace connecting different user groups

• Self-service developer experience

• Network effects drive growth

• Value predominantly created by platform participants

Moving through these stages isn't mandatory for every product, but understanding where you are helps inform strategic decisions.

The Business Case for Platform Thinking

Converting stakeholders to platform thinking requires demonstrating clear business benefits:

Exponential Growth Potential
Platforms can scale beyond the constraints of your development resources. Shopify's app store now features over 8,000 apps, creating value far beyond what their internal team could build.

Defensive Moat
Platforms create stickier products through network effects and ecosystem dependencies. Slack's 2,600+ app integrations make switching costs significantly higher for users invested in multiple connected workflows.

Market Expansion
Platforms allow you to serve adjacent markets without diluting focus. Stripe expanded from payments to a comprehensive financial services platform by enabling partners to build specialized solutions on their infrastructure.

Higher Valuation Multiples
Platform businesses typically command 2-3x higher valuation multiples than feature-based products due to their scalability and defensibility.

Principles for Successful Platform Products

Through my work with various product teams, I've identified five core principles that underpin successful platform strategies:

1. Start With Core Value Creation

Before platform expansion, ensure your core product delivers substantial standalone value. Attempting to platform-ize a product without a strong core value proposition leads to failure.

Example: GitHub established itself as the leading code repository platform before expanding into actions, packages, and codespaces.

2. Design for Extensibility From Day One

Even if you're not immediately building platform capabilities, architect your product with future extensibility in mind. This includes:

• Clean API design

• Modular architecture

• Consistent data models

• Standardized interfaces

Example: Notion started with a simple note-taking app but designed its block-based architecture for ultimate flexibility, enabling its eventual expansion into a full workspace platform.

3. Focus on Developer Experience

For platforms, developers are a critical user segment. Their experience determines platform adoption and value creation.

Example: Stripe invested heavily in developer documentation, SDKs, and testing tools, making it the preferred payment solution despite numerous competitors offering similar core functionality.

4. Build Governance Mechanisms

As your platform scales, maintaining quality and coherence becomes challenging. Establish clear governance:

• Quality standards for extensions

• Security requirements

• Performance benchmarks

• Design guidelines

Example: Apple's App Store review process, while sometimes criticized for stringency, maintains quality standards that benefit the overall ecosystem.

5. Enable Value Capture for All Participants

Successful platforms create win-win-win scenarios where users, developers/partners, and the platform all capture value.

Example: Shopify's revenue share model enables app developers to build sustainable businesses while enhancing the platform's value proposition and generating additional revenue.

Should You Platformize? A Decision Filter for Product Teams

Not every product is destined to become a platform—and that’s okay. Platform thinking is powerful, but premature platformization can distract you from solving the core problem your users care about.

Use this simple decision filter to evaluate whether your product is ready—or could be ready soon—for a platform strategy.

You’re likely ready if:

• Users are hacking your product — They’re building workarounds, exporting data, or stitching together integrations with Zapier or scripts.

• Partners are requesting integrations — External companies want to connect with your product or extend it for niche use cases.

• You’re being pulled into adjacent markets — Customers are using your product in ways you didn’t expect and asking for customizations.

• Internal teams are duplicating effort — Different teams are rebuilding the same logic or services across multiple silos.

• Your roadmap is overloaded — You’re saying “no” to good ideas because your team can’t scale linearly.

You’re probably not ready if:

• Your core product isn’t working yet — If you haven’t nailed product-market fit, platformization is a distraction.

• You have very low usage or engagement — Platforms amplify value, but they don’t create it from scratch.

• There’s no clear value for external developers — If others don’t benefit from building on your product, they won’t.

• You don’t have the resources to support developers — Half-baked API programs damage reputation and adoption.

Measuring Platform Success

Traditional product metrics don't fully capture platform performance. Consider these platform-specific metrics:

Developer Metrics

• Number of active developers

• Time to first successful API call

• Developer retention rate

• Support ticket volume per developer

Integration Metrics

• Number of active integrations

• Integration installation rate

• Integration retention rate

• Revenue generated through integrations

Ecosystem Health Metrics

• Platform dependencies (how essential is your platform?)

• Third-party investment (resources others commit to your platform)

• Ecosystem diversity (variety of solutions built on your platform)

• Network density (connections between ecosystem participants)

Case Study: Twilio's Transition from Product to Platform

Twilio provides an excellent case study of a successful transition from a product to a platform mindset:

Initial State:

• Launched in 2008 as a cloud-based telephony service

• Offered simple SMS and voice APIs

• Limited to basic communication features

• Developer-focused but with a narrow set of capabilities

Platform Transformation:

1. Twilio identified its core value proposition: simplifying communications infrastructure

2. Developed a comprehensive API layer with consistent design patterns

3. Created extensive developer documentation, SDKs, and code samples

4. Launched Twilio Studio, enabling non-developers to build workflows

5. Introduced the Twilio Marketplace for partner solutions

Results:

• Evolved from a communications API to a complete customer engagement platform

• Expanded from 2 products to 31+ products through both internal development and acquisitions

• Active customer accounts grew from 28,000 in 2016 to over 268,000 in 2022

• Revenue increased from $167 million in 2016 to $3.8 billion in 2022

Key Strategies:

• Maintained a relentless focus on developer experience

• Used their own APIs internally ("dogfooding")

• Provided flexible pricing models that scaled with customer growth

• Created "building blocks" that developers could combine in unique ways

• Established clear documentation standards and support systems

Twilio's success demonstrates how platform thinking can transform a relatively simple API product into a comprehensive ecosystem that powers communications for organizations of all sizes, from startups to enterprises like Uber, Airbnb, and Netflix.

Common Pitfalls to Avoid

From what I’ve seen in my experience, these are the most common pitfalls:

Premature Platformization
Building platform capabilities before establishing core product value leads to wasted resources and lack of adoption.

Over-Engineering APIs
Designing overly complex or rigid APIs can limit adoption and increase maintenance burden.

Neglecting Internal Use Cases
The first users of your platform should be internal teams, who can provide valuable feedback before external release.

Focusing on Technology Over Ecosystem
The technology is just an enabler—successful platforms focus on nurturing the ecosystem of developers, partners, and users.

Insufficient Resources for Developer Experience
Many companies underestimate the investment required to create a compelling developer experience.

As markets mature and user expectations evolve, the ability to scale beyond your team's direct capabilities becomes increasingly critical. Platform thinking represents not just a technical approach but a fundamental business strategy for sustainable growth.

By reimagining your product as a foundation for value creation rather than a collection of features, you open new avenues for innovation, expansion, and defensibility. The journey requires investment and patience, but the potential rewards—exponential growth, higher valuation, and ecosystem leadership—make it a compelling path for forward-thinking product teams.

Leave a comment

"Most metrics we use are only an approximation of the real thing we care about." — Sophie Alpert

As product managers, we're constantly seeking ways to make better decisions faster. One powerful technique is using proxy metrics—measurable indicators that predict movement in more important but slower-to-capture outcomes.

What is a Proxy Metric?

A proxy metric is a stand-in measurement that reliably predicts a more important outcome that might be:

• Too slow to measure (like annual retention)

• Difficult to quantify directly (like product experience quality)

• Not generating enough data yet (in early-stage products)

Think of proxy metrics as the pulse check you do while waiting for comprehensive blood test results. They explicitly acknowledge: "I'm not the ultimate thing you want to measure, but I'm the best practical surrogate for it right now."

Why You Need Proxy Metrics in Product Management

In the Pyramid of Evidence framework I wrote about previously, proxy metrics help you climb higher by providing faster signals about what's working. Here's when they're most valuable:

At Booking.com, we used proxy metrics extensively to make product decisions without waiting for full booking cycles to complete. This approach allowed us to move much faster while maintaining confidence in our direction.

Characteristics of Effective Proxy Metrics

Based on my experience implementing hypothesis-driven product development at companies like Eneco and Foodics, effective proxy metrics should have:

1. Strong correlation with your target outcome (backed by historical data)

2. Causal potential—moving the proxy should move the outcome (validate with A/B tests)

3. Timely sensitivity—it moves quickly enough to inform sprint-level decisions

4. Team control—your product team can directly influence it

5. Simplicity & integrity—easy to understand and resistant to gaming

These align with decision frameworks I've shared previously about reducing decision fatigue—the right proxy metrics simplify decision-making by providing clear signals.

How to Implement Proxy Metrics: A 6-Step Process

1. Define Your North Star

Start with your ultimate goal—the outcome that truly matters. This might be annual retention, revenue per user, or customer lifetime value. A proxy never replaces this North Star; it just helps you navigate toward it faster.

2. Map Your Value Path

Identify the customer behaviors that must occur before your outcome happens. This is where the Jobs-to-be-Done framework becomes valuable—understanding the steps in your customer's journey helps identify potential measurement points.

3. Brainstorm Candidate Metrics

For each critical behavior, ask: "What can we measure quickly that indicates this is happening?" Focus on ratios rather than absolute numbers (e.g., percentage of users who activate rather than total activations).

4. Run Correlation Analysis

Use historical data to determine which candidates best predict your outcome. This is where the data-driven decision-making approach I've advocated for becomes essential.

5. Test for Causality

Run controlled experiments where you intentionally move the proxy metric to verify it impacts your ultimate outcome. The hypothesis-driven product development approach I detailed previously works perfectly here.

6. Implement and Monitor

Set up dashboards and alerts at your sprint cadence. Establish guardrails to ensure the proxy isn't optimized at the expense of your ultimate goal.

Real-World Examples from My Experience

At Booking.com, we found that "Users who supplised a credit card at the time of their booking that was 6 months or less about to expire, were 2X more likely to cancel their reservation”. By reminding customers to update their credit card 6 months before its expiry, we decreased cancellations of that customer segment by around 3%.

In product management training programs, I've seen "completion of practice exercises" serve as an excellent proxy for eventual skill application. Programs that optimize for this proxy consistently produce more effective product managers.

Avoiding Common Proxy Metric Pitfalls

Evolving Your Metric Strategy

Proxy metrics are like training wheels—crucial when you're starting but meant to come off eventually. As your product matures and you collect more data, you'll be able to move to more direct measurements.

The product trio should regularly evaluate the effectiveness of proxy metrics and be ready to graduate to more sophisticated measurement approaches when appropriate.

Key Takeaways

1. Proxy metrics compress the feedback loop between action and learning

2. They must be correlated, causal, timely, and team-controllable

3. Use a structured selection and validation process to ensure they remain reliable

4. Regularly reevaluate and replace proxies as your product and data capabilities evolve

When implemented thoughtfully, proxy metrics give your product team the confidence to move quickly without guessing in the dark—turning every sprint into measurable progress toward your true North Star.

What proxy metrics have you found most valuable in your product management work? Share your experiences in the comments!

Leave a comment

Dear product pros 👋,

Today I’m doubly excited to share two milestones for the Mastering Product community:

1. The Product Management Resources Hub is live.
   A curated, ever‑growing library of free guides, templates, and checklists built from 20 years of real‑world PM work. No paywall, no email gate—just grab what you need and get back to building great products.

2. We’ve moved to a dedicated domain:

   You can still read every post in your inbox as usual, but if you access the site directly, update your bookmarks from masteringproduct.substack.com to masteringproducthq.com. (All old links will automatically redirect.)

A quick tour of what’s inside

Product Management Fundamentals
‑ Bite‑size primers on the core concepts every PM should master
‑ Sample picks: Product Management Basics Guide, Product Lifecycle Overview, Agile for Product Managers

Templates & Frameworks
‑ Plug‑and‑play documents to give your process structure
‑ Sample picks: Product Requirements Document (PRD) template, Prioritization Framework Guide, User Story Template

Learning Resources
‑ Hand‑picked courses, reading lists, and must‑watch videos
‑ Sample picks: Curated course links, annotated book list, video recommendations

Career Development
‑ Tools to level up your portfolio and interview game
‑ Sample picks: Resume tips, interview prep checklists, career‑path guidance

P.S. I will do my best that new resources every two weeks, your support is crucial to help me maintain the momentum though! —watch this space! masteringproducthq.com

How this affects you

• Email delivery stays the same. You’ll keep receiving new essays and drops right in your inbox.

• No action needed the old url will redirect you to the new one.

• More flexibility for the future. Owning the domain lets us add member‑only perks (think tool integrations, micro‑courses, and job boards) without leaving Substack behind.

Dive in and let me know what you think

👉 Explore the new hub: https://www.masteringproducthq.com/p/product‑management‑resources

If a template or guide saves you time, hit reply and tell me about it—or suggest what I should create next. Knowledge compounds when we share it.

Thanks for being part of this journey. Onward to better products!

— Sohaib

Every product decision you make is quietly influenced by cognitive biases you might not even recognize. Despite data-driven approaches and structured frameworks, our brains still take shortcuts that distort our judgment.

During my years at Booking.com, Eneco, Foodics and 7awi. I've seen how these invisible biases derail even the most carefully planned product strategies. The most dangerous part? We rarely notice them until the damage is done.

Let me show you the most damaging biases in product management and practical techniques to overcome them.

1. Confirmation Bias: Seeing What You Want to See

The Bias: You seek out information that supports your existing beliefs while ignoring contradictory evidence.

How It Sabotages Product Decisions:

• You interpret user research selectively to validate your product vision

• You dismiss critical feedback that challenges your assumptions

• You give more weight to data that aligns with your hypotheses

Real-World Example: At Booking.com, we were convinced a new feature would drive conversion improvements. Our initial research seemed positive, reinforcing our belief. After launch, we saw virtually no impact. We had unconsciously filtered user feedback, focusing on positive signals while dismissing subtle indicators that users didn't actually value the feature.

Practical Countermeasures:

• Assign a dedicated devil's advocate in every product discussion

• Ask explicitly: "What would prove this hypothesis wrong?"

• Set success criteria before seeing results

• Review data blindly when possible, without knowing which variant is which

Try This Today: Before your next major decision, answer these four questions:

• Have I actively looked for evidence that contradicts my position?

• Can I articulate the strongest case against my decision?

• Have I consulted someone with a different perspective?

• Would I make the same decision if the data pointed in the opposite direction?

2. Sunk Cost Fallacy: The Persistence Trap

The Bias: You continue investing in something based on past investment rather than future value.

How It Sabotages Product Decisions:

• You keep developing features that data shows aren't valuable

• You persist with rejected product strategies

• You refuse to pivot because "we've already put so much into this"

Real-World Example: We once spent six months developing a complex analytics dashboard our initial research suggested customers wanted. Three months in, feedback indicated a much simpler solution would better meet customer needs. We continued anyway because "we've already done half the work." The result? An over-engineered product with poor adoption.

Practical Countermeasures:

• Schedule regular go/no-go decision points in your development process

• Evaluate decisions based on future value, not past investment

• Break initiatives into smaller, independently valuable increments

• Recognize teams that make the tough call to kill underperforming initiatives

Try This Today: For your current project, conduct a "Fresh Start Review":

• If we were starting today with what we now know, would we still make the same decision?

• What would we do differently if we had no prior investment?

• What could we do with these resources if we stopped this work today?

3. The IKEA Effect: Overvaluing Your Own Creations

The Bias: You place higher value on things you helped create, regardless of their objective quality.

How It Sabotages Product Decisions:

• You overestimate the value of features you personally conceived

• You resist feedback suggesting your creations need significant changes

• You prioritize your ideas over potentially better alternatives

Real-World Example: I once spent weeks designing what I thought was an elegant solution to a complex user problem. When user feedback was lukewarm, I convinced myself they "just didn't get it yet" and pushed for launch with minimal changes. The feature saw poor adoption and eventually required a complete redesign based on feedback I should have heeded initially.

Practical Countermeasures:

• Have different team members evaluate ideas than those who created them

• Implement blind evaluation processes where ideas are judged without knowing their source

• Create multiple solutions to the same problem

• Define success in terms of user impact, not feature completion

Try This Today: For your current favorite feature or idea, apply the "Proud Parent Test":

• Would I be equally enthusiastic if someone else had proposed this?

• Am I defending this based on its merits or because it's "my baby"?

• Can I name three significant limitations in my own idea?

4. Recency Bias: The Latest is the Greatest

The Bias: You give too much importance to recent events or information compared to older data.

How It Sabotages Product Decisions:

• You dramatically shift priorities based on the latest customer feedback

• You overreact to recent competitor moves

• You make decisions based on short-term metrics fluctuations rather than sustained patterns

Real-World Example: After one vocal customer complained about a specific feature gap, we immediately reprioritized our roadmap to address it. We later discovered this issue affected less than 2% of users, while we delayed work on problems impacting over 50% of our user base.

Practical Countermeasures:

• Keep a decision journal documenting context and rationale

• Implement a "cooling-off period" for decisions triggered by recent events

• Review longer-term data trends before shifting priorities

• Create a systematic feedback aggregation process

Try This Today: Before pivoting based on new information, ask:

• How does this compare to what we've heard over the past 3-6 months?

• Is this a pattern or an isolated data point?

• Would we make this same decision if we'd received this information a month ago?

5. Availability Heuristic: The Vividness Trap

The Bias: You overestimate the importance of things that come readily to mind because they're recent, unusual, or emotionally charged.

How It Sabotages Product Decisions:

• You overemphasize dramatic but rare edge cases in product design

• You give too much weight to memorable feedback while ignoring common but less vivid experiences

• You focus on highly visible but less impactful product issues

Real-World Example: After a high-profile security incident at a competitor, our team spent months implementing elaborate security features that diverted resources from more pressing user needs. The vivid nature of the breach made the risk seem more immediate than data suggested.

Practical Countermeasures:

• Quantify frequency and impact of issues rather than relying on anecdotes

• Create a "problem bank" that systematically tracks issues with data on frequency and severity

• Use structured prioritization frameworks like RICE

• Proactively research problems users aren't actively reporting

Try This Today: When a vivid problem captures your attention, conduct a "Frequency Check":

• How often does this actually occur?

• What percentage of users are affected?

• How does this compare to other issues in terms of frequency and impact?

6. Planning Fallacy: Systematic Underestimation

The Bias: You underestimate time, costs, and risks while overestimating benefits.

How It Sabotages Product Decisions:

• You create unrealistic development timelines

• You underestimate implementation complexity and technical debt

• You overestimate feature impact on key metrics

• You set unrealistic expectations with stakeholders

Real-World Example: We once estimated a major platform migration would take three months. Despite adding a 20% buffer, it took seven months. We failed to account for unexpected integration challenges, competing priorities, and learning curves with new technologies.

Practical Countermeasures:

• Use reference class forecasting by looking at how long similar projects actually took

• Implement "pre-mortem" technique to identify potential failures before they occur

• Break work into smaller increments with more predictable timelines

• Track estimate accuracy over time

Try This Today: For your next significant initiative, apply the "Historical Doubling Rule":

• Look at similar past projects and note estimated vs. actual timelines

• If no similar projects exist, double your initial estimate

• Create ranges rather than point estimates (e.g., "4-6 weeks" not "5 weeks")

• Identify specific risks that could extend the timeline

7. Status Quo Bias: Resistance to Change

The Bias: You prefer the current state of affairs and see changes as losses.

How It Sabotages Product Decisions:

• You resist potentially valuable product pivots

• You maintain legacy features that no longer serve users

• You avoid bold innovations in favor of incremental improvements

• You dismiss disruptive ideas that challenge existing mental models

Real-World Example: Despite data showing our product's navigation structure was causing user confusion, our team resisted a redesign for over a year. We overestimated the disruption a change would cause. When we finally implemented a more intuitive navigation, user satisfaction increased significantly. We regretted not making the change sooner.

Practical Countermeasures:

• Regularly ask: "If we weren't already doing this, would we start?"

• Implement sunset reviews for existing features

• Create space for experimentation through innovation sprints

• Use the "reversible decision" framework to reduce perceived risk

Try This Today: Use the "Clean Slate Exercise":

• If you were building this product from scratch today, what would you do differently?

• Which current features exist primarily because "that's how we've always done it"?

• What would a new competitor without your legacy constraints do?

Building a Bias-Resistant Decision Process

While understanding individual biases helps, the most effective approach is building a decision-making process that systematically counters multiple biases:

1. Structure Before Content

   • Define how a decision will be made before discussing what the decision should be

   • Establish evaluation criteria in advance

   • Clarify decision-making authority

2. Separate Generation from Evaluation

   • Create distinct phases for generating options, gathering information, evaluating options, and deciding

   • This prevents premature convergence and reduces ownership bias

3. Implement Decision Reviews

   • Compare actual outcomes to expected outcomes

   • Identify which assumptions proved correct or incorrect

   • Document learnings to improve future decisions

4. Create a Decision Journal

   • Record significant product decisions, context, alternatives considered, and expected outcomes

   • Creates accountability and helps combat hindsight bias

5. Build Psychological Safety

   • Ensure team members feel safe challenging ideas regardless of source

   • Celebrate changing your mind based on new evidence

   • Actively seek diverse perspectives

Cognitive biases aren't character flaws—they're part of being human. The difference between good and great product managers isn't the absence of biases but the awareness of them and the discipline to implement countermeasures.

Start by focusing on one or two biases you recognize in your own thinking, implement specific countermeasures, and gradually expand your toolkit. Your decisions will improve, your products will get better, and your teams will deliver consistently superior results.

Which cognitive bias do you struggle with most? Reply to share your experience—I read every response and often feature reader insights in future newsletters.

Leave a comment

Preview and Download

Click here to download the guide in PDF, would a web based version of this template be useful? let me know in the comments below!

[Browse all resources] - [Upgrade/Pledge Premium Subscription]

Preview and Download

Click here to download the overview in PDF, would a web based version of this template be useful? let me know in the comments below!

[Browse all resources] - [Upgrade/Pledge Premium Subscription]

Preview and Download

Click here to download the list in PDF, would a web based version of this template be useful? let me know in the comments below!

[Browse all resources] - [Upgrade/Pledge Premium Subscription]

Preview and Download

• Subscribe for free, download link will be in your welcome email

[Browse all resources] - [Upgrade/Pledge Premium Subscription]

Preview and Download

Signup for free to mastering product to get this guide.

[Browse all resources] - [Upgrade/Pledge Premium Subscription]

Preview and Download

• Click here to download the guide in PDF, would a web based version of this template be useful? let me know in the comments below!

[Browse all resources] - [Upgrade/Pledge Premium Subscription]