Methodology
How I build, improve and fix products.
Three playbooks for the three situations every product team faces. Enterprise practice sets the gates; startup practice supplies the evidence.
One integrated process
Strategy, discovery, evaluation, development and launch run as one system.
Product innovation is one integrated process: strategy, discovery, evaluation, development and launch run as a single system, with the product and its go-to-market developed in parallel.
Phases based on Crawford and Di Benedetto, New Products Management.
The three playbooks
01 ยท New Product Development
Earn the right to build: each phase must clear a gate of evidence.
When I use it
A new market, segment or product bet with high uncertainty.
Phases it covers
- 01 Opportunity
- 02 Concept
- 03 Evaluation
- 04 Development
- 05 Launch
Enterprise practice brings rigor and governance; startup practice brings speed and evidence. I combine both.
Step 01
Opportunity identification and selection
Choose where to play.
- Key question
- Which arena fits our strengths and a real unmet need?
- Output artifact
- Charter and target opportunity
- Exit criterion
- Opportunity approved against strategy and market evidence.
- Enterprise practice
- Startup practice
Step 02
Concept generation
Create solution concepts from real problems.
- Key question
- What solution delivers the benefit users value most?
- Output artifact
- 2 to 3 concept statements
- Exit criterion
- Concepts tied to validated pains.
- Enterprise practice
- Startup practice
Step 03
Concept and project evaluation
Kill weak ideas early and cheaply.
- Key question
- Will they buy it, can we build it, does it pay?
- Output artifact
- Go or no-go with a forecast
- Exit criterion
- Value and viability risks reduced with evidence.
- Enterprise practice
- Startup practice
Step 04
Development
Build the right product and its go-to-market in parallel.
- Key question
- What exactly must it do, and how will it reach users?
- Output artifact
- Tested product and launch plan
- Exit criterion
- Protocol met; usability, QA and evals pass.
- Enterprise practice
- Startup practice
Step 05
Launch and life cycle
Reach the market and learn fast.
- Key question
- Is adoption on track, and what do we do if not?
- Output artifact
- Launch dashboard, contingency triggers and next bets
- Exit criterion
- Adoption and retention signal that justifies scaling.
- Enterprise practice
- Startup practice
Six dimensions in this playbook
Product frameworks
- Innovation charter and gates
- JTBD and opportunity trees
Technical knowledge
- Build vs. buy and stack choice
- AI feasibility and cost
User-centered design
- JTBD interviews
- Concept and usability tests
Validation
- Concept tests and A-T-A-R
- 4 Big Risks
Communication
- Product protocol or PR/FAQ
- Gate reviews
Stakeholder management
- Executive alignment on the bet
- Partners and pilot customers
02 ยท Feature Development
Ship the change that moves a metric, then prove it did.
When I use it
Improving an existing product for current users.
Phases it covers
- 01 Opportunity (not covered)
- 02 Concept (not covered)
- 03 Evaluation (not covered)
- 04 Development
- 05 Launch
Enterprise practice brings rigor and governance; startup practice brings speed and evidence. I combine both.
Step 01
Frame
Define the problem from evidence.
- Key question
- What user or business outcome moves?
- Output artifact
- Problem brief with a target metric
- Exit criterion
- Problem tied to a measurable outcome.
- Frameworks
Step 02
Prioritize
Choose the highest-impact bet.
- Key question
- Why this, and why now?
- Output artifact
- Ranked backlog and Now-Next-Later roadmap
- Exit criterion
- Trade-offs agreed with the team.
- Frameworks
Step 03
Specify
Make it buildable.
- Key question
- What exactly is done?
- Output artifact
- Spec with success metrics
- Exit criterion
- Engineering and design sign-off.
- Enterprise practice
- Startup practice
Step 04
Build and test
Reduce usability and quality risk.
- Key question
- Does it work for users?
- Output artifact
- Tested build and experiment plan
- Exit criterion
- Passes usability and QA; evals pass.
- Frameworks
Step 05
Ship and learn
Release safely and measure.
- Key question
- Did it move the metric?
- Output artifact
- Release notes, impact readout and contingency triggers
- Exit criterion
- Adoption measured against triggers; iterate or stop.
- Enterprise practice
- Startup practice
Six dimensions in this playbook
Product frameworks
- RICE and Kano
- Product protocol and PRD
Technical knowledge
- APIs and instrumentation
- Feature flags and AI evals
User-centered design
- Usability testing
- Feedback loops
Validation
- A/B tests
- Launch tracking
Communication
- Specs and sprint demos
- Release notes
Stakeholder management
- Product trio
- Sales and CS enablement
03 ยท Bugs and Incidents
Quality is a customer promise: restore it first, then fix the system that broke it.
When I use it
Something breaks or quality drops.
Phases it covers
- 01 Opportunity (not covered)
- 02 Concept (not covered)
- 03 Evaluation (not covered)
- 04 Development
- 05 Launch
Enterprise practice brings rigor and governance; startup practice brings speed and evidence. I combine both.
Step 01
Triage
Size the impact fast.
- Key question
- How many users, how badly, since when?
- Output artifact
- Severity level and owner
- Exit criterion
- Owner and priority set.
- Frameworks
Step 02
Diagnose
Find the root cause.
- Key question
- Why did it really happen?
- Output artifact
- Root cause statement
- Exit criterion
- Cause reproduced and confirmed.
- Frameworks
Step 03
Fix and verify
Restore service safely.
- Key question
- Is it fixed without new damage?
- Output artifact
- Verified fix
- Exit criterion
- Fix confirmed in production.
- Frameworks
Step 04
Communicate
Keep trust.
- Key question
- Who needs to know what, and when?
- Output artifact
- Status updates and a customer note
- Exit criterion
- Affected users and teams informed.
- Frameworks
Step 05
Prevent
Stop it from recurring.
- Key question
- What system change prevents this class of issue?
- Output artifact
- Postmortem, updated acceptance criteria and regression tests
- Exit criterion
- This class of issue cannot recur unnoticed.
- Enterprise practice
- Startup practice
Six dimensions in this playbook
Product frameworks
- Severity by impact
- 5 Whys and postmortem
Technical knowledge
- Observability and data validation
- Rollback
User-centered design
- User impact first
- Plain-language updates
Validation
- Reproduction
- Regression tests and evals
Communication
- Incident updates
- Postmortem
Stakeholder management
- Engineering and CS
- Affected customers
Applied in
At a glance
The same six dimensions, tuned to each situation
Open any cell for the detail.
| Dimension | New Product Development | Feature Development | Bugs and Incidents |
|---|---|---|---|
| Product frameworksStructured thinking and prioritization | |||
| Technical knowledgeCredibility with engineering, feasibility judgment | |||
| User-centered designDecisions start from real user evidence | |||
| ValidationRisk is tested before it is built or shipped | |||
| CommunicationClear written and verbal alignment | |||
| Stakeholder managementAlignment across teams and leadership |
Product frameworks
- New product
- Innovation charter and gates ยท JTBD and opportunity trees
- Feature
- RICE and Kano ยท Product protocol and PRD
- Bugs and incidents
- Severity by impact ยท 5 Whys and postmortem
Technical knowledge
- New product
- Build vs. buy and stack choice ยท AI feasibility and cost
- Feature
- APIs and instrumentation ยท Feature flags and AI evals
- Bugs and incidents
- Observability and data validation ยท Rollback
User-centered design
- New product
- JTBD interviews ยท Concept and usability tests
- Feature
- Usability testing ยท Feedback loops
- Bugs and incidents
- User impact first ยท Plain-language updates
Validation
- New product
- Concept tests and A-T-A-R ยท 4 Big Risks
- Feature
- A/B tests ยท Launch tracking
- Bugs and incidents
- Reproduction ยท Regression tests and evals
Communication
- New product
- Product protocol or PR/FAQ ยท Gate reviews
- Feature
- Specs and sprint demos ยท Release notes
- Bugs and incidents
- Incident updates ยท Postmortem
Stakeholder management
- New product
- Executive alignment on the bet ยท Partners and pilot customers
- Feature
- Product trio ยท Sales and CS enablement
- Bugs and incidents
- Engineering and CS ยท Affected customers
Cross-cutting layers
Business and AI run through every playbook
Business layer
Every phase answers to viability.
- Arena, goals and rules for the bet
- Core, adjacent and transformational
- Sales forecast from adoption rates
- LTV/CAC, payback, contribution margin, AI token cost per task
- Subscription, usage, outcome or hybrid
- Product-led, sales-led or marketing-led, chosen by product complexity, price point and buyer; time to value is the PLG success metricApplied inPunchNFIT: product-ledTaxfyle TXF: marketplace supply-side launch
AI layer
AI earns its place through evidence.
- Stack selection by differentiation, cost and control
- Answers grounded in company data, with sources
- Tools, steps and guardrails for each agent
- Evals and error analysis before scale
- Agency grows only as control allows
- Suggest, then answer with review, then alone
- Data privacy: sensitive data stays in-house
Product sense
Good products sit where all three lenses overlap
Viability is the business lens, desirability the user lens, feasibility the AI and technology lens. A playbook step is done only when all three hold.
Select a lens or the navy center to see what it checks.
Venn diagram of three overlapping circles: Viability (Business Strategy), Desirability (Human-Centered Product), Feasibility (Tech & AI Strategy). The area where all three overlap is filled navy and labeled Product sense.
See the playbooks in action
Three products, each built with the people who use them and mapped step by step to the playbook it used.