A product manager explains user stories at a team training: "A user story captures value from the user's perspective: 'As a [user type], I want [feature] so that [benefit].' The key is the 'so that' — it connects the feature to a user outcome, not just a capability. Acceptance criteria make it testable: 'Given [context], when [action], then [result].' The mistake I see most: acceptance criteria that describe implementation instead of behaviour — 'the system calls the cache API' vs. 'search results appear within 500ms.'" What is the purpose of acceptance criteria in a user story, and what makes them well-written?
Acceptance criteria (AC): the specific conditions a story must satisfy to be accepted as done. Format: Given [precondition] / When [action] / Then [expected outcome]. Example: Given a user is on the search page / When they type 'laptop' and submit / Then results appear within 500ms and show at least 10 items. Good AC is: Observable: can be tested without reading the code. User-facing: describes behaviour the user (or QA) can verify. Specific: 'within 500ms' not 'fast.' Outcome-focused: not 'calls the cache layer' but 'results appear quickly.' Bad AC: describes implementation ('the API must be RESTful'), is ambiguous ('the page loads'), or is untestable ('users feel satisfied'). User story vocabulary: User story: 'As a [user type], I want [capability] so that [benefit].' The 'so that' is the business value — it prevents building features for no reason. Story point: a relative size estimate (Fibonacci sequence: 1, 2, 3, 5, 8, 13). Not hours. Epic: a large body of work spanning multiple stories. Vertical slice: a story that delivers end-to-end value (UI + API + DB) vs. a horizontal slice (UI only). Walking skeleton: the thinnest possible vertical slice that demonstrates the full system works end-to-end. In conversation: 'When engineers say they're not sure what done looks like, that's a signal the AC needs more specificity. Good AC eliminates that uncertainty before the sprint starts.'
2 / 5
A product manager introduces Jobs-to-be-Done (JTBD) to the team: "JTBD reframes the question: users don't want your product — they want to get a job done. The job is the progress they're trying to make in a specific situation. 'Job': I need to communicate a decision to remote stakeholders. 'Hired': email, Slack, Notion doc. We 'hired' these tools for that job. JTBD helps discover what our users are actually trying to accomplish — it stops us from building features that look good in demos but don't solve real problems." What is Jobs-to-be-Done (JTBD) and how does it differ from traditional feature-based thinking?
JTBD (Jobs-to-be-Done) (Clayton Christensen): When people buy or use a product, they 'hire' it to do a job for them — to make progress in a specific situation. JTBD format: 'When [situation], I want to [motivation / job], so I can [expected outcome].' Feature vs. JTBD thinking: Feature: 'Users want a document editor.' JTBD: 'When collaborating with remote colleagues on a decision, I want to capture and share our reasoning clearly, so stakeholders can review it asynchronously and trust the decision.' The JTBD reveals: the real competitors are email, Google Docs, Loom, a Slack thread — not just 'other document editors.' Product discovery vocabulary: Opportunity solution tree (Teresa Torres): structured visualization linking desired outcomes → opportunities (unmet needs/jobs) → solutions → experiments. Assumption mapping: identifying assumptions in a solution and ordering by importance + uncertainty. Highest importance + highest uncertainty = test first. Customer interview: the primary discovery tool for understanding jobs, struggles, and context. Rule: listen for stories ('tell me about a time when...'), not opinions ('would you use this?'). Problem statement: a crisp articulation of the job and the gap. Switch interview: asking users why they switched from a competitor — reveals the job more clearly than asking about their current behaviour. In conversation: 'JTBD stopped us building a feature 60% of users said they wanted in surveys. A JTBD interview revealed the real job — which we solved with a two-line copy change, not a new feature.'
3 / 5
A PM presents RICE scoring to justify deprioritising a feature request: "RICE helps us compare unlike things on the same scale. Reach: how many users does this affect per quarter? Impact: what's the effect per user (0.25=minimal, 0.5=low, 1=medium, 2=high, 3=massive)? Confidence: how certain are we about these estimates (100%=high, 80%=medium, 50%=low)? Effort: engineering weeks. Formula: (Reach × Impact × Confidence) ÷ Effort. A feature affecting 10K users with high impact and high confidence, taking 2 weeks: (10000 × 2 × 1.0) ÷ 2 = 10,000 RICE. That beats a fancy feature affecting 500 power users even if it sounds more exciting." What is the purpose of RICE scoring in product prioritisation, and what does the Confidence factor account for?
RICE (Reach × Impact × Confidence ÷ Effort): A prioritisation framework by Intercom. Reach: number of users/customers affected in a time period. Source: analytics. Impact: magnitude of effect per user. 0.25=minimal, 0.5=low, 1=medium, 2=high, 3=massive. Subjective but forces calibration. Confidence: how sure you are about your Reach and Impact estimates. 100% = data-backed. 80% = some evidence. 50% = mostly a guess. Prevents gaming: inflating Confidence requires justification. Effort: person-weeks from all roles. Denominator: penalises large items. RICE score interpretation: higher is better. Comparable across items. Limitations: RICE is not a strategy. It optimises for what you're measuring (reach × impact) — which may not align with strategic bets. Use alongside qualitative judgement. Prioritisation framework vocabulary: MoSCoW: Must have / Should have / Could have / Won't have. Simple; doesn't handle uncertainty. Kano model: classifies features by how they affect satisfaction (basic needs vs. performance vs. delight). Opportunity scoring: (importance × (importance - satisfaction)) — identifies gaps. Stack ranking: force-ranking all items 1–N. Eliminates ties. Now/Next/Later roadmap: three-bucket roadmap without dates. Reduces over-commitment. In conversation: 'RICE is a conversation tool more than a truth machine. The value is in making assumptions explicit — if two PMs disagree on a RICE score, it reveals a disagreement about Reach or Impact that's worth having explicitly.'
4 / 5
A product lead defines the north star metric for the team: "Our north star metric is weekly active users who complete at least one search and one save action. It captures the core user behaviour that correlates with long-term retention — both parts matter. We don't use DAU alone (that could include low-quality sessions) or saves alone (someone could save without finding value). Guardrail metrics prevent optimising for the north star in ways that hurt the business: we track page load time, support ticket volume, and NPS — if any cross a threshold while we improve the north star, we stop." What is the role of guardrail metrics in product metric design?
North star metric: the single metric that best captures the core value delivered to users — when it goes up, the business goes up. Examples: Airbnb: nights booked. Spotify: time spent listening. Slack: daily active users sending messages. Properties of a good north star: reflects user value (not just revenue), correlates with long-term retention, actionable by the product team. Guardrail metrics: metrics that must not be degraded while improving the north star. If they cross a threshold: stop the experiment or deprioritise the initiative. Examples: support volume (north star improving → users confused?), page load time (feature addition slowing the product?), NPS (users frustrated by a change?), churn rate. Metric vocabulary: Leading indicator: predicts future outcomes. Early signal. Example: 7-day engagement predicts 30-day retention. Lagging indicator: reflects past outcomes. Example: annual revenue. Activation metric: the moment a user first experiences the product's core value. Example: Dropbox: user places at least one file in a folder. Retention metric: % of users returning after N days. AARRR (Pirate Metrics): Acquisition → Activation → Retention → Revenue → Referral. L7/L28: percentage of users active in the last 7 or 28 days. In conversation: 'Without guardrail metrics, teams can game the north star. We once boosted DAU 40% by sending daily push notifications — and NPS dropped 8 points. Guardrails would have caught it in week one.'
5 / 5
A senior PM explains theme-based roadmaps to stakeholders: "We use a theme-based roadmap instead of a feature roadmap. A theme is a strategic bet — 'Reduce time-to-first-value for enterprise customers.' We don't commit to specific features 6 months out because we don't yet know what will solve the problem best. The roadmap shows themes with timeframes: Now (this quarter, committed), Next (next quarter, planned but not committed), Later (later this year, direction only). Each theme links to the business outcome we're trying to move." What is the key difference between a theme-based roadmap and a feature roadmap?
Feature roadmap: 'In Q3 we will build feature X.' Problems: commits to a solution before validating it, creates stakeholder expectations that become hard to change, encourages building features you don't end up needing, leads to 'roadmap debt' — features promised but never built. Theme-based roadmap: 'In Q3 we will focus on theme Y (reducing time-to-first-value).' Benefits: preserves optionality, focuses team on outcome not output, easier to update as you learn, aligns stakeholders on what problem matters without committing to how. Roadmap vocabulary: Now / Next / Later: three-bucket roadmap without specific dates. Reduces over-commitment. Committed vs. aspirational: committed items are resourced and planned; aspirational are directional. Horizon 1 / 2 / 3: short/medium/long-term bets from McKinsey framework. Initiative: a large group of related work (larger than an epic, smaller than a strategy). Milestone: a significant checkpoint, often with external visibility (beta launch, general availability). Discovery: the work to determine what to build. Delivery: the work of building it. Dual-track agile: running discovery and delivery in parallel. In conversation: 'When a stakeholder says 'is Feature X on the roadmap?' the answer with a theme roadmap is: 'We're committed to Theme Y — whether Feature X is the right solution for it is what we're discovering in Q2.' That keeps optionality without ambiguity about the strategic direction.'