DEV Community

Tongshan
Tongshan

Posted on

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

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.

Top comments (0)