In my first years in product management, I had all the tools: Jira boards, sprint backlogs, wiki pages, stakeholder decks. Yet the same conversations kept recurring. About priorities. About why we’d dropped things. When I mapped two sprints of actual work against the type of contribution each task made, the pattern was obvious. I wasn’t overloaded. I was unbalanced. The category I was systematically ignoring was Clarity — the one that makes every other type of work more effective.
The four types of PM work
I use a framework to classify what PMs actually do. Not what we should do, not what the job description says. Four categories, defined by the kind of contribution each task makes:
- Value: ensuring the team works on things that create real impact for customers and the business.
- Enablement: removing blockers so the team can actually deliver.
- Maintenance: keeping existing systems, processes, and products stable and reliable.
- Clarity: creating shared understanding of goals, priorities, and decisions.
Each task belongs to one primary category. A meeting you can’t assign to a single category isn’t versatile. It’s unfocused. Forcing a primary classification is the point.
This isn’t a priority framework. It doesn’t tell you what to do first. It’s a classification framework. It tells you what you’ve been doing, so you can see where the gaps are.
This framework occupies a narrower position than most PM leverage models: it exists to make visible the one category that every other framework treats as ambient. Clarity isn’t a subset of communication or leadership. It’s a distinct category of output with its own deliverables, and treating it that way changes what you prioritize.
Most PMs, if they map their work honestly, cluster in two categories: Value and Enablement — both focused on delivery. The rest is either empty or contains work that was never consciously chosen.
Clarity is not discovery
This is where most people push back: “Isn’t Clarity just product discovery?”
Discovery asks what should we build and for whom? It generates evidence: user interviews, experiments, prototypes, data analysis. Its output is confidence that a problem is worth solving and that a solution will work.
Clarity asks does everyone involved understand what we’re doing, why, and what we chose against? Its output is shared understanding across the team and the organization.
You can do rigorous discovery and still have a Clarity gap. I’ve seen teams run excellent experiments, validate assumptions, and ship the right thing, while three stakeholder groups each held a completely different mental model of the product’s direction. The discovery was sound. The reasoning never left the discovery team’s heads.
Discovery produces evidence. Clarity distributes understanding. Conflating them is how teams end up with validated solutions and misaligned organizations.
Why Value dominates (and Clarity disappears)
Value work is the only category where the outputs are both visible and attributable. You shipped a feature. You moved a roadmap item from “planned” to “done.” There’s a Slack thread with a party emoji.
Now compare that to Clarity work done well: when alignment exists, nobody notices. The absence of confusion is invisible. It has no demo.
Organizational incentives reinforce this everywhere. Performance reviews reward shipped outcomes. Sprint demos showcase working software. Nothing in the standard PM operating rhythm rewards the fact that a team had a shared, accurate understanding of why they were building what they were building.
Clarity gets dismissed as something you should “just communicate better” about, rather than something you build, maintain, and deliver as a core part of the job. This isn’t a personal failing. It’s a systems problem.
Maintenance neglect at least leaves evidence: slowing velocity, rising incident rates, engineers raising flags. Clarity neglect leaves nothing. The cost is entirely invisible until the moment it isn’t.
The specific cost of neglected Clarity
Here’s what happens when Clarity work is missing: teams build the right thing for reasons they can’t articulate. That sounds fine until context shifts. A new competitor enters the market. Leadership changes strategic priorities. A key assumption turns out to be wrong. When any of these happen, the team has no foundation to adapt from. They knew what to build. They never internalized why. So they can’t course-correct without starting the conversation from scratch.
Meanwhile, stakeholders fill the void with their own interpretations. In the absence of documented reasoning, every VP, every sales lead, every partner team constructs their own version of “the plan.” When reality diverges from their version, they don’t update their model. They escalate. And the PM who never built the artifact that would have prevented it ends up defending a decision without evidence, in real time, to someone who has already written their own verdict.
There’s a moment almost every PM has experienced: someone asks “Why are we doing this?” at a sprint review, and the room gets uncomfortable. That isn’t a communication failure. It’s a Clarity failure. The information was missing because no one did the upstream work of creating shared understanding about direction and trade-offs.
Here’s the diagnostic: if you’re answering the same directional question more than twice, from different people, Clarity work is missing upstream. You haven’t built the artifact that makes the answer self-evident.
The audit
The audit takes about an hour. Most PMs never do it because they assume they already know the answer. They don’t. There’s no correct ratio across the four categories — what balance looks like depends on your context. What the audit surfaces is absence.
Take your last two sprints. List every task, meeting, and deliverable you personally worked on. Assign each one a category: Value, Clarity, Enablement, or Maintenance.
The hardest part is classification. Here’s the heuristic that matters most:
A backlog refinement session where you help the team estimate stories and clarify acceptance criteria is Enablement. That same session, if it produces a written decision log explaining why you chose to sequence Feature A before Feature B, with the reasoning documented for people outside the room, is Clarity work. The difference isn’t the meeting. It’s whether shared understanding leaves the room in a form others can access.
A useful related distinction: a blocker raised in standup is Enablement work, not Clarity work. Resolving the blocker keeps the team moving. It doesn’t build shared understanding. Knowing the difference between “this unblocks someone” and “this aligns people” changes what you choose to do with your next hour.
Any category at zero is a signal. It means an entire dimension of PM work has been absent from your practice for at least two weeks. That’s not a scheduling accident. That’s a pattern.
Clarity at zero needs specific diagnosis. Count how many times in the last two sprints you answered a question about direction, priority, or trade-offs verbally that could have been answered by a written artifact. Each of those moments is a symptom. The pattern they form tells you where your first Clarity artifact needs to go.
What rebalancing looks like in practice
Clarity work produces artifacts. If you treat it as a deliverable with concrete outputs (not a mindset, not a communication style), it becomes plannable, visible, and defensible.
I’ve written before about the cost of unwritten strategy, how teams mistake a shared feeling for shared understanding. This article isn’t about whether to write things down. It’s about recognizing Clarity as a category of work that competes for your time alongside Value, Enablement, and Maintenance. The question isn’t “should I document my reasoning?” It’s “how much of my last two sprints was spent ensuring shared understanding actually existed?”
Once you see Clarity as a work category, specific artifacts follow. One of the highest-leverage: a short document listing the three to five things you explicitly deprioritized this quarter, with one or two sentences of reasoning for each. Every roadmap communicates what you chose. Almost none communicate what you chose against, or why. That gap is where stakeholder misalignment breeds. When a VP asks “Why aren’t we building [thing]?” and there’s no documented answer, you aren’t having a strategic conversation. You’re having a trial.
A decision log serves a different but complementary function. For each significant call — a pivot, a sequencing choice, a scope trade-off — record what was decided, what alternatives were on the table, and why the chosen path won. This isn’t a meeting recap. It’s a reasoning record. When someone joins the team mid-quarter, or when a decision needs revisiting, the log gives them a foundation instead of a blank page.
Assumption registers address a third failure mode. Decisions don’t just rest on reasoning — they rest on beliefs: that users behave a certain way, that a market condition holds, that a dependency will be ready. Writing down the key assumptions at the time of the decision means that when one breaks, the team knows exactly which decisions are now on shaky ground. Without it, a changed assumption triggers a full strategy conversation from scratch. With it, the scope of the response is already defined.
The uncomfortable takeaway
The reason this imbalance persists isn’t that PMs don’t care about alignment or enablement or maintenance. It’s that the systems we operate in — the review cycles, the demo rituals, the way roadmaps get presented to leadership — are all designed to make Value work legible and everything else invisible.
If you do the audit and find that Clarity work is the gap (and for most PMs, it will be), start small. Pick one decision your team made this sprint that will get questioned later. Write down the reasoning. Document what you chose against. Make the “why” as concrete as the “what.”
Nobody will thank you for it right away. That’s exactly how you’ll know it’s Clarity work.
When the work is visible, it’s probably Value. When it disappears into how smoothly things run, that’s Clarity. Three sprints from now, when someone asks “Why are we doing this?” and the answer already exists in a document instead of in your head, that’s the deliverable.