5 exercises — MVP and hypothesis validation, North Star metrics, product-market fit, pivots, and dogfooding. The core vocabulary of product-first engineering teams.
0 / 5 completed
1 / 5
A product manager says in a planning meeting: "We're not building the full feature yet — let's start with the MVP and validate our core assumption." What does MVP mean here, and what is the "core assumption"?
MVP and the product validation vocabulary:
MVP (Minimum Viable Product) — coined by Eric Ries in "The Lean Startup" (2011). The smallest version of a product that delivers value to early adopters AND generates enough feedback to validate or invalidate the core business hypothesis.
Key properties of a true MVP: • Has the core functionality only — not polished, not full-featured • Goes to real users in the real world (not internal testing) • Designed to answer a specific hypothesis • Success = learning, not revenue (at this stage)
The "core assumption" / hypothesis: Every product is built on beliefs that haven't been proven yet. The MVP's job is to test the most important one. Examples: • "Developers will pay $20/month for this linting tool" • "Users will onboard without requiring a tutorial" • "Companies with 50+ employees need a different tier"
Related vocabulary (product development lifecycle): • hypothesis — an unproven belief the product tests • validate — confirm an assumption is true using real data • invalidate / falsify — prove an assumption is wrong • iteration — a cycle of build → measure → learn • feature creep — adding more features than needed; the enemy of MVP discipline • scope — the set of features included in a release ("scope this down" = reduce features) • dogfooding — using your own product internally before releasing it ("eating your own dog food") • alpha — very early internal testing; beta — controlled external testing before full launch • GA (General Availability) — public release, available to all users
2 / 5
During a product review, the CEO says: "Our North Star metric is weekly active users who complete at least one project. Everything we build should move this number." What is a North Star metric, and why does this framing matter for engineers?
North Star Metric — the concept and the engineering implication:
The North Star Metric (NSM) is the single measurement that best represents the value your product delivers to users. It is leading (predicts long-term success) rather than lagging (reflects what already happened, like revenue).
Examples by product: • Slack: messages sent per active user (are people actually communicating?) • Airbnb: nights booked (are people actually staying?) • Spotify: time spent listening per user • GitHub: pull requests merged • Linear (project tool): issues closed per engineer
Why not just use revenue? Revenue is a lagging indicator — by the time it drops, you've already lost users. The NSM captures user engagement before it converts to revenue, giving earlier signal.
The engineering implication: "Did this feature move our North Star?" is a more rigorous success criterion than "did we ship on time?" Engineers who understand this can challenge product decisions: "This feature adds to our feature count but doesn't move WAU — should we build it?"
Metrics vocabulary (product & engineering): • North Star Metric (NSM) — single metric capturing the core value delivered • leading indicator — early signal of future outcome (engagement, sign-ups) • lagging indicator — outcome that comes after the fact (revenue, churn) • vanity metric — looks impressive but doesn't reflect real value (total registered users, page views) • actionable metric — a metric you can actually change with product decisions • WAU / MAU / DAU — weekly/monthly/daily active users
3 / 5
A startup's CTO announces at an all-hands: "We've found product-market fit. We're moving from discovery mode to growth mode." What does product-market fit mean, and what changes when you reach it?
Product-Market Fit (PMF) — the most important milestone in a startup:
Marc Andreessen's definition (2007): "Product-market fit means being in a good market with a product that can satisfy that market."
Sean Ellis's test: Ask users "How would you feel if you could no longer use this product?" If 40%+ answer "very disappointed" — you have PMF.
Signs of PMF (you feel it): • Word-of-mouth growth without paid acquisition • Users return without reminders; email notifications are opened eagerly • Customer success team can't keep up with inbound requests • Press writes about you without being paid • You have a waiting list
Signs of no PMF: • High churn (users sign up but don't return) • Sales cycle is painful — convincing each customer requires extensive effort • Users say "it's nice" but don't use it regularly • You keep pivoting features
What changes after PMF — engineering implications: Before PMF: move fast, iterate, focus on learning. Technical debt acceptable. After PMF: scale, reliability, observability become critical. Engineers now face growth engineering challenges: database scaling, performance, infra cost optimisation, feature flagging for gradual rollouts.
Vocabulary: • PMF (product-market fit) — your product satisfies strong market demand • discovery mode — pre-PMF: exploring, validating, pivoting • growth mode — post-PMF: scaling, optimising, expanding • churn — rate at which users stop using the product • retention — rate at which users continue using the product • pivot — a fundamental change in product strategy based on learning
4 / 5
A product team's Notion document contains the phrase: "We need to decide — do we pivot or persevere?" The company has been building an AI scheduling tool for 18 months with low traction. What does pivot mean in this context?
Pivot — the startup vocabulary for strategic change:
Eric Ries (The Lean Startup) defines a pivot as: "a structured course correction designed to test a new fundamental hypothesis."
Types of pivots: • Zoom-in pivot — a single feature becomes the whole product (Instagram pivoted from Burbn to photo sharing) • Zoom-out pivot — the whole product becomes one feature of a larger product • Customer segment pivot — same product, different target customer • Platform pivot — change from an application to a platform (or vice versa) • Business model pivot — change how you make money (free to paid, SaaS to marketplace) • Technology pivot — same customer problem, different underlying technology
Famous pivots: • Slack — started as a gaming company (Tiny Speck / Glitch); the internal chat tool became the product • Instagram — pivoted from Burbn (check-ins) to photo sharing • YouTube — started as a video dating site • Twitter — started as a podcasting platform (Odeo)
Pivot vs. iteration: • Iteration: "We're changing the onboarding flow" — minor product change • Pivot: "We're changing who we sell to" — fundamental strategy change
Vocabulary for strategic decisions: • pivot — structured change in strategy, keeping company alive • persevere — continue current strategy with more time/data • traction — evidence of user adoption and growth • runway — how long the company can operate before running out of money
5 / 5
A product manager writes in Jira: "This ticket is P0 — it is blocking our dogfooding team and they cannot test the beta build." What do P0 and dogfooding mean?
Priority levels and dogfooding — startup engineering vocabulary:
Priority labels (P0-P4): • P0 — Critical / SEV-1. Drop everything. Site down, security breach, data loss, completely blocked. Fix now. • P1 — High priority. Major feature broken, blocking many users. Fix this sprint / this week. • P2 — Medium. Important but has a workaround. Scheduled work. • P3 — Low. Nice to have. Backlog. • P4 — Minimal impact. Maybe someday.
(Priority labelling systems vary — some companies use Severity 1-5, Critical/High/Medium/Low, or Blocker/Must/Should/Could/Won't from MoSCoW.)
Dogfooding: Origin: 1988 Microsoft manager Eat Our Own Dog Food — encouraging Microsoft to use Microsoft software internally. Now a standard tech industry practice. • Dogfooding = using your own product internally before releasing to customers • Purpose: find issues that would embarrass you with real users, build team empathy with the product • Dogfooding team — internal users of pre-release builds • Beta — the version released to external early adopters (after dogfooding, before GA)
Related product release vocabulary: • internal beta — dogfooding; only internal team uses it • closed beta — invited external users only • open beta — any user can opt in; still pre-release • GA (General Availability) — full public release • canary deployment — deploy to small % of users first to catch issues before full rollout • feature flag — turn a feature on/off for specific users without deploying new code