Product Shaping
The Algorithm should shape the whole product, not just the code.
Start With One Sharp Problem
Question product ideas until one painful job remains:
- who is the first user
- what problem already costs them time, money, or attention
- what ugly workaround are they already using
- what outcome makes them say "finally"
Avoid ideas that only become interesting after several future features are added.
Clarify The Offer Before You Scale The Offer
Question what you are actually promising.
Ask:
- what transformation is the user buying
- what category the product truly belongs to
- what sentence explains it without jargon
- what promise would still feel honest if the product stayed small
Delete vague promises and extra claims until the offer is obvious.
Cut the MVP to One Promise
A strong MVP makes one promise well.
Delete aggressively:
- multi-role support
- team features
- permissions grids
- analytics dashboards
- exports
- notifications
- mobile apps
- public APIs
- marketplace integrations
- advanced personalization
The first version should feel narrow but complete.
Simplify the User Flow
Fewer decisions beats more flexibility.
Prefer:
- one CTA over a crowded hero
- one onboarding path over branching journeys
- one form with only essential fields
- defaults over configuration
- one obvious next step after success
Every extra choice creates product debt, support debt, and test debt.
Simplify Monetization Too
Do not build a pricing architecture before you have pricing truth.
Prefer:
- one paid plan before a ladder of plans
- one checkout path before custom quotes
- one billing interval before monthly and annual and seat logic and credits
- one refund policy before exceptions
Complicated monetization often hides uncertainty about the real value proposition.
Simplify Distribution Too
Do not build a growth machine before you know which message lands.
Prefer:
- one believable channel before many weak ones
- direct conversations before broad audience assumptions
- one clear CTA before many competing asks
- one repeatable acquisition loop before stacked experiments
Many teams try to scale distribution while the underlying message is still blurry.
Launch With a Tight Loop
Accelerate contact with reality:
- recruit a small number of target users
- watch them complete the primary flow
- collect objections in plain language
- fix the biggest friction before broadening scope
- measure one leading indicator tied to the product promise
Ship to learn, not to look complete.
Product Deletion Checklist
Before expanding scope, ask:
- If we removed this, would the first user still buy?
- If we delayed this by 90 days, what real damage happens?
- Does this solve a live problem or a forecasted one?
- Are we adding this because a user needs it, or because the product feels too simple?
- Does this feature create new support, state, permissions, or migration burden?