Most PMs I've worked with are smart, well-intentioned, and still consistently ship the wrong things. Not because they're lazy — but because their decision-making process has gaps that don't show up until after launch.
After years as a PM at iQIYI (one of China's largest streaming platforms), I distilled our internal review process into 4 steps. I now run every feature decision through this before anything reaches engineering.
Step 1: Find the Real Need
Users tell you what they want. What they need is usually different.
When someone asks for a "filter" feature, dig deeper. What pain are they actually experiencing? What does their workflow look like without this? The real need is usually one level below the stated request.
Practice: For every request, ask "what problem goes away if we build this?" If you can't answer it in one sentence, you don't know the need yet.
Step 2: Evaluate the Full Solution Space
Once the real need is clear, list every possible solution — not just the obvious one. Aim for at least 5-7 options.
This is where most teams fail: they jump to the first reasonable solution and start debating execution instead of exploring alternatives. The best option is often not the most obvious one.
Practice: Set a timer for 10 minutes and brainstorm solutions without filtering. Include silly ones. Include ones that are "not your job." Then evaluate.
Step 3: Map the Full User Flow
Pick your best solution and draw every step a user takes — from problem awareness to resolution.
Don't just map the happy path. Explicitly map:
- What happens when users get confused
- What the error states look like
- What support sees when things go wrong
- What email/notification gets triggered
I've killed more than a few features at this step when the full flow revealed hidden complexity we weren't prepared to handle.
Step 4: Enumerate All UI States
Every screen has multiple states. Name them all before design starts:
- Empty state
- Loading state
- Error state
- Partial data state
- Success state
- Edge case states
This is the most skipped step. And it's why so many products feel rough — not because the core interaction is bad, but because no one thought about the empty state.
This framework doesn't tell you what to build. It makes sure that whatever you build is the right thing, built right.
I've written this up in more depth — with templates and worked examples — in a short PM handbook: https://dcljoyful.gumroad.com/l/toPM
What steps does your team take before shipping? I'd love to hear what works.
Top comments (0)