Product Development
The ongoing craft of building product — from first prototype through mature product at scale. Distinct from product-market-fit (finding it) and ideation (choosing what to build), product development is the continuous process of making the product better.
The Two Tracks: Discovery and Delivery
Marty Cagan’s framework: product development is two parallel processes, not one sequential pipeline.
Product Discovery — figuring out what to build:
- What problems do users actually have?
- Will they value this solution?
- Can they use it? (usability)
- Can we build it? (feasibility)
- Does it serve the business? (viability)
Product Delivery — building and shipping what you’ve validated:
- Engineering, testing, deployment
- Quality, reliability, performance
- Iteration based on real usage data
These run simultaneously. While delivering this week’s feature, you’re discovering next month’s.
The Four Product Risks
Every product decision carries four risks that must be managed:
| Risk | Question | How to Test |
|---|---|---|
| Value | Do customers need this? | Customer interviews, prototypes, landing pages |
| Usability | Can they figure it out? | User testing, session recordings, onboarding metrics |
| Feasibility | Can we build it? | Technical spikes, architecture reviews, time estimates |
| Viability | Does it work for the business? | unit-economics, pricing tests, market sizing |
Test value and usability before investing in feasibility. Most wasted effort comes from building something technically impressive that nobody wants.
Feature Teams vs Empowered Teams
| Feature Teams (weak) | Empowered Teams (strong) |
|---|---|
| Given features to build | Given problems to solve |
| Execute a roadmap | Own outcomes |
| Success = shipped on time | Success = moved the metric |
| PM writes requirements | PM sets context, team decides approach |
| ”Build what stakeholders asked for" | "Find the best solution to the user problem” |
Startups should be empowered teams by default — you don’t have enough people for bureaucracy.
Product Development by Stage
Pre-PMF: Build to Learn
The product IS the experiment. Everything Ries and Blank teach applies:
- minimum-viable-product: smallest experiment for maximum learning
- lean-startup: Build → Measure → Learn, repeat
- Speed of iteration is your only advantage
- “If you’re not embarrassed by the first version, you launched too late”
The metric: learning velocity — how fast you test and invalidate assumptions.
Post-PMF: Build to Delight
Once you have PMF, the game changes from searching to executing:
- Vohra’s 50/50 roadmap: half on strengths (what “very disappointed” users love), half on barriers (what blocks “somewhat disappointed” users)
- Altman: improve 5% weekly — compound growth becomes significant
- Watch users interact with the product directly
- Keep the product simple — resist feature bloat
The metric: Sean Ellis score — maintain ≥40% “very disappointed”
At Scale: Build to Defend
The product must now serve diverse user segments while maintaining quality:
- Dual-track agile: discovery and delivery in parallel
- Platform thinking: build infrastructure others can extend (network-effects)
- Technical debt becomes a real concern — balance speed with sustainability
- founder-mode: stay involved in product decisions even as you delegate operations
The metric: retention by cohort — are new users sticking as well as early users?
Practical Principles
1. Talk to Users Constantly
Altman: “Founders must maintain direct user contact without intermediaries as long as possible.” Literally sit in customer offices when possible. Follow Mom Test rules.
2. Ship Weekly
Nothing is finished until it’s released (PG). Create a weekly shipping cadence. Small, frequent releases beat big, infrequent ones — they reduce risk, accelerate learning, and maintain momentum.
3. Measure What Matters
Use AARRR to identify your bottleneck stage. Pair metrics (Rabois) to prevent gaming. Avoid vanity metrics.
4. Say No More Than Yes
The best product decisions are what you DON’T build. Every feature adds complexity, maintenance burden, and cognitive load. Rabois’ editing metaphor applies to product: simplify relentlessly.
5. Love the Problem, Not the Solution
Fall in love with the user’s problem, not your solution. Solutions change (that’s pivoting). Problems persist.
See Also
- product-market-fit
- minimum-viable-product
- lean-startup
- customer-development
- startup-metrics
- execution
- scaling
- the-validation-stack
Sources
- Startup Playbook — Sam Altman
- Lean Startup Principles — Eric Ries
- Superhuman’s PMF Engine — First Round Review
- Do Things That Don’t Scale — Paul Graham