4 Steps Every PM Should Follow Before Shipping Anything

Tongshan — Tue, 19 May 2026 02:16:34 +0000

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.

The 4-Step PM Framework I Used for 12 Years at iQiyi, NIO, Alibaba & Horizon Robotics

Tongshan — Mon, 18 May 2026 14:08:47 +0000

After 12 years shipping products at iQiyi, NIO, Alibaba, and Horizon Robotics — I kept running the same mental checklist on every new requirement. I finally wrote it down.

Here's the 4-step framework:

Step 1: Understand the Real Need (Behind the Stated One)

Most requirements arrive wrapped in a solution. Someone says "add a filter" when what they actually need is "find relevant items faster." Your job is to peel back the surface request and uncover the actual user need.

A useful test: Pareto improvement. Does this change make something better without making anything worse? If your understanding of the need forces a painful tradeoff, you probably haven't found the real need yet.

Example from ride-hailing: Drivers said they wanted "to get paid more." The real need was income certainty — predictable earnings, not just higher ones. That single insight explains the entire auto-debit payment flow design.

Step 2: Evaluate the Solution Space

Once you understand the real need, resist building the first solution that comes to mind. Ask:

What are the alternative approaches?
What's the simplest version that addresses the core need?
What constraints (tech, legal, time) narrow the space?

PMs who skip this step consistently over-engineer. The best solution is often the one that removes friction, not adds features.

Step 3: Draw the Flow

Before touching any spec doc, draw the user flow. End-to-end. Every decision point, every handoff, every edge case branch.

This is where most requirements fall apart — not in the happy path, but in the branches nobody thought through. A visual flow forces you to confront those gaps early, when changes are cheap.

Step 4: Enumerate Every UI State

For every screen in the flow, explicitly define all possible states:

Normal — the intended state
Loading — while data is being fetched
Empty — when there's no data yet
Error — when something goes wrong

If you can't describe the Error state for a given screen, the feature isn't ready to spec. Most production bugs come from unhandled states that "nobody thought would happen."

Using This in Practice

I've applied this framework across wildly different contexts — streaming platforms, electric vehicles, logistics, autonomous driving. The specifics change; the checklist doesn't.

If you want the full breakdown with worked examples, decision templates, and real requirement patterns from these industries — I put everything into a 16-page handbook:

👉 The 4-Step PM Framework Handbook — $19.90, instant download

It's the checklist I wish I'd had on day one.

DEV Community: Tongshan