Forem: Tongshan

The PM Skill No One Teaches: How to Name Your Decision Before Making It

Tongshan — Sat, 23 May 2026 14:28:33 +0000

There's a meeting I've sat in dozens of times. The team has been debating for an hour. Someone finally says "so what are we deciding?" and the room goes quiet — because nobody actually knows.

This is the most common failure mode in product management, and it's invisible. Teams think they're making decisions when they're actually having discussions. The difference is critical, and fixing it starts with one deceptively simple skill: naming the decision.

What "Naming a Decision" Actually Means

Most product discussions orbit around topics, not decisions. "Let's talk about notifications" is a topic. "We're deciding whether to reduce notification frequency for users who haven't opened the app in 7 days — and whether to do it via a global setting or an ML-based individual threshold" is a decision.

The difference seems pedantic until you realize what topic-based meetings produce: alignment on the problem but no clarity on the next action, endless follow-up meetings, and — worst of all — "decisions" that get relitigated two weeks later because nobody wrote down what was actually decided.

A properly named decision has three parts:

The specific choice being made — not a direction or a theme, but the actual fork in the road
The scope — who is affected, what product area, what time frame
What's off the table — what are you NOT deciding right now

Why This Is So Hard in Practice

I managed a content recommendation team at iQIYI. We had a recurring meeting called "recommendation strategy." It covered everything from algorithm choices to editorial curation to notification timing. Every week we'd generate action items. Every week half of them would evaporate because nobody could remember what we'd actually committed to.

The turning point came when I forced us to write the decision name at the top of every meeting doc in one sentence. Just one sentence. It took 15 minutes of argument to write that sentence — and that 15 minutes was the most valuable part of the meeting. Because if we couldn't agree on what we were deciding, we had no business spending an hour deciding it.

The Test for a Well-Named Decision

A good decision name passes this test: if you read it to someone who wasn't in the room, could they tell you what a "yes" looks like vs. a "no"?

"We're deciding our notification strategy" → fails. Too vague.

"We're deciding whether to cap daily push notifications at 3 for users with < 30% open rate, starting next sprint" → passes. A yes means implementing the cap. A no means either a different threshold, a different mechanism, or doing nothing.

How This Connects to the Rest of the Decision Process

Naming the decision is step 1 of the 4-step PM decision framework I've refined over years of practice:

Name the decision — one precise sentence
Define success criteria — what does a good outcome look like, measured how, by when?
Find the killer assumption — the one thing that, if wrong, makes this decision irrelevant
Decide and set a review date — commit, then schedule when you'll revisit

You can't do steps 2–4 without step 1. If the decision isn't named, you can't define success criteria (success for what, exactly?). You can't find the killer assumption (assumption underlying which choice?). You definitely can't set a review date.

The whole framework only works if the foundation is solid — and the foundation is a clean decision name.

A Template Worth Stealing

When I'm facilitating a product decision, I start with this fill-in-the-blank:

"We are deciding [specific action or choice] for [affected users/product area] in order to [goal], by [deadline]. This does NOT include [out-of-scope item]."

Example: "We are deciding whether to replace the rule-based recommendation fallback with an ML model for cold-start users (< 5 plays) in order to improve D7 retention, by end of Q2. This does NOT include changes to the primary recommendation algorithm."

That sentence takes 10 minutes to write and saves hours of misaligned meetings.

The Downstream Effect

When you name decisions well, something else happens: accountability becomes natural. When everyone knows what was decided, and it's written down, "I thought we decided differently" stops being a conversation-stopper. The record is the record.

This sounds obvious. It isn't practiced. Most teams I've worked with or coached have never written a single-sentence decision name for a major product call. They've written PRDs, specs, meeting notes — but not the one sentence that captures what choice was actually made.

If you want to go deeper on decision-naming and the full 4-step framework, I've put it all into a practical handbook: A 4-Step System for Analyzing Any Product Problem — it covers how to move from a named decision through to a confident choice, even under uncertainty.

Start with the name. Everything else follows.

Why Your Product Roadmap Keeps Getting Derailed (And the 4-Step Fix That Stops It)

Tongshan — Sat, 23 May 2026 14:12:25 +0000

Every PM I know has experienced this: you ship the feature, it doesn't move the metric, and six weeks later you're in a retrospective trying to explain what went wrong.

The instinct is to blame execution. Wrong priorities. Engineers who missed requirements. A design that didn't land. But most of the time, the roadmap derailed before a single line of code was written.

Here's what actually causes it — and the framework that stops it.

The Real Problem: Undocumented Assumptions

When a product decision gets made, it carries invisible weight: a set of assumptions that everyone on the team believes to be true but nobody has written down.

"Users will adopt the new workflow."
"The integration will hold at scale."
"Our primary competitor won't ship this first."

These assumptions aren't wrong to make. Every product decision requires them. The mistake is treating them as facts instead of bets.

When one of those hidden assumptions turns out to be false — and it often does — the roadmap collapses. The feature ships but doesn't convert. The metric doesn't move. The business case evaporates.

The 4-Step Fix

I developed this framework after years of product work at iQIYI, watching decisions fail not because they were bad ideas, but because nobody forced the team to get explicit before committing.

Step 1: Name the decision

Write down exactly what decision you're making. Not "we're working on the checkout flow" — that's a project, not a decision. A decision sounds like: "We are investing 6 weeks of engineering to redesign the guest checkout flow in order to improve checkout conversion by 15%."

Specificity forces clarity. When you can't name the decision precisely, you don't understand it yet.

Step 2: Define success criteria

Before you build, write down what good looks like. Not in qualitative terms — in measurable ones. "Checkout conversion rate increases from 62% to 71% within 30 days of launch." That's a success criterion. "Users will like the new flow" is not.

This step is uncomfortable because it creates accountability. That's the point.

Step 3: Find the killer assumption

Ask: "What single belief, if wrong, would cause this project to fail — even if we execute perfectly?"

For the guest checkout example, the killer assumption might be: "Our current checkout drop-off is primarily caused by friction in the form — not by price sensitivity or trust concerns." If that's wrong, redesigning the form is a waste.

Once you name the killer assumption, ask: "What's the cheapest way to test it before committing?" A landing page. A user interview. Five sessions of usability testing. The answer is almost always cheaper and faster than the full build.

Step 4: Decide and set a review date

Make the call: go, no-go, or "test first." Then write down a review date — a specific day when you'll revisit the decision with fresh data.

Without a review date, decisions calcify. The market shifts. The assumption becomes false. The team keeps executing anyway because no one scheduled the moment to ask "is this still right?"

What This Looks Like in Practice

At iQIYI, we were evaluating whether to add a push notification feature to increase content discovery. The team was excited. The data showed engagement correlated with notification delivery.

Before committing to a 3-month build, we ran the 4-step process:

Decision: Build a personalized push notification system to increase D7 retention by 12%
Success criteria: D7 retention improves from 34% to 38% within 60 days of rollout
Killer assumption: Users who don't engage with content recommendations aren't doing so because they forget the app — they're doing so because the recommendations aren't relevant
Test first: Run a 2-week manual notification test with a small cohort using curated content from the editorial team

The test revealed the actual problem: recommendation relevance, not notification timing. We pivoted the roadmap before spending 3 months on the wrong solution.

That's the framework working.

The Pattern That Actually Causes Roadmap Derailment

Roadmaps don't derail because PMs are bad at prioritization. They derail because:

Decisions get made in meetings, not documents
Assumptions stay implicit instead of getting named
Success criteria are vague enough to be unfalsifiable
Nobody schedules the moment to ask "should we still be doing this?"

The 4-step framework is a forcing function. It doesn't make you smarter. It makes your thinking visible — which is the only way to catch the errors before they cost you a quarter.

If you want the full structured framework in a format you can use immediately, I built a decision handbook for exactly this: A 4-Step System for Analyzing Any Product Problem. It's the same process I use, written for PMs who need to make better decisions under uncertainty — not in theory, but in the middle of a real sprint.

The Killer Assumption Test: How to Spot Doomed Product Decisions Before You Ship

Tongshan — Sat, 23 May 2026 13:52:57 +0000

Every product decision rests on at least one assumption that, if wrong, makes the entire effort pointless. I call this the "killer assumption."

Most PMs don't name it. They build, ship, and then explain why the metric didn't move.

Here's how to find the killer assumption before it finds you.

What Is a Killer Assumption?

A killer assumption is the single belief that has to be true for your product decision to be correct. Not all the assumptions — the one that matters most.

For example:

You're building a notification feature to increase re-engagement. The killer assumption: "Users are disengaging because they forget about the product, not because they lost interest in it."
You're redesigning onboarding to improve activation. The killer assumption: "Users who drop off during onboarding are doing so because the flow is confusing, not because the product doesn't match what they expected."

Notice how in both cases, if the killer assumption is wrong, the entire effort is wasted — regardless of how well you execute.

Why PMs Don't Surface It

There are a few reasons this happens:

1. Assumption naming feels like admitting uncertainty. Teams want to project confidence in their roadmap. Saying "here's the one thing we're betting on" feels like weakness. It's actually the opposite — it's intellectual honesty that enables faster learning.

2. The assumption is buried in the framing. When a PM writes "users need better search," the killer assumption ("search is what's blocking user success") is hidden inside the solution statement. If you never separate problem from assumption from solution, you never see it clearly.

3. Everyone already agrees on it. The most dangerous assumptions are the ones that feel obviously true to the whole team. Consensus doesn't validate assumptions. It just means nobody challenged them.

The 3-Question Test

Before committing to any significant product decision, answer these:

Q1: What would have to be true for this to work?
Write down everything. Then circle the one that, if false, would invalidate all the others.

Q2: How confident are we in that assumption, and why?
Not "pretty confident" — name the specific evidence. If you can't, name what evidence you'd need.

Q3: What's the cheapest way to test it before we build?
A customer interview, a landing page, a prototype, a manual experiment. The answer almost always exists. The question is whether the team is willing to slow down enough to run it.

The 4-Step Framework

This is one piece of a broader decision-making process I use with PM teams:

Name the decision (not the feature, the actual decision being made)
Define success criteria upfront ("We'll know this worked if X moves from A to B by date")
Find the killer assumption (the one thing that has to be true)
Set a review date (when will you revisit, and under what trigger conditions)

The killer assumption step is where most teams short-circuit. They move from step 1 directly to step 4, skipping the thing that would tell them whether step 1 was even the right question.

A Real Pattern I've Seen

At iQIYI, we had a team convinced that improving content discovery would increase weekly active usage. The killer assumption was: "Users who are inactive aren't finding content they want."

Running a 2-week test on a sample segment showed the actual pattern: users were finding content fine — they were just finishing their shows and not receiving a compelling "next series" recommendation at the right moment. Completely different problem. Completely different solution.

The original discovery feature would have taken a quarter to build. The recommendation timing fix took two weeks.

Naming the killer assumption before building saved about 10 weeks of engineering time.

The Discipline

The skill isn't finding the assumption — it's getting comfortable naming it out loud before you build, and being willing to run a cheap test before you commit.

Teams that do this ship less and learn more. That's not a bad trade.

If you want the full framework with templates for running this process on your team, I put it in a short handbook: A 4-Step System for Analyzing Any Product Problem

Your PM Retrospectives Are Lying to You

Tongshan — Sat, 23 May 2026 13:41:07 +0000

Every quarter, product teams hold retrospectives. Someone asks "what went well?" and "what didn't?" The team lists bullet points. Someone writes "we should communicate better." Everyone nods. Nothing changes.

The problem isn't the retro format. It's that you never defined what success looked like before the work started — so you can't actually evaluate anything now.

I've run product teams at iQIYI, NIO, and Alibaba. The retrospectives that mattered had one thing in common: a pre-written success criterion that existed before any work began. Every other retro was theater.

The retrospective trap

When you define success after seeing the results, you unconsciously fit the definition to the outcome. If engagement went up 5%, that was the goal. If it went down 5%, you pivot to "we learned a lot." The retro becomes a narrative exercise, not a learning exercise.

Real learning requires a pre-mortem question: "What would we need to see to know this worked?"

That question, answered before the sprint starts, is the only thing that makes a retrospective honest.

The four questions that fix retrospectives

Before any significant initiative, write answers to these four questions:

1. What is the decision we're making?
Not "build feature X." The actual decision: "Are we betting on engagement-led growth over acquisition-led growth this quarter?" Name it. A decision that can't be stated in one sentence is a decision you haven't made yet.

2. What does success look like — exactly, in advance?
One sentence. Measurable. Time-bound. Not "improve retention" but "increase D30 retention from 22% to 28% by July 15." If you can't write this before you start, you're not ready to start.

3. What's the killer assumption?
Every initiative rests on one belief that, if wrong, invalidates the whole effort. Find it. Name it. Write it down. "We're assuming that power users are churning because of the onboarding flow, not the core product." If that's wrong, no amount of onboarding optimization saves you.

4. When is the assumption review date?
Not the ship date — the date you'll check whether the assumption held. Six weeks post-launch, you open the document and ask: did the metric move? Did the assumption prove correct? This is the only retrospective question that matters.

What honest retrospectives look like

With pre-written criteria, your retro becomes a one-page debrief:

Did the metric hit the target? (Yes/No, with data)
Did the killer assumption hold? (Yes/No, with evidence)
What does this tell us about the next decision?

That's it. No "communication" bullet points. No vague learnings. Just a clear verdict on whether the bet you made was right, and what you now know that you didn't before.

The teams that compound the fastest aren't the ones that ship fastest. They're the ones that learn fastest — and learning requires knowing what you were trying to prove before you tried to prove it.

I built a complete 4-step decision framework around this: https://dcljoyful.gumroad.com/l/toPM

Stop Running Sprints on the Wrong Problem: A PM's Checklist Before Building Anything

Tongshan — Sat, 23 May 2026 13:23:15 +0000

Every sprint review I've attended at a product-led company has at least one moment where someone asks: "Wait, why did we build this again?"

The feature ships. The metrics don't move. Retrospectives identify "scope creep" or "unclear requirements." But the actual root cause is almost always the same: the team built something before the decision was clear.

After 10+ years in product across iQIYI, NIO, Alibaba, and consulting for startups, I've developed a 4-question checklist I run through before any sprint begins. It's prevented more wasted cycles than any process tool I've ever used.

The 4-Question Pre-Sprint Checklist

1. Can you name the actual decision in one sentence?

Not the feature. The decision.

"Should we add social sharing or focus on improving the onboarding flow first?" is a decision.

"Build social sharing" is a task.

If your sprint goal is phrased as a task, stop. You've skipped the decision layer. Naming the decision forces you to articulate the trade-off and why you're making it now.

2. What does success look like — and when?

Write this down before the sprint starts, not after.

"DAU increases by 8% within 30 days of launch" is success criteria.

"Users like the new feature" is not.

Without a pre-committed success definition, teams unconsciously move the goalposts after launch. You can't learn from a result you haven't defined in advance.

3. What is the one assumption that could kill this?

Every sprint is a bet. Every bet has one load-bearing assumption — if it's wrong, the whole thing collapses.

For a retention feature: "Users who churn in week 2 are churning because of missing feature X."

If that assumption is untested, you're spending sprint capacity on a hypothesis, not a validated problem. Name it explicitly, and state what evidence you have (or plan to get).

4. What's the review date?

When will you know if the decision was right? Set the date before you ship.

This is the most skipped step and the most valuable. A pre-set review date does two things:

It reduces the emotional cost of committing (because you're not committing forever, just until the review)
It creates a forcing function to actually measure results rather than moving on

Why This Works

Most PM frameworks focus on prioritization — deciding what to build from a list. This checklist focuses on decision quality — making sure the list item you picked actually has a clear problem statement, testable hypothesis, and success definition attached to it.

Teams that skip this end up with full sprints and empty metrics.

Teams that use it ship less and learn more.

I formalized this into a full decision framework for product managers: The PM Decision Framework Handbook — a 4-step system for making faster, better product decisions with stakeholder alignment built in.

The One Question That Exposes Bad Product Decisions Before You Make Them

Tongshan — Fri, 22 May 2026 07:13:26 +0000

Most bad product decisions aren't made at the end of a decision process.

They're made at the beginning — when the team agrees on a direction without asking the one question that would have exposed the flaw.

That question is: "If this one thing turns out to be false, does the whole decision fall apart?"

What a Killer Assumption Looks Like

Every product decision rests on assumptions. Some are safe (users have smartphones). Others are fragile — and if they break, the entire decision breaks with them.

The fragile one is your killer assumption.

Example: You decide to build a social sharing feature. The killer assumption might be: "Users want to share this publicly." If users are actually private about this, the whole feature collapses. Not just underperforms — collapses.

Most teams don't name this assumption. They argue about execution when the real debate should be about whether the foundation is solid.

The Question to Ask

Before committing to any significant product decision, ask your team:

"What is the single assumption that, if wrong, makes this entire decision wrong?"

Force the group to name it. Write it down. Make it visible.

This one step separates teams that learn fast from teams that ship confidently and fail expensively.

What to Do With It

Once you've named the killer assumption, you have two options:

Option 1: Test it. Is there a cheap, fast way to validate or invalidate this assumption before you fully commit? A survey, a prototype, a quick interview, an A/B test?

Option 2: Acknowledge it explicitly. If you can't test it in time, at least document it. Write: "We are proceeding with the assumption that X is true. If we discover X is false by [date], we revisit this decision."

This is not weakness. This is how senior PMs operate.

Why Teams Skip This

Naming a killer assumption feels like doubt. Teams worry it will slow things down, create political tension, or make them look uncertain.

But the alternative is worse: you ship, you discover the assumption was wrong, and now you're explaining to stakeholders why the project failed on something that was knowable in advance.

The teams that name assumptions don't slow down. They speed up — because they stop wasting cycles on the wrong things.

The Framework Behind the Question

This question is Step 3 from a 4-step PM decision framework I've been using for years:

Name the actual decision (not the symptom)
Define success criteria before looking at options
Find the killer assumption
Decide, document your reasoning, and set a review date

If this resonates, I've put the full framework — with templates, worked examples, and decision logs — into a handbook: The PM Decision Framework ($19.90).

It's for PMs who want to make fewer regrettable decisions and build a traceable record of how they think.

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.