Product Management
Defining what to build and why, before Project & Program Management figures out how — product strategy, roadmapping, and prioritization.
This isn't the deep research discipline — interviews, Jobs to Be Done, opportunity-solution trees belong to Research, a separate skill. This is the fast, practical version: what to do in week one, before you've earned the time for a full research program, so you're not writing a Vision Statement's Target Customer field from a guess.
Audit What Already Exists — read support tickets, sales call notes, churn data, NPS/CSAT, usage analytics, and social media or review mentions before running anything new. For consumer products, a customer satisfaction or social-listening team is often already mining this and has a dashboard built — find it before starting from zero.
Talk to Internal Stakeholders First — sales, support, and customer success already have pattern-matched customer knowledge. Borrow it before generating new research from scratch.
Segment the Customer Base — not every user of the product is the same customer. Figure out which segment actually matters right now, not just which one's loudest.
Get Direct Customer Contact — nothing replaces hearing it yourself. A secondhand summary always loses the detail that mattered.
Synthesize into a Customer Profile — turn scattered inputs into one usable page. This becomes the actual Target Customer field on Product Vision & Strategy.
The most common mistake isn't skipping research — it's skipping the free research that's already sitting in a ticket queue. Talking to five customers before reading two hundred existing support tickets means re-discovering what your own team already knew.
Apple didn't have iPod tickets yet — but the Mac team already had years of data on how loyalists ripped CDs and organized sprawling MP3 folders by hand.
Two hundred RouteWise support tickets tagged "POD" had been sitting unread — every one was a driver losing a proof-of-delivery photo.
The team already building a digital jukebox app for the Mac knew exactly where existing MP3 players failed — slow transfers and tiny storage, not the music itself.
Sales already knew RouteWise's #1 lost-deal reason — no offline mode for drivers working in warehouses with no signal.
Not every music fan was the target — the focus was people who already owned a large, organized digital library, not someone buying their first single-artist player.
Two very different users share one RouteWise login — dispatchers who plan routes at a desk, and drivers who need three buttons that work with gloves on.
Early prototypes were tested against how people actually loaded and organized their own libraries, not how an engineer assumed they would.
Five driver ride-alongs surfaced the offline problem before a single dashboard chart did.
The profile came down to one line — someone who already owns the music and just wants all of it, everywhere, without the hassle.
One page — "drivers, mid-shift, spotty signal, gloves on" — became the actual Target Customer field on the vision doc.
Paste this into ChatGPT, Claude, or whatever AI tool you use:
"A customer complained" isn't a scored opportunity — it's a complaint with a vote count. Six steps to turn a pile of pain points into the short list that actually earns a Vision Statement's Problem/Opportunity field:
List Every Candidate Problem — pull every complaint, ticket theme, and stakeholder pain point onto one unranked list before judging any of them. Also include friction nobody's complaining about — customers stop mentioning what they've quietly gotten used to — and emerging technology that just became newly possible, even with no customer signal at all.
Score Frequency & Severity — how often does this happen, and how bad is it when it does? A rare-but-catastrophic problem and a frequent-but-minor one don't compete without both numbers.
Estimate Reach — how many customers, or how much of the business, does this actually touch. A painful problem hitting 2% of customers loses to a mild one hitting 60%, more often than people expect.
Separate Root Cause from Symptom — is this the actual problem, or a downstream symptom of something already on the list? Fixing a symptom twice wastes the effort of fixing it once.
Check Strategic Fit — does solving this ladder up to where Product Vision & Strategy is already trying to go, or is it a distraction dressed as an opportunity?
Cut to a Short List — narrow the candidates down to the few worth carrying into Product Vision & Strategy's Problem/Opportunity field.
Three things to watch for while building the candidate list — each one easy to miss in a different way:
What customers complain about loudest isn't always the real problem. The classic case is the slow-elevator complaint — building managers who tried fixing it by making elevators literally faster spent a fortune for marginal gains. The complaint was about speed; the actual problem was boredom during the wait. Installing mirrors next to the elevators (later, TVs) didn't shave a second off the ride, but complaints dropped anyway, because people stopped noticing the wait once they had something to look at.
The biggest opportunity is often something nobody complains about at all, because they've quietly adapted to the friction and stopped noticing it — you can't complain about the absence of something that isn't in your vocabulary yet. Amazon's 1-Click checkout, Uber's live map showing your driver approaching, Netflix's "Skip Intro" button, and 3M's Post-it Note (a failed strong-adhesive experiment employees started using internally long before anyone asked for temporary sticky notes) all removed friction or created value nobody had a name for yet. A candidate list built only from complaints will always miss opportunities like that.
A third source doesn't start from a customer signal at all — it starts from noticing that two unrelated pieces of technology have just become available at the same time. The iPod is the real example: Apple's head of hardware noticed in early 2001 that Toshiba had just built a tiny 1.8-inch hard drive with no product to put it in, and an unclaimed chipset reference design already existed — the pieces to build a real portable music player suddenly existed, and nobody else had noticed they fit together. This kind of opportunity won't show up in a complaint list or a ticket queue, because the product it enables doesn't exist yet for anyone to complain about. It comes from watching what's newly possible, not just what's newly painful — exactly what a Research practice should be scanning for, alongside customer interviews.
The most common failure is skipping straight from "a customer complained" to "we should build X" — that's a solution wearing a problem's clothing. Score the problem before anyone's allowed to pitch a fix for it.
List Every Candidate Problem: Candidates on the table — too few songs fit, transfers were painfully slow, batteries died fast, and interfaces were clumsy. Four different problems, all mixed together.
List Every Candidate Problem: Candidates on the table — lost proof-of-delivery photos, drivers going offline in warehouses, slow onboarding, and confusing route-reassignment screens.
Score Frequency & Severity: Slow transfers hit every single use, every time; short battery life was annoying but only on longer days away from a charger — frequency won.
Score Frequency & Severity: Lost proof-of-delivery photos happened on nearly every shift with a warehouse stop; confusing reassignment screens were annoying but rare — both numbers pointed the same direction.
Estimate Reach: Low storage capacity affected anyone with more than a handful of CDs already ripped — nearly every existing MP3 player owner, not a niche.
Estimate Reach: The offline problem touched every driver on every route with a low-signal stop — closer to 80% of shifts than anyone on the team had assumed.
Separate Root Cause from Symptom: Clumsy interfaces and slow transfers both traced back to the same root cause — nobody had designed the hardware and software together as one system.
Separate Root Cause from Symptom: Lost photos and stalled route status were two symptoms of the same root cause — the app assumed a live connection existed for the whole shift.
Check Strategic Fit: A device that solved storage and speed fit a hardware-plus-software company's actual advantage; a fix that required every other manufacturer to adopt a shared standard didn't.
Check Strategic Fit: Fixing offline reliability matched RouteWise's actual differentiation bet; redesigning the reassignment screen was a real annoyance but didn't ladder up to anything strategic yet.
Cut to a Short List: One sentence — capacity and speed, solved together, for people who already owned real libraries. Everything else could wait for a later release.
Cut to a Short List: One problem — proof-of-delivery and route status have to survive zero signal for a full shift. Everything else got parked for a later cycle.
Paste this into ChatGPT, Claude, or whatever AI tool you use:
A vision without a strategy is a poster. A strategy without a vision is a to-do list. Fill in these eight fields to connect the two, and revisit them whenever a roadmap decision needs a tiebreaker. This is one rung down from Organization's Strategic Planning — company Vision/Mission/Values set the ceiling, this translates them into one product's bets.
Vision Statement — one sentence, the future state you're aiming at (3-5 years out), not a list of things to ship.
Target Customer — who this is for, and just as important, who it's explicitly not for.
Problem / Opportunity — the unmet need in the market that justifies the vision.
Why Now — what's already true that makes this winnable today, not five years ago or five years from now. Two different flavors, and a strong case often has both: technology (a new component or capability just became available) and culture (the market has already normalized the behavior this needs).
Strategic Bets — the 2-4 big choices this cycle that ladder up to the vision. A bet is something you could be wrong about — if it's not risky, it's not a bet, it's a feature.
Differentiation — why this, and not a competitor or the status quo.
Non-Goals — deliberately out of scope. Naming what you won't do protects the bets you did make.
Success Measure — how you'll know the strategy is working.
The most common failure isn't a bad vision statement — it's strategic bets that are actually just a feature list wearing a strategy costume. A real bet names a belief that could turn out to be wrong.
"People don't buy what you do, they buy why you do it."
— Simon Sinek, Start with Why
Start with Why is where the Strategy-is-the-why framing comes from — the same idea applies inside a product team, not just to customers. People don't follow the plan, they follow the reason behind it: a team that understands why a product matters can improvise its way through a plan that's wrong; a team that only has the plan is stuck the moment reality doesn't match it.
If "strategy" still feels slippery after that, Richard Rumelt's Good Strategy Bad Strategy is the sharpest explanation of why: most things called strategy are really just goals or vision statements in disguise. Real strategy, in his framing, is a diagnosis of the actual problem, a guiding policy for dealing with it, and a set of coherent actions that carry it out — worth reading before filling in this section's Strategic Bets field for real.
Differentiation isn't just positioning — sometimes it's protectable. If the mechanism behind a Strategic Bet is genuinely novel, not just a better interface on an existing idea, loop in Legal or IP counsel early enough to file before a competitor sees it launched. Most differentiation isn't patentable, and that's fine — but it's worth a five-minute gut check, not a default no.
Vision: Every song you own, in your pocket, always with you.
Vision: Every delivery, tracked and proven, even when the driver's phone has zero bars.
Target Customer: People who already own a real music collection and are tired of lugging around a CD binder — not casual listeners happy with the radio.
Target Customer: Regional last-mile delivery companies running 50-500 drivers — not solo couriers, and not massive carriers who'll build this in-house.
Problem / Opportunity: Existing MP3 players in 2001 held a dozen songs and took forever to load. Nobody had solved "my whole library, always with me."
Problem / Opportunity: Dispatchers were flying blind the moment a driver walked into a warehouse with no signal — routes silently stalled and nobody knew until a customer called angry.
Why Now (technology): Toshiba had just built a tiny 1.8-inch, 5GB hard drive with no product to put it in, and an unclaimed chipset reference design already existed — the pieces to build this suddenly existed, waiting for someone to notice they fit together.
Why Now (technology): Cheap Android hardware and larger on-device storage finally made a real offline mode possible — five years earlier, the phones dispatchers issued couldn't have held a full day's route data locally.
Why Now (culture): The Sony Walkman had already normalized wearing headphones and listening to music in public — the iPod didn't have to create that behavior, just make it better.
Why Now (culture): Regional carriers had already shifted to a gig-style, high-turnover driver workforce — a dead-simple app that just needed to work reliably fit how drivers already operated, no retraining required.
Strategic Bet: Bet on a tightly closed hardware-plus-iTunes system over an open, mix-and-match MP3 player market — control the whole experience end to end.
Strategic Bet: Bet on offline-first over always-connected — build as if signal is the exception, not the assumption, even though it makes the engineering harder.
Differentiation: A 5GB hard drive, a scroll wheel you could operate one-handed, and FireWire sync fast enough to load 1,000 songs in under 10 minutes.
Differentiation: The only driver app in the category that keeps working — full route data, proof-of-delivery capture, status updates — with zero signal for an entire shift.
Non-Goals: Not a phone, not a video player, not a photo album — just music, done better than anyone else, at launch.
Non-Goals: Not a fleet-maintenance tool, not a payroll system, not a customer-facing tracking page — just get the delivery proven, reliably, every time.
Success Measure: iPod becomes the default way people carry their music, not just another player on the shelf.
Success Measure: Proof-of-delivery capture succeeds on the first try 99% of the time, signal or no signal.
Paste this into ChatGPT, Claude, or whatever AI tool you use:
Before committing engineering time, pressure-test the plan from Product Vision & Strategy using Amazon's PR/FAQ method, the core of their Working Backwards process — write the press release and FAQ as if the product already shipped and succeeded, before building any of it.
Dated years in the future, not today — written as if the product already launched and succeeded. Plain customer-facing language, the success metrics it actually hit, and a quote from a customer or key stakeholder. A press release can't hide behind jargon — if the Vision Statement, Target Customer, and Differentiation don't survive being written this way, they weren't clear enough to begin with.
Two sets of questions: external ones a real customer would ask, and internal ones the team is quietly worried about — cost, feasibility, "why hasn't a competitor done this already." Answering them before anyone else asks is a direct pressure test on Why Now, Non-Goals, and every Strategic Bet.
If a field from Product Vision & Strategy can't survive being written into the press release or defended in the FAQ, it's not ready — sharpen it before moving on to Product Requirements.
"The fact that most PR/FAQs don't get approved is a feature, not a bug."
— Colin Bryar & Bill Carr, Working Backwards: Insights, Stories, and Secrets from Inside Amazon
Most ideas shouldn't survive this exercise. Spending an afternoon writing a press release is far cheaper than spending a quarter building the wrong thing — the point isn't to get every PR/FAQ approved, it's to find out which ones deserve to be.
Paste this into ChatGPT, Claude, or whatever AI tool you use:
A Strategic Bet from Product Vision & Strategy is still a sentence, not a spec. A PRD is where it becomes buildable — twelve fields to fill in before engineering starts estimating:
Problem Statement — the specific problem this solves, one level more concrete than the strategy-level Problem/Opportunity it came from.
Goals & Success Criteria — what shipped-and-working actually looks like, measurably.
Opportunity Cost If We Don't — what it actually costs to leave this unsolved. If there's no real cost to inaction, this isn't as urgent as it feels.
Current Journey / Landscape — how this works today, step by step, before any of this ships. You can't measure improvement against a state nobody wrote down.
Proposed Solution — the actual approach, in plain language, before it gets broken into stories.
Scope (In / Out) — what's included in this release, and what's explicitly deferred.
User Stories — as a [named persona], I want [action], so that [outcome]. Name the persona — "a user" isn't specific enough to write a real story against — and tag each story with a priority (P0-P3, defined below).
Acceptance Criteria — the specific, testable conditions that make each story countable as done.
Assumptions, Dependencies & Constraints — what has to be true, which other teams and systems this relies on, and any hard limits — budget, timeline, technical — the solution has to work inside.
Measurable Outcomes (Key Metrics for Success) — the specific numbers tracked after launch that prove this actually worked, not just the pre-launch definition of done.
Prioritization Framework — how must-haves get separated from nice-to-haves when time or resources run short: P0 Must Have (can't ship without it), P1 Should Have (real value, not launch-blocking), P2 Could Have (nice to have, future roadmap), P3 Won't Have (low value or explicitly out of scope).
Open Questions — what's still unresolved, tracked instead of silently guessed at.
Built out as a single document:
Users can't carry more than a handful of songs without lugging a separate device for every format.
Drivers lose proof-of-delivery photos and dispatchers can't see route status the moment a driver loses signal.
Ship a device that holds 1,000 songs and syncs a full library in under 10 minutes.
Ship offline mode that captures and locally queues proof-of-delivery for an entire shift with zero signal, syncing automatically the moment signal returns.
Every quarter without a real solution, more customers buy a competing player — and once someone's library lives somewhere else, they don't come back.
Every month without offline mode, RouteWise loses another regional carrier to a competitor that doesn't drop routes when a driver loses signal.
Rip a CD, wait through a slow USB transfer, fit maybe 20 songs on a device, then repeat the process the next time you want new music.
A driver's app freezes the moment they lose signal in a warehouse — no new stops, no way to mark a delivery complete, and dispatch sees nothing until the driver walks back outside.
A pocket-sized device with a real hard drive, a one-handed scroll wheel, and FireWire syncing, paired with iTunes.
An offline-first driver app that queues every action locally — stops, photos, signatures — and syncs the moment signal returns.
Music playback and sync.
Photos, video, wireless — future release.
Offline proof-of-delivery capture and local queueing.
Offline route re-optimization — needs a live connection this release.
A 4-minute song transfers in under 2 seconds over FireWire; the device holds at least 1,000 typical MP3s at 128kbps.
A full 8-hour shift of stops, photos, and signatures queues locally and syncs within 30 seconds of regaining signal, with zero data loss.
Depends on iTunes shipping in time, and FireWire being standard on the target Mac lineup. Constraint: must ship by the 2001 holiday season.
Depends on 2GB+ free storage on issued devices and batched sync support on the backend. Constraint: must work on the 3-year-old Android devices carriers have already issued.
Time to load 1,000 songs, holiday-quarter unit sales, and repeat Mac/iTunes customer rate within six months.
Proof-of-delivery sync success rate, time from signal-regained to full sync, and carrier renewal rate after the first offline-heavy season.
Does the scroll wheel need to be touch-sensitive, or will a physical click suffice?
What happens if a driver's queued data never syncs before their shift resets at midnight?
Paste this into ChatGPT, Claude, or whatever AI tool you use:
Everything above answers what to build and why — the customer, the opportunity, the vision, the requirements. Once that's settled, Project & Program Management picks up the how: chartering the work, scoping it, planning the timeline, and actually shipping it.