Problem-First Product Development
Give teams behavior problems to solve, then measure outcomes instead of feature output
- Difficulty
- Advanced
- Time to result
- ~months to results
- Steps
- 5
- Confidence
- 98%
Problem-First Product Development replaces feature directives with customer-behavior outcomes. A founder or PM describes the problem, explains why it matters, and gives the cross-functional team room to generate alternatives. The team compares those options, chooses a solution transparently, ships it, and tests whether the intended behavior changed. For example, the goal might be increasing use from twice to five times per week; an iOS app is only one possible tactic alongside improving the web experience or changing another part of the journey. This mechanism uses the judgment of engineers and designers, creates ownership, and prevents a feature-factory culture where teams celebrate releases without knowing whether they helped customers or the business.
Origin
Rajaram named founder over-involvement as the biggest product-development pitfall he sees. He contrasted directing a team to build an iOS app with asking it to increase usage frequency and evaluate several possible solutions.
Core principles
- 01Teams create better solutions when leaders define the problem rather than dictate the tactic
- 02A product change matters only if it changes customer behavior
- 03Transparent reasoning builds ownership and decision quality
- 04Shipping volume is not a substitute for measured impact
How to run it
- 1
Define the behavior problem
Express the need as a measurable change in customer behavior, not as a feature request. Give the team the context and evidence behind the desired outcome.
Pro tip Use a before-and-after behavior statement, such as moving usage from twice to five times per week.
Watch out A disguised instruction such as 'solve acquisition by building an app' is still a tactic.
- 2
Generate multiple solutions
Have engineers, design, and product brainstorm different ways to change the behavior. Include options that improve an existing surface before assuming a new product is required.
Pro tip Ask for at least three materially different approaches.
- 3
Choose transparently
Compare expected impact, effort, learning value, and risk. Explain why the selected approach beats the alternatives so the team understands the decision.
Watch out Opaque decisions teach teams to wait for instructions.
- 4
Ship an outcome test
Build the selected solution with a clear measurement plan. After release, test whether the target behavior actually changed.
Pro tip Define the measurement before implementation so success cannot be rewritten after launch.
- 5
Learn instead of counting features
Keep, revise, or remove the solution based on the observed behavior. Judge the team by problem-solving and impact rather than the number of releases.
Watch out A shipped feature with no behavioral effect is output, not impact.
In the wild
Instead of telling a team to build an iOS app, a leader asks it to increase the percentage of customers using the service five times a week rather than twice. The team can compare an app with improvements to the web experience and other tactics, then test the strongest option.
→ The team owns the solution and the company learns which change actually affects usage.
Common mistakes
Dictating the solution
Prescribing what to build disempowers the team and wastes the problem-solving ability of engineers and designers.
Celebrating shipment without impact
A feature factory treats release volume as success even when customer behavior does not change.
Is it for you?
Best for
Product-development teams whose founders or PMs are prescribing features and leaving engineers and designers underused.
Not ideal for
Routine compliance or maintenance work where the required implementation is externally fixed.
From the episode
Gokul Rajaram on designing your product development process, when and how to hire your first PM, a playbook for hiring leaders, getting ahead in you career, how to get started angel investing, more