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.
