MartinLabuschin.com

Does Your Calendar Know You’re a Product Manager?

2026-07-21T23:42:00+02:00

The product management job in the books isn’t the one many of us actually do. The books describe outcome ownership. Your calendar shows dependency syncs, status decks, and dates you never committed to. That gap has a name, most organizations won’t say it out loud, and reading it as personal failure is one of the most expensive mistakes you can make in this career.

Start with your calendar

Look at your last full week. Here’s mine. Every morning starts with a 25-minute daily with my product management group. The rest of the week is coordination: a cross-team sync with a partner organization, refinement to get tickets ready for development, a second cross-org meeting on the same afternoon, a three-org governance round, and whatever deployment coordination landed that week. On sprint-change weeks, Wednesday disappears entirely into review, retro, and planning.

I want to be precise about what this week wasn’t. It wasn’t fake work. The dependency was real and would have derailed the release. The sign-off was legally required. Somebody had to defend that date, and the person defending it should understand the plan. The work was necessary. What was broken was the label on it.

Two modes, one title

The product literature describes one job. Call it outcome mode. You own a problem. You hold real decision rights over the solution space. You measure yourself in changed user behavior and business results. Discovery isn’t a luxury in this mode; it’s the core activity, because deciding what to build is your actual mandate.

Many organizations run a different job under the same title. Call it delivery mode. You own a commitment. Your decision rights cover sequencing, at best. You measure yourself in dates held, dependencies resolved, and escalations avoided. The what was decided elsewhere: in a contract, in a regulatory deadline, in a steering meeting two levels up.

Delivery mode isn’t a broken version of outcome mode. It’s a legitimate operating mode that some organizations need for rational reasons. Fixed-scope contracts exist. Regulatory deadlines exist. If your product is a platform with twelve consuming teams, coordination isn’t overhead, it’s the job. I’m not writing this to tell you delivery work is beneath you. I’m writing it because the label matters, and most organizations lie about it.

Nobody decided to lie

That’s what makes the gap so durable. There’s no villain who sat down and wrote a false job description.

The ad says product manager because the market says product manager. The title attracts candidates who wouldn’t apply for “release coordinator”. It signals modern practice to customers, and in regulated industries it signals maturity to auditors. HR benchmarks the ad against other ads, which were benchmarked against conference talks, which describe outcome mode.

Leadership believes the strategy deck, and the deck describes outcome mode. Empowered teams. Outcome over output. The deck is sincere. But strategy decks describe the organization leadership wants to run. The calendar describes the one it actually runs. The calendar is the only honest document in the building.

So the gap emerges without anyone owning it. Hiring language written by one department. Expectations set by an industry. Daily demands set by an operating model nobody examined. You walk in expecting the job from the ad. You get the job from the calendar. And because everyone around you uses outcome vocabulary, you assume the gap is your fault.

What not knowing costs you

Three costs, and they compound.

You train for the wrong job. You optimize for the described role. Evenings spent on interview techniques, opportunity mapping, experiment design. Skills the organization won’t let you use, because the what is already fixed. Meanwhile, the skills your actual mode rewards stay accidental: dependency mapping, escalation design, commitment forensics. That last one means finding out who committed what, when, and based on what evidence. Nobody teaches these skills because nobody admits the mode exists. So the people in delivery mode learn it badly, by improvisation, while studying for a different exam.

You’re reviewed against the wrong job. Your objectives use outcome language, because the template came from the same place as the job ad. Drives product strategy. Increases customer value. Then the year happens, and the year is delivery. At review time you’re measured against a job you were structurally prevented from doing. The job you actually did, often well, stays invisible because the template has no words for it. You can fail the review by succeeding at your real job.

You blame the wrong cause. This is the expensive one. You read a structural condition as a personal flaw. “I never get to discovery” becomes “I’m not disciplined enough to protect time for discovery.” Every productivity system you try fails, because no time management technique changes your decision rights. I know PMs who carried this guilt for years. The guilt points at the wrong target. You can’t fix with better habits what the organization built into your role.

Three questions that settle it

Not a maturity model, not a quiz. Three questions with uncomfortable answers.

Who committed the dates you defend? If the answer isn’t “I did, based on evidence I trust”, you’re in delivery mode. Defending someone else’s commitment is coordination work, whatever your title says.
What happens if you kill a feature? Not deprioritize. Kill. If the honest answer involves someone above you putting it back on the roadmap, you don’t own the solution space. You administer it.
When did you last decide what gets built, not when? Name a decision from the last quarter that changed the content of the product, made by you, still standing. If you can’t, the mode has named itself.

Answer them honestly and you’ll know your mode before you finish reading. Most people I’ve asked already knew. They’d just never let themselves say it.

What to do with the answer

The standard advice is to push back, educate your leadership, or just do discovery anyway in the gaps. All three assume you hold authority that delivery mode, by definition, withholds. Advice that requires outcome-mode power to escape delivery mode isn’t advice. It’s decoration.

Three moves that work with the authority you actually have.

Do the mode deliberately. Delivery mode has a real skill ceiling, and most people operating in it never get close, because they treat the mode as temporary. Commitment forensics done well changes meetings. When you can state who committed a date, on which assumptions, and which of those assumptions have since died, you stop defending dates and start renegotiating them. That’s a senior craft. It’s rare, it’s visible, and it compounds.

Negotiate the label, not the work. The work may be exactly what the organization needs. Then say so, in writing, in your review criteria. Get “coordinates cross-team delivery” into your objectives and get “drives strategy” out, or keep it only for the territory where it’s true. The point isn’t to shrink your job. The point is to be measured against the job that exists.

Carve out one bounded outcome territory. Not the whole role, one problem. Small enough that nobody above you has committed anything about it, real enough to matter. Claim it explicitly: this problem, my decision rights, my evidence. Defend that border and let the rest of the role be honest delivery mode. One problem you truly own beats a whole roadmap you only pretend to.

The mode isn’t the verdict

The mode you’re operating in today is a fact about your organization. It reflects its contracts, its regulators, its history, its trust structure. It isn’t a fact about you.

Staying blind to it for another year is.

The Priority List Is a Protection Mechanism

2026-07-07T18:04:00+02:00

Most product teams think prioritization is about choosing what to do next. It isn’t exclusively that. It also means giving your team explicit permission to let say no and to let things die. And if you can’t point to the list when someone asks why something isn’t moving, you don’t have priorities. You have a wish list.

A priority list that doesn’t make people uncomfortable isn’t doing its job. If everything on it feels reasonable and nothing important is visibly excluded, you haven’t prioritized. You’ve just re-sorted your backlog and called it strategy.

Real prioritization creates a visible gap between what the organization wants and what the team will actually do. That gap is the point. It’s not a side effect of limited capacity. It’s the output.

When your team has a clear, written priority list, something powerful happens: anyone who walks over and asks “Why isn’t X moving?” gets a concrete answer. Not an excuse. Not a deflection. A traceable decision. “Because items 1-4 are above it, and here’s who agreed.”

That’s not bureaucracy. That’s expectation management with a paper trail.

What Happens When You Don’t Protect the List

Here’s the failure mode I see constantly. A team has nominal priorities, but treats them as soft guidance rather than hard constraints. When a senior stakeholder shows up and asks about a lower-priority system, the team scrambles to show progress. They pull work into the sprint that doesn’t belong there. They split their attention. They compromise the things that actually matter.

The result is predictable: nothing gets done well. The high-priority items slip. The low-priority items get just enough attention to create the illusion of progress without actually shipping. And the team burns out trying to serve two masters when the entire point of the list was to make them serve one.

A priority list that the team abandons under social pressure isn’t a priority list. It’s decoration.

The Chain You Need to Make Visible

In product organizations embedded inside larger enterprises, there’s a specific failure pattern that doesn’t get enough attention. Enterprise-level decisions (infrastructure migrations, rebranding efforts, compliance overhauls) silently consume product team capacity. Each one is individually justified. Collectively, they crowd out every minute of customer-facing product work.

Here’s what makes this dangerous: no single decision looks like the one that killed your product. The certificate authority migration is critical. The corporate identity refresh is mandated. The data center migration is non-negotiable. Each one is someone else’s priority that becomes your team’s work.

And when a customer eventually churns because nothing has improved in the product for two quarters, nobody connects that outcome to the “urgent” internal projects that consumed your capacity. The causal chain is invisible.

Your job as PM is to make it visible before the consequences arrive. Not after.

How to Build the Chain

This is where the priority list becomes more than a task-ranking tool. It becomes an accountability document.

For every sprint where internal, non-product work displaces customer-facing delivery, document three things:

What was displaced. Name the customer-facing work that didn’t happen. Not vaguely. Specifically. “Feature X for customer segment Y did not ship this sprint.”
What displaced it. Name the internal initiative. “Certificate migration for new CA infrastructure, requested by [team/stakeholder].”
What the cumulative cost is. Track how many consecutive sprints your team has operated below its customer-facing capacity. One sprint is a blip. Three is a pattern. Six is a strategic problem someone needs to own.

This isn’t about blame. It’s about making trade-offs legible. When someone eventually asks why the product hasn’t moved, you don’t want to be standing there with nothing but a vague sense of having been busy. You want a document that says: “Here are the enterprise decisions that consumed our capacity since November, here is the customer-facing work that didn’t happen as a result, and here is who approved each trade-off.”

A word of caution: this documentation only works as an accountability tool if you’re using it to surface trade-offs and drive decisions. If you’re building the chain instead of having the conversation, you’ve turned an accountability mechanism into a passive-aggressive archive. The document should make trade-off discussions happen earlier, not replace them.

The Permission Problem

Most teams know what their priorities are. What they lack is genuine organizational permission to act on them.

Permission means: when a lower-priority system sits untouched for months, nobody panics. Nobody sends a “concerned” message. Nobody pulls the team into an emergency review for something that was explicitly deprioritized.

If your priority list says system A is priority one and system B is priority four, and system B hasn’t been deployed to in months, that’s not a failure. That’s the list working. The anxiety you feel about it is the feeling of prioritization actually functioning.

The moment you flinch and start sneaking lower-priority work back into the sprint to reduce that discomfort, you’ve broken the mechanism.

When You Get It Wrong

No prioritization system is perfect. Sometimes you draw the line in the wrong place. A system you deprioritized turns out to need urgent attention for a reason you didn’t anticipate.

I’ve been in exactly this situation. I was confident the team had certain work under control. They didn’t, and I should have checked. The priority list was right. My oversight of execution within that priority was wrong.

Those are two different problems, and conflating them (“the priority list doesn’t work”) is a trap. The list worked. My attention allocation didn’t.

Admitting that openly, adjusting your involvement, and moving on is more valuable than any framework. The priority list doesn’t replace management judgment. It creates a structure within which that judgment operates.

The Worst Case Isn’t a Mystery

Here’s the thing about enterprise-imposed capacity drain: if it eventually drives a customer away, the cause isn’t mysterious. You can trace it. Your product team spent months on infrastructure migrations, restructurings, compliance work, and rebranding. All mandated. No customer-value. The product stagnated. The customer left. That’s not a product failure. That’s an organizational choice with a product consequence. And the only way leadership learns to weigh those choices differently is if someone makes the consequence chain explicit, in writing, before the damage is done.

If you make it visible and leadership still chooses to prioritize internal work over product progress, that’s a legitimate strategic decision. You may disagree with it. But at least it’s a decision, not an accident.

If you don’t make it visible, you’ll absorb the blame when the product suffers. You’ll be the PM who “couldn’t deliver” while the people who consumed your capacity move on to their next initiative.

Making It Work

If you take one thing from this: treat your priority list as a political protection mechanism, not just a planning tool.

Write it down. Get it approved. Reference it every time someone asks why something isn’t moving. A priority list nobody can point to is a priority list that doesn’t exist.
Track displacement. Every sprint where internal work pushes out customer-facing delivery, log it. Build the chain. Use it to start trade-off conversations, not to stockpile ammunition.
Resist the flinch. When lower-priority items sit untouched for months, don’t panic. Check that nothing critical was miscategorized, then hold the line.
Own your mistakes quickly. When something falls through the cracks within your top priority, say so. Fix the oversight. Don’t blame the framework.
Make the worst case traceable. If the product eventually suffers because of decisions outside your control, the documentation should already exist. Not as a “told you so,” but as an organizational learning tool.

A priority list that everyone ignores under pressure is just a backlog with a nicer name. A priority list that the team actually follows, even when it’s uncomfortable, even when important things visibly sit undone, is one of the few real protections a PM has.

Use it like one.

When Silence Becomes the Escalation Strategy

2026-06-23T08:40:00+02:00

The most dangerous organizational failures aren’t the ones that escalated and were mishandled. They’re the ones that never surfaced at all, because PMs learned, through repeated experience, that escalating certain categories of risk reliably damaged their standing more than absorbing the consequences quietly. When a PM stops escalating, they aren’t being resilient. They’re revealing that the organization has trained them that visibility is punishing. And that means leadership is flying blind by design.

Silence is trained behavior

No PM starts quiet. Early in your career, you escalate everything. You flag the dependency risk. You name the timeline slip before it’s visible in the metrics. You raise the concern about the integration nobody wants to own.

Then you learn.

Not from a single catastrophic moment, but from a pattern. The escalation that got reclassified as a complaint. The risk you surfaced that triggered a “solutioning” conversation redirected entirely back at you, with no additional resources and a new expectation to fix it yourself. The blocker you named clearly, with consequences and deadlines, that produced no action but somehow left a residue on your reputation. You became “the one who always has problems.”

The lesson doesn’t arrive as a policy. It arrives as accumulation. After enough repetitions, the PM internalizes a simple cost-benefit calculation: the personal cost of escalating exceeds the personal cost of absorbing the failure quietly. So they stop.

This isn’t cynicism. It’s rational adaptation to a broken incentive system, the same structural dynamic that drives knowledge hoarding or discovery theater. The organization never explicitly told the PM to be silent. It just made silence cheaper than transparency, one interaction at a time.

The four signals that train silence

Not all escalation failures look the same. There are distinct patterns that teach PMs to stop surfacing risk, and recognizing which ones are active in your organization is the first step toward fixing them.

The Reclassification. The PM escalates a structural blocker. Leadership reframes it as an attitude problem or a communication style issue. The risk itself is never addressed. The PM walks away having learned that the content of their escalation matters less than how it was received. Next time, they soften the message. The time after that, they skip it entirely.

The Boomerang. The PM names a problem clearly, expecting organizational support. Instead, the escalation returns as a new assignment: “Great that you spotted this. Can you own the solution?” No additional capacity, no adjusted scope, no escalation path beyond the PM themselves. The lesson is straightforward: raising a problem means inheriting it, so stop raising problems.

The Delayed Penalty. The escalation produces no visible consequence at the time. But weeks or months later, the PM notices they weren’t included in a key decision, or their scope shifted without explanation, or their performance review contains language about “focusing on solutions rather than problems.” The connection is never explicit. It doesn’t need to be. The signal is clear.

The Performative Acknowledgment. Leadership thanks the PM for the transparency. The risk gets logged. Then nothing happens. The risk materializes exactly as predicted. Nobody references the original escalation. The PM learns that the organization has a ritual for receiving bad news that is entirely disconnected from acting on it. Escalation becomes theater, and theater isn’t worth the effort.

Each of these patterns, individually, looks like a single bad interaction. In combination, they form a training curriculum. After twelve months of mixed signals, most PMs have a finely calibrated sense of which risks are “safe” to escalate and which ones will cost them standing. The dangerous risks, the ones that implicate leadership decisions, cross-functional ownership gaps, or resource allocation failures, almost always fall into the second category.

What trained silence costs the organization

The PM who stops escalating doesn’t disappear. They adapt. They absorb risks privately. They route around blockers through personal relationships rather than formal channels. They pad estimates to account for problems they can’t name publicly. They become very good at managing consequences rather than preventing them.

From the outside, this often looks like competence. The PM who never escalates appears calm, self-sufficient, low-maintenance. They may even be rewarded for it. But the organization is now paying three costs it can’t see.

Decision latency. Risks that could have been addressed with a small intervention when first identified now compound until they become visible on their own, at which point the intervention required is significantly larger. The PM knew about the problem in week two. Leadership discovers it in week ten. The cost difference between those two moments is the price of trained silence.

Repeated failures in the same category. When risks are escalated, even poorly, they enter organizational awareness. Patterns become visible. When risks are absorbed silently, each failure appears isolated. The organization never sees that the same dependency bottleneck, or the same integration gap, or the same resource constraint has caused problems in three consecutive quarters, because three different PMs each absorbed it independently.

Talent attrition among your most transparent people. The PMs who escalate early are, by definition, the ones who see problems clearly and care enough to name them. When the organization systematically punishes that behavior, those PMs either go silent (and the organization loses their signal) or leave (and the organization loses their capability). Either outcome selects for PMs who are comfortable operating without organizational support, which is another way of saying it selects for people who’ve given up on the system working.

The result is a leadership team that believes it has good visibility into organizational risk because nobody is raising alarms. The absence of escalation feels like the absence of problems. It’s actually the absence of trust.

Diagnosing trained silence

If you’re a PM, the diagnostic is uncomfortable but simple.

Think about the last three risks you identified that you chose not to escalate. For each one, ask: did I stay silent because the risk was genuinely manageable, or because I predicted that escalating would cost me more than absorbing it? If the answer is the second one more than once, you’ve been trained.

Now ask a harder question: what is the largest risk you are currently carrying that your leadership doesn’t know about? If one exists, and you can articulate exactly why you haven’t raised it, the silence is structural, not situational.

If you’re a leader, the diagnostic requires more effort because the system is working as designed to hide this from you.

Start with a simple count: how many escalations have you received from your PMs in the last quarter? If the number is low, resist the instinct to interpret that as health. Ask instead: is it low because the problems are genuinely small, or because my team has learned that escalating to me doesn’t produce results?

Then run a retrospective on any recent delivery failure. Trace backward. At what point did someone on the team first recognize the risk? How long was the gap between recognition and organizational visibility? If that gap is measured in weeks or months, something in your system is suppressing signal.

Structural recommendations

Trained silence can’t be fixed with an open-door policy or a town hall where you invite candor. Those gestures address the symptom without touching the incentive structure.

For PMs: Test your organization’s response to transparency with moderate-stakes escalations before you need it for high-stakes ones. Surface a real but non-critical risk using the full escalation structure: named consequence, decision deadline, trade-off options. Watch what happens. Does the system respond to the content, or to the act of escalating? The answer tells you whether your silence is protecting you from a fixable communication problem or from a structural one.

For leaders: Audit your last five escalation responses. For each one, trace what happened to the PM who raised it. Did the escalation produce organizational action, or did it produce a new assignment for the PM? Did the PM’s standing change afterward, even subtly? If you can’t answer these questions, you don’t have visibility into your own incentive system.

For organizations: Make escalation outcomes reviewable. Track not just what was escalated, but what happened next. Did the risk get addressed, absorbed, or ignored? Which PMs escalate frequently and which never do? A PM who never escalates in a complex environment isn’t low-risk. They’re either carrying risk invisibly or they’ve stopped looking for it. Both should concern you.

The uncomfortable truth is that most organizations would rather have PMs who absorb problems quietly than PMs who make those problems visible. Visibility creates work. Visibility implicates decisions. Visibility forces trade-offs that leadership would prefer to defer.

But a PM who has learned to be silent hasn’t become more capable. They’ve become a single point of failure for every risk they’re carrying alone. And the organization that trained them into silence has built a system where the most important information is the information it will never receive.

Documentation Is a Power Problem

2026-06-09T17:10:00+02:00

People don’t fail to document because they’re busy or undisciplined. They fail to document because institutional knowledge is leverage, and documentation surrenders it. This is the third time¹ I’ve written about incentive structures hiding behind individual behavior. The pattern keeps showing up because organizations keep misdiagnosing it.

The standard framing, and why it’s wrong

Most advice treats documentation as a hygiene problem. Build the habit, pick the right tool, schedule the time. This assumes people agree documentation is valuable and just need a nudge.

But the pattern is too consistent and too universal to be explained by laziness. Engineers, PMs, designers, leads, across industries, across decades, all under-document. That’s not a discipline failure. That’s an incentive structure working exactly as designed.

Sometimes it genuinely is a discipline problem. Someone is overwhelmed, context-switching constantly, and documentation falls off the list. That’s real. But it doesn’t explain why the most senior, most organized, most capable people in an organization are consistently the worst documenters. Discipline explains the junior engineer who forgets to update the README. It doesn’t explain the VP who has never once written down the rationale behind a major platform decision.

Knowledge as positional advantage

The person who holds undocumented context is the person you have to ask. That makes them essential.

The architect who never writes down system rationale. The PM who keeps stakeholder relationships and decision history in their head. The ops lead whose deployment process exists only as muscle memory. These aren’t oversights. They’re leverage preservation strategies, sometimes conscious, often not.

Writing it down means anyone can do what only you could do before.

“Ask Sarah” isn’t documentation. It’s a single point of failure with a Slack handle.

Why senior people document least

Not because they’re busiest. Because their organizational value is partly constructed from being irreplaceable.

The more senior the role, the more the knowledge is contextual, relational, and political. Exactly the kind that’s hardest to extract and most valuable to hoard. A junior engineer’s work is visible in code. A senior leader’s work lives in “I know why we made that call in Q3 and who was in the room.”

Why documentation initiatives die

Every organization has tried: wikis, Notion, Confluence, decision logs, ADRs. They launch with energy and decay within weeks.

The standard explanation is “no one maintains them.” The power explanation is simpler: the people with the most valuable knowledge to document have the most to lose from documenting it. The people with the least valuable knowledge are the ones maintaining the wiki. The incentive gradient runs exactly opposite to what the initiative requires.

Why the “bus factor” argument doesn’t work

Telling someone to document as if they leave tomorrow is asking them to preemptively reduce their own organizational value. No rational actor does this voluntarily unless the incentive structure explicitly rewards transferability. And it almost never does.

Performance reviews reward impact, ownership, being the go-to person. Not making yourself replaceable. The bus-factor framing treats documentation as insurance. But you’re asking people to pay the premium on a policy that only benefits others.

What knowledge-hoarding actually costs

The leverage strategy works until it calcifies into a trap.

The moment the hoarder loses negotiating power, the knowledge debt comes due all at once. Role transitions, reorganizations, layoffs, compliance audits. These aren’t hypothetical. They’re recurring organizational events, and in every one of them, the person who hoarded context is suddenly expected to transfer it under pressure, on a timeline they don’t control, with no process in place because they never built one.

The hoarder who looked indispensable in stable times looks like a liability in unstable ones. They can’t move to a new role without a months-long extraction process. They can’t take leave without Slack pings. They get promoted into positions where the old knowledge is irrelevant, but they’ve built no practice of making their new knowledge transferable either. The thing that looked like job security becomes a constraint on their own career mobility.

The irony is precise: hoarding knowledge to stay essential makes you essential to exactly one role, forever.

The organizational design implication

If documentation is a power problem, the fix isn’t better templates or documentation sprints. It’s making knowledge-hoarding visibly costly and knowledge-sharing structurally rewarded.

Start with the mechanisms that directly change incentive gradients:

Tie promotion criteria to team capability, not personal indispensability. This is where most organizations fail, because it requires rewriting what “impact” means. If your promotion rubric rewards “was the critical decision-maker on X,” you’re rewarding hoarding. If it rewards “built the team’s ability to make decisions like X without a single point of failure,” you’re rewarding transferability. The language shift is small. The behavioral shift is enormous.

Make “could someone else run this in your absence?” a standing question in performance reviews. Not as a checkbox. As a genuine evaluation criterion with consequences. The uncomfortable version of this conversation happens when X is a high performer whose manager doesn’t want to create friction. That’s exactly when the question matters most. If you only flag single-point-of-failure risk on low performers, you’re treating it as a performance issue, not a structural one.

Treat repeated “only X knows this” situations as a risk flag, not a compliment to X. This requires leadership to stop rewarding the hero dynamic that makes knowledge-hoarding attractive in the first place.

Fund documentation time the way you fund tech debt: as infrastructure, not charity. If it’s not in the capacity plan, it’s not real. Every organization that tells people to “find time to document” without allocating capacity is signaling that documentation is optional. People read signals, not memos.

None of these mechanisms work in isolation. The incentive structure has to change at multiple points simultaneously, or the rational actor simply optimizes around whichever lever you pulled.

The uncomfortable question

What do you know right now that no one else on your team could reconstruct from your artifacts?

That’s not your value. That’s your organization’s vulnerability, and your own trap.

They Aren’t Bad Leaders. They Are Misplaced. in February 2026; and The Sunshine Manager in March 2026 ↩

The Discovery Trap

2026-05-26T08:17:00+02:00

Has discovery ever killed a feature at your company? Not delayed one. Not reshaped one around the edges. Killed one. The answer tells you everything. Every product team I’ve worked with in the last five years runs continuous discovery. Weekly customer interviews, opportunity solution trees on the wall, synthesis sessions in the calendar. And in almost every case, the actual product decisions still get made by whoever holds the most organizational authority in the room.

Powerless Discovery

The standard critique of failed discovery blames execution. Teams aren’t interviewing the right customers. The opportunity tree isn’t structured well. Synthesis happens too late. These are real problems, but they’re not the important one.

The important one is this: discovery outputs have no formal authority in the decision-making process. They exist as inputs that anyone with sufficient seniority can override without naming the override.

A team runs six weeks of interviews, identifies a clear pattern, maps it to an opportunity, and proposes a solution. Then the roadmap conversation happens. A senior stakeholder says, “I hear the research, but I think we should prioritize X instead.” The research gets acknowledged. It doesn’t get followed. And no one records that a discovery output was overridden, by whom, or why.

The discovery was decorative rather than determinative. It created the feeling of rigor. It didn’t create the obligation to act.

Why This Happens

The instinct when discovery fails to influence decisions is to do more of it. More interviews. More data. More compelling presentations. This is the trap.

The problem isn’t evidence quantity. It’s that organizations build structural antibodies against inconvenient findings. A stakeholder whose performance is measured by features shipped has no incentive to let research slow that pipeline. A discovery practitioner without P&L accountability lacks the standing to force a trade-off conversation. The cost of ignoring user evidence is zero because the override is never named, never recorded, and never reviewed. By next sprint, no one remembers that the decision contradicted the research.

Compare how engineering teams handle technical debt. A good team doesn’t just identify debt. It records the trade-off, tracks the cost, and makes the decision to defer visible in every sprint review. Discovery needs the same structural accountability. The fix isn’t a louder signal. It’s a system that makes the ignoring visible.

What It Looks Like in Practice

Discovery theater doesn’t always look like neglect. It usually looks like diligence. These are the four patterns I see most often:

The confirmation interview. The team already knows what it’s building. Discovery gets scoped to validate the existing direction. Questions are framed to surface supporting evidence. Contradictory signals get categorized as edge cases. The interviews are real. The openness to changing course is not.

The pre-aligned discovery. Discovery runs in parallel with a commitment that’s already been made. A delivery date exists before the research concludes. If a feature has a ship date before discovery is complete, discovery is theater by design. The finding can’t change the outcome because the outcome is already locked.

The synthesis round-up. Interviews happen. Notes get taken. Then synthesis becomes a summary of what was heard rather than a recommendation that could alter the plan. Findings get shared as “themes” rather than as trade-off inputs. The work looks rigorous. It carries no weight.

The discovery sprint that’s actually a commitment sprint. The team calls it discovery, but the sprint’s structure assumes the answer is “yes” before the question gets asked. The week starts with a problem statement and ends with a prototype. “Should we build this?” is never on the agenda because the sprint format treats it as already decided. The output might be wireframes, a proof of concept, or a backlog. It doesn’t matter. The moment the sprint assumes building is the outcome, it stopped being discovery.

Most teams will recognize themselves in at least one of these. I’ve participated in all four.

Decision Protocols

The solution is not more discovery. It’s decision protocols that force the organization to interact with discovery outputs at the point of decision.

A decision protocol for discovery does four things:

1. It defines kill criteria before discovery starts.

Before running discovery on a problem space, document what “no” looks like. What findings would cause you to stop? If you can’t name them in advance, you’ve already committed to building. The kill criteria become the first entry in the decision record, and the override log tracks whether those criteria were met and ignored.

2. It requires discovery outputs to be present at the decision point.

Not “referenced in a slide three weeks ago.” Present. If a team has run discovery on a problem space, the synthesis belongs in the prioritization artifact next to the business case and the technical estimate. If there’s no discovery output for a decision, that absence should be visible, not quietly accepted.

3. It requires explicit override language when discovery is contradicted.

This is the critical piece. When a decision contradicts discovery findings, the protocol requires someone to name it: “We are choosing to override the discovery finding that [specific finding] because [specific reason].” This gets recorded in the decision log, not in someone’s memory.

The override isn’t forbidden. Sometimes business context, technical constraints, or strategic timing legitimately outweigh user evidence. The point isn’t to make discovery outputs unquestionable. It’s to make overriding them a named, accountable act rather than a quiet one.

4. It creates a review loop on override outcomes.

Overrides get tracked. Quarterly, the team reviews: which discovery findings did we override? What happened? Were the override reasons validated? This isn’t about blame. It’s about calibration.

What This Looks Like in Practice

At the simplest level, this is three fields. In whatever tool or template your team uses for prioritization decisions:

Kill criteria (defined before discovery): [what findings would stop this work]
Discovery evidence considered: [summary or link to synthesis, or “none available”]
Override noted: [yes/no, and if yes: what finding was overridden, by whom, and stated reason]

The mechanism is small. The cultural shift is not.

In a sprint review or roadmap discussion, the protocol sounds like this: “The discovery work pointed toward [finding]. We’re going a different direction because [reason]. [Name] is making that call, and we’re recording it so we can review the outcome.”

That sentence is the entire intervention. Right now, in most organizations, it never gets said.

The Diagnostic Value

If your team adopts override tracking and discovers that overrides are rare, or frequent but well-reasoned and validated by outcomes, your process is healthier than you thought.

The scenario that matters is the third one: overrides happen frequently, without clear justification, and the outcomes are consistently worse than what the discovery work recommended. That pattern tells you something no amount of better interview technique will surface. You don’t have a discovery problem. You have an authority problem.

The override log turns a vague sense that “leadership doesn’t listen to research” into a specific, reviewable record: these decisions, by these people, contradicting these findings, with these outcomes. That’s not a discovery insight. It’s an organizational diagnosis.

Why Teams Resist

Discovery practitioners will sometimes resist, and this is the more interesting resistance. The protocol reframes their work from a self-contained practice into an input with a measurable influence rate. Some teams prefer the autonomy of running discovery without the accountability of tracking whether it changed anything. That comfort is precisely the trap. Discovery that doesn’t connect to decisions is a hobby, not a practice.

Senior stakeholders will resist too, but for an obvious reason: the protocol makes their overrides visible. If those overrides were well-reasoned, visibility costs nothing. If they weren’t, visibility is exactly what the organization needs.

The Uncomfortable Implication

Process rigor without decision authority is theater. The interviews are real. The synthesis is real. The opportunity tree is real. And the decision was made before any of it was consulted.

The fix isn’t abandoning discovery. It’s building the bridge between evidence and decision: a protocol that makes the connection (or disconnection) between research and action visible, named, and reviewable.

Start with the three fields. Track the overrides. Review them quarterly. And be honest about the uncomfortable part: most of us have participated in discovery theater. We’ve run the interviews knowing the decision was already made. We’ve synthesized findings into formats designed to be acknowledged rather than acted on. The first override to name might be your own.

The Risk Register Is a Political Document

2026-05-12T08:04:00+02:00

Someone in a post-mortem always says it: “Why didn’t anyone flag this?” The risk register exists to make that sentence unsayable. Not because it tracks risks, every project does that informally, but because it forces the people in the room to say, on the record, what they plan to do about them. That’s not an organizational function. It’s a political one. And most PMs are using it wrong because they’ve never understood what it actually is.

The Register Is a Political Act

Let me be direct about what a risk register actually does. It makes it structurally impossible for stakeholders to claim they were surprised.

When a risk has a name, a score, a response strategy, and an owner, several things become very difficult: pretending you didn’t see it, avoiding a response, and claiming ignorance when it materializes. The register makes all of that impossible. Not because of the format, but because of what the format requires you to say out loud and write down.

This isn’t about bureaucratic compliance. It’s about stripping away plausible deniability. Stakeholders who disagree with an assessment have to argue against specific numbers and a documented rationale. Stakeholders who’d prefer to ignore a risk have to write “Acceptance” in the response column, which makes the choice explicit and visible to everyone. Stakeholders who later claim they weren’t informed have to contend with the fact that the document existed, they had access to it, and they chose not to act.

The PM who controls the risk register controls the narrative. Not in a manipulative sense, but in a structural one. The register defines what’s known, what’s been decided, and who decided it. That’s what makes it uncomfortable. That’s what makes it work.

The Risk Score: Killing Gut Feel

The first thing a risk register does is replace subjective dread with a number.

Risk score = probability × impact.

The number matters less than the process of producing it. When you sit down with a stakeholder and disagree about whether a dependency risk has high or medium probability, you’re no longer having a vague discussion about feelings. You’re negotiating about reality. That conversation doesn’t happen without something concrete to argue about. The register provides the anchor.

One important discipline: the register records impact not only as an abstract number but in relation to what actually matters for the project. Every impact needs to be assessed against the three constraints: time, cost, and scope. A risk that threatens delivery speed has a different weight in a time-critical launch than in a background infrastructure project. Document which constraint the risk threatens, not just how big the damage might be. This is where scoring becomes political, because it forces the room to agree on what the project actually optimizes for.

The Four Response Strategies (and the Politics Inside Each One)

Identifying and scoring risks is table stakes. The part that creates accountability is the response column. Every risk must be assigned one of four strategies. But the choice of strategy is never purely technical. It reveals who has power, who’s willing to make trade-offs, and who’d rather defer a hard conversation.

Avoidance. Eliminate the source of the risk entirely. Cut the feature that requires an unstable third-party integration. Descope the work package whose timeline depends on a team that hasn’t committed. This is the cleanest outcome, and the most politically uncomfortable, because it requires a sponsor to agree that not doing something is a legitimate project decision. Every avoidance choice needs its trade-off documented alongside it. Otherwise the scope cut looks like a PM failure instead of a risk response.

Minimization. You reduce either the probability or the damage. Build in a feature flag so a rollback takes minutes instead of days. Onboard a backup for a key engineer before they go on leave. Minimization doesn’t guarantee the risk goes away. It makes the outcome more manageable.

The political value of minimization is that it lets stakeholders feel like they’re acting on a risk without giving anything up. That makes it the most popular strategy, and the one most likely to hide what I’d call comfort theater. The team agrees to “monitor closely” or “add a buffer,” everyone nods, and the risk stays at the same probability and impact it had before the response was applied.

The diagnostic is straightforward: after a minimization strategy is documented, re-score the risk. If the net score hasn’t moved down from the gross score, the strategy isn’t actually minimizing anything. It’s a statement of intent dressed up as a countermeasure. When you find this pattern, name it in the register review. Ask the room: “What specifically changes about the probability or the impact as a result of this action?” If no one can answer with a concrete mechanism, you don’t have a minimization strategy. You have a wish. Relabel it as acceptance and let the owner decide if that’s still the choice they want to make with their name next to it.

Transfer. You shift the consequence to a third party. The probability doesn’t change, but the damage no longer lands on your team or your budget. In external relationships, this means contractual SLAs with vendors or penalty clauses in delivery agreements. But the harder version of transfer happens internally, when you’re negotiating risk ownership with a peer team inside the same organization. There’s no contract to fall back on. You’re sitting across from someone who has their own priorities and no structural obligation to absorb your risk. Transfer becomes a negotiation about organizational trust: who will own this dependency, what does “ownership” actually mean, and what happens when the other team’s priorities shift? Without the register, internal transfer is just a verbal agreement that evaporates the moment it’s inconvenient. With it, the commitment is documented, the owner is named, and the conversation later is fundamentally different.

Acceptance. This is the strategy that separates the politically sophisticated PM from everyone else, because it forces a stakeholder to put their name next to a risk they’d rather pretend doesn’t exist.

Acceptance means you document the risk, acknowledge that countermeasures would cost more than the potential damage (or are already in place), and decide to proceed. What makes it different from negligence is the word “documented.” Acceptance without documentation is just forgetting. Acceptance with documentation means the team made a deliberate decision, the stakeholders were informed, and the consequences were known in advance.

When a steering committee member writes “Accept” next to a risk they previously wanted to wave away in conversation, the dynamic in the room changes. That one word, in a shared document, does more for accountability than any status meeting ever will.

Gross and Net: The Two Views That Change the Conversation

A distinction most risk management content glosses over entirely: the gross view and the net view.

The gross list contains every identified risk, before any response has been applied. It’s the complete picture of what could go wrong. The net list contains only what remains after avoidance, minimization, and transfer strategies have been applied: the residual risk exposure the project is actually carrying. Accepted risks appear in the net list explicitly, because they haven’t been removed, only acknowledged.

When a sponsor or steering committee asks about project risk, you show them the net view. When you’re doing internal planning or onboarding a new team member, you work from the gross view. Both need to exist. Both need to stay current.

But the net view is the politically important one. Consider the difference. A risk materializes. If it appears on the net list with a documented acceptance decision, the conversation starts at “We knew this was possible and we chose to proceed. Here’s our response.” If it was never on the net list, or was quietly removed without explanation, the conversation starts at “Who dropped this?” One meeting is about execution. The other is about blame.

The net view also reveals the true shape of your project’s risk posture. If your net list is heavy with accepted risks, that’s a signal. It either means the team is making deliberate, informed choices about what it can absorb, or it means avoidance and minimization strategies are being under-applied because they’d require trade-offs nobody wants to make. Both are worth surfacing.

For steering committees, the net view is the single most efficient communication tool you have. It answers three questions in one document: what risks remain, what we decided to do about each one, and who owns the decision. If your stakeholder communication around risk is taking more than five minutes in a steering meeting, you probably aren’t using the net view effectively.

Why Regular Reviews Are a Political Act, Not a Housekeeping Task

Most teams abandon the risk register after kickoff. The cadence collapses, the document freezes, and the risks that were documented in week one quietly stop reflecting reality. The political function of a regular review is precisely to prevent that: it makes the quiet disappearance of inconvenient risks structurally difficult. Without a cadence, acceptance decisions stop getting re-examined as new information arrives. The dependency you accepted starts slipping. The vendor you transferred risk to misses a milestone. These shifts don’t announce themselves. You find them by looking.

I built risk register reviews into my sprint rhythm alongside the decision log. Not every sprint produced a new entry. But the act of looking at it consistently forced one question: is this still accurate? And asking that question in a room with stakeholders, on a predictable schedule, changes behavior. When people know the register will be reviewed, risks don’t quietly disappear. Comfort theater gets flagged. Acceptance decisions get re-examined.

The register stays alive not because someone owns a maintenance task, but because the review creates a recurring moment of political accountability. That’s the difference between a living commitment and a kickoff artifact.

Visibility Is the Entire Point

The register doesn’t exist to catch people out. Used well, it creates shared understanding before anything goes wrong and shared accountability when something does. But alignment only works when everyone has to state their position clearly, in writing, where it can be referenced later.

That’s the real output of a risk register. Not a spreadsheet. Not a compliance artifact. A record that makes informed ignorance impossible. In any organization where decisions are made by committee and accountability is distributed, that record is the most politically valuable document a PM owns. Use it like one.

You’re Not Too Busy. You’re Unbalanced.

2026-04-28T08:21:00+02:00

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.

The Invisible Lane That Eats Your Quarter

2026-04-14T08:06:00+02:00

I often walk into a planning session knowing that a significant portion of my team’s capacity is already spoken for. Not by features. Not by tech debt. By compliance. And when I present a roadmap that reflects this reality, colleagues look at it and ask: “Why is Q2 so thin?” It isn’t thin. It’s honest. But most roadmaps in regulated industries aren’t.

The Third Stream

Most product managers carry two dimensions on their roadmap: features and technical foundations. That model works for an unregulated SaaS team. In product management for an eIDAS qualified trust service provider, it’s a planning fiction. Regulation doesn’t sit inside either category. It has its own resource demands, its own deadlines, and its own consequences for failure. Treating it as a first-class planning dimension changes how you resource, communicate, and defend your roadmap. Treating it as anything less is how you build a plan that won’t survive contact with Q2.

If you’ve read my earlier pieces on making invisible work visible, whether that’s tech debt or blockers, this is the same thesis applied to a higher-stakes domain. The pattern is consistent: what you don’t name on the roadmap controls the roadmap anyway. In regulated environments, the cost of that silence isn’t just a missed metric. It’s a certification issue. Certification issues end products.

Why Compliance Doesn’t Fit Inside the Other Two

The instinct most teams have is to absorb compliance work into existing categories. Audit preparation becomes an engineering task. Certification requirements get folded into infrastructure sprints. Regulatory documentation gets assigned to whoever has bandwidth.

This is how compliance becomes invisible. And invisible compliance still consumes resources, still blocks engineers, still delays releases, without anyone outside the team understanding why. It competes with technical priorities and loses. It competes with feature priorities and loses harder. In a qualified trust service, the result of losing those fights isn’t a delayed dashboard. It’s a finding in your next conformity assessment.

The Audit Reality

It’s not only the extensive yearly audits. What most people outside regulated product teams don’t see is everything between them. Every new feature has a compliance surface: a document trail, a control to validate, an evidence requirement tied to your certification scope. Every architecture decision carries regulatory implications that your auditor will ask about twelve months later. Every release has documentation requirements that aren’t optional and don’t wait for a convenient sprint.

Compliance isn’t an annual disruption. It’s a permanent operating condition. The PMs who treat it like a calendar event spend the other eleven months explaining delays they can’t name.

What Happens When You Hide It

There’s a predictable failure pattern in regulated environments. A team builds a roadmap that looks like one from an unregulated company. Leadership approves it. Commitments get made externally. Then midway through the quarter, engineers get pulled into documentation reviews, security assessments, and evidence collection.

The PM absorbs this silently. Adjusting scope. Renegotiating timelines. Apologizing for delays they didn’t cause and can’t fully explain without sounding like they’re making excuses.

Over time, it’s not just the quarter that erodes. It’s the PM’s standing. Each unexplained slip makes the next commitment harder to defend. Stakeholders stop asking what happened and start assuming the answer. The next planning cycle opens with pressure to catch up, which compresses compliance further, which produces the same slippage, which produces the same apology. It’s not a delivery problem. It’s a roadmap honesty problem.

Visibility as a Political Act

Putting compliance on the roadmap isn’t just organizational hygiene. It’s a political act.

You’re telling leadership something they often don’t want to hear: this team cannot move as fast as an unregulated team, and pretending otherwise produces worse outcomes, not better ones. That’s uncomfortable to say out loud. But the roadmap is exactly where that discomfort belongs. Not in a side document. Not in a footnote. Not in a mid-quarter apology. The artifact leadership uses to ask “what are we delivering” needs to show compliance as a named, resourced, time-bound stream of work. Anything else is a negotiation you’ll lose after the commitments are already made.

When compliance is visible on the roadmap, two things change:

Expectations become realistic. Leadership sees that available feature capacity is a portion of total capacity, not all of it. The gap between what they want and what’s possible stops being a surprise and starts being a planning input.

Trade-off conversations happen before commitments, not after. If leadership wants to accelerate a feature, they can see what it would displace. You negotiate scope in planning, where the PM has leverage, not mid-sprint, where they don’t.

What Three Streams Actually Look Like

In practice, my roadmap has three explicit streams, each with a named capacity allocation, agreed before the quarter starts. Not assembled from whatever features and tech debt left over.

Features: User-facing capabilities, integrations, experience improvements. What gets demoed, marketed, and sold.

Technical foundations: Infrastructure, performance, scalability, security hardening, debt reduction. What keeps the product viable over time.

Compliance: Audit preparation, regulatory documentation, certification maintenance, policy implementation, evidence collection, control validation. What keeps us allowed to operate.

The split isn’t fixed. A quarter anchored to certification renewal might allocate 35 to 40 percent of engineering capacity to compliance work alone. A steady-state quarter with no major audit milestones might run closer to 15 percent. But compliance never drops to zero, and it never competes silently with the other two streams. The negotiation happens in planning, not mid-sprint.

The Conversation You Need to Have

This is where most PMs stop: they agree with the framework but never say the words out loud. So here’s what the conversation actually sounds like.

Before the quarter starts, you sit down with your engineering lead, align on a capacity split across the three streams, and bring those numbers to leadership. You say something like: “Next quarter, roughly 30 percent of our engineering capacity goes to compliance. Here’s what’s driving it: [certification renewal, control validation for the new feature scope, evidence collection for the upcoming audit]. That leaves this much capacity for features. Here’s what fits. Here’s what doesn’t. If you want to change the feature list, we can talk about what moves, but the compliance allocation isn’t optional.”

The key is specificity. Not “compliance takes time,” but “compliance takes 30 percent next quarter because of these three obligations.” Not “we might slip,” but “here’s the capacity, here’s the plan, here’s what happens if we compress it.” You’re not asking permission. You’re presenting the operating reality and offering trade-offs within it.

The cost of not having this conversation is specific. Mid-quarter scope cuts. Timelines renegotiated without a credible explanation. Credibility that erodes sprint by sprint. Regulated PMs who absorb compliance silently don’t protect their teams. They absorb consequences that were never theirs to own.

Constraints that are named and planned for are just parameters. Constraints that are hidden and absorbed are the ones that break teams.

The Honest Roadmap

Being honest about where capacity goes is the most senior thing a regulated PM can do. It doesn’t feel strategic. It feels like admitting a limitation. But there’s only one version of that limitation that’s dangerous: the hidden one. A slow-moving crisis with your name on it.

If your roadmap only has two streams, you’re lying to someone. Maybe to leadership. Maybe to yourself. Name the third stream, resource it, defend it. Anything less is a description of a product organization that doesn’t exist.

Define Your Failure Signal Before You Ship

2026-03-31T08:52:00+02:00

In December 2022, my team at Trusted Shops killed the biggest feature of the year. Not because it stopped working. Because it worked too well on the wrong axis. We had pushed review questionnaire conversion up by a huge percentage. Internally, the win of the year. Three months later, we rolled it back. We learned that the volume of negative reviews mattered more to our customers than the volume of reviews overall.

The metric that promised everything

The feature was called Autosave. Simple concept: when a consumer clicked the star rating in an invitation email, we saved the review immediately, even if they never completed the full questionnaire. From a pure conversion standpoint, this was a dream. A huge improvement, overnight.

We tracked completion, volume, funnel conversion. Everything moved in the right direction. What we never instrumented was the composition of what we were collecting. Whether these were reviews our customers, the businesses paying us, would actually want published.

We optimized the funnel. We ignored what was flowing through it.

What customers actually pay for

The blind spot was structural, and it should have been obvious.

Our customers are businesses that use reviews to build trust. They don’t pay for review volume as an abstract number. They pay for reviews that reflect genuine consumer experiences, reviews that help them earn trust with future buyers. Volume is a means. Trust is the product.

Autosave broke that contract. When a consumer tapped a star rating in an email, sometimes accidentally, sometimes mid-scroll, we saved it. Many of those half-formed ratings were negative. Not because the consumer had a bad experience, but because a single star tap with no context defaults toward low ratings. The consumer didn’t mean to leave a review. We recorded one anyway.

We had optimized our conversion metric while actively degrading the thing our customers were paying for. That’s the sentence I should have been able to write in January 2023. I couldn’t, because we weren’t measuring it.

Between January and March 2023, the negative review ratio shifted measurably. Customer satisfaction scores appeared to drop, not because service had declined, but because our measurement method was distorting reality. We found out through complaints, not dashboards.

The rollback and what it actually cost

In March 2023, my team paused Autosave. “Paused” is the word we used internally. The reality was closer to a kill.

The engineering cost was the easy part to absorb. A few sprints of work, reversible. The harder costs were the ones that don’t show up in Jira.

Trust with customers. The businesses that had seen their review profiles shift had to be addressed individually. Some had already started asking whether our platform was reliable. When your product sits in the digital trust space, that question is existential. You can’t answer “we shipped a feature that inflated your negative reviews by accident” and expect the conversation to end well.

Internal credibility. We had presented Autosave as a success in leadership reviews. The conversion number had made it into planning discussions. Rolling it back meant explaining to the same stakeholders why a metric we had built roadmap commitments around had been wrong from the start. The feature was gone. The commitments it justified were not. Every subsequent pitch carried a little more weight to prove.

Team morale. The engineers and designers who built Autosave did good work. The implementation was clean. The problem wasn’t execution. It was goal definition. Telling a team “the feature worked exactly as designed, but the design was wrong” is a different kind of difficult than telling them “there was a bug.” Bugs are fixable. Goal definition errors force you to question the decision-making process itself.

The second attempt, and why it’s different

We didn’t abandon the idea. The hypothesis behind Autosave was still sound: reducing friction in the review process should increase completed reviews. The problem was that we had removed too much friction, including the friction that separated intentional reviews from accidental ones.

In 2024, we started testing what we called “Confirmed Autosave.” The difference is one interaction step: the review is only saved when the consumer actively clicks “Next” after selecting their star rating. Not on the star tap alone. That single additional confirmation separates signal from noise.

But the bigger change isn’t the feature design. It’s the test infrastructure around it.

Before the relaunch, we built a dashboard tracking the ratio of negative reviews relative to total volume, updated daily, broken down by test cohort versus control. We defined abort criteria before the test went live: if the negative ratio moves beyond a specific threshold within the test window, we stop. No debate, no “let’s see if it stabilizes.” The stop condition was agreed on before a single user saw the feature.

We set a 7-day test limit for the initial cohort. Seven days because our historical data showed that review distribution patterns stabilize within the first five to six days of any feature change. A 7-day window gave us enough signal to evaluate the ratio shift without exposing a large user base to a potentially broken mechanic. Predefined metrics, a clear exit rule, written down before launch day.

The difference between December 2022 and the 2024 relaunch isn’t a smarter feature. It’s that we defined what failure looks like before we shipped, not after complaints told us.

The actual lesson

Conversion rate is a proxy metric. Every PM knows this intellectually. Very few PMs instrument their launches as if they believe it.

When conversion goes up, the narrative is immediate: the feature works. When the downstream effects surface weeks later (complaints, ratio shifts, trust erosion) the narrative has already hardened. You’re no longer evaluating a hypothesis. You’re defending a success story. And organizations are much better at defending success stories than they are at killing them.

The thing I got wrong in December 2022 wasn’t shipping Autosave. It was defining success as a single metric without a corresponding failure signal. We had a target for conversion. We had no target for “review quality didn’t degrade.” We measured the accelerator but not the guardrail.

Every primary metric needs a paired counter-metric that tells you when you’re winning the number but losing the customer. Conversion rate paired with complaint rate. Activation rate paired with churn within 30 days. Volume paired with composition.

If you’re about to ship something and you can only articulate why it will succeed, you haven’t finished the instrumentation work. The failure signal is the part most teams skip. It’s also the part that would have saved us three months of damage.

The conversion rate can go up while the product value goes down. If your instrumentation can’t detect that, you aren’t measuring success. You’re measuring activity. And you’ll celebrate all the way to the rollback.

We shipped the most successful feature of 2022. Then we had to kill it. Then we tried again, with better questions. That’s the part most lessons-learned posts leave out: the second attempt is where the learning actually lives. In our case, it lives in a pre-launch checklist that now has one non-negotiable line item: “What signal would tell us this feature is hurting the customer, and are we measuring it before day one?”

You Don’t Have a Strategy. You Have a Vibe.

2026-03-17T12:00:00+01:00

Most product teams I’ve worked with believe they have a strategy. They can talk about it in meetings, reference it in planning sessions, and nod along when leadership mentions it. But when I ask a simple question, “Can you show it to me?”, the room gets quiet. That silence tells me more about the state of a product organization than any roadmap ever could.

The Strategy That Doesn’t Exist

Here’s something I’ve learned after years of building products in the SaaS industry: if your strategy isn’t written down, you don’t have a strategy. You have a vibe.

That sounds harsh, but it’s precise. An unwritten strategy is a shared hallucination. Everyone thinks they’re aligned until the first real trade-off arrives. Then you discover that the CEO’s version of the strategy, the VP of Product’s version, and the engineering lead’s version are three different stories that happen to share a few keywords.

I’ve seen this pattern repeat across organizations of every size. The symptoms are always the same. Prioritization debates that never resolve. Stakeholders who keep reopening decisions that were supposedly settled. Teams building features that are technically competent but strategically incoherent. The root cause isn’t bad judgment or poor communication skills. It’s that there’s nothing to point to. No written artifact that says: this is what we’re doing, this is why, and this is what we’re choosing not to do.

Why PMs Avoid Writing It Down

The obvious explanation is that people are busy. Strategy documentation feels like overhead, one more artifact to maintain in a world already drowning in Confluence pages nobody reads.

But that’s not the real reason.

The real reason is that writing forces clarity, and clarity is uncomfortable. When you write a strategy down, you have to commit. You have to say what you actually believe about your market, your customer, and your competitive position. You have to name the bets you’re making and, more painfully, the bets you’re not making. You have to be specific enough that someone could disagree with you.

Most product organizations aren’t allergic to documentation. They’re allergic to commitment.

An unwritten strategy gives you room to shift, reinterpret, and claim alignment after the fact. A written strategy holds you accountable. That’s exactly why it’s valuable, and exactly why it meets resistance. I’d go further: the degree of resistance you feel when trying to write your strategy down is a reliable signal of how much unresolved disagreement your organization is carrying. If it’s easy to write, your team is more aligned than most. If it feels impossible, you’ve just learned something important.

What Written Strategy Actually Does

A written strategy isn’t a plan. It’s not a roadmap, a vision statement, or a list of OKRs. It’s a clear articulation of the choices you’ve made and the logic behind them. When it’s done well, it does three things that no verbal agreement can replicate.

It creates a shared reference point. When a new opportunity lands on the table, a written strategy gives the team something to evaluate it against. Not “what does the CEO think?” or “what did we say in that meeting last month?” but “does this fit the strategy we committed to?” That shifts conversations from opinion to analysis.

It surfaces disagreement early. When strategy lives in people’s heads, disagreements stay hidden until they become expensive. Someone reads the written strategy and says, “Wait, I thought we were going after enterprise customers, not mid-market.” That moment of friction is a gift. It’s far cheaper to resolve a strategic disagreement in a document review than in a failed product launch.

It makes delegation real. This is the benefit most product leaders underestimate. A senior PM or product leader can’t be in every room where decisions get made. A written strategy acts as a proxy for your judgment. It lets teams make good decisions without waiting for permission, because they can see the boundaries and the intent behind them. Without that written artifact, delegation breaks down in a predictable way: teams either wait for approval on everything (which kills speed) or they make their best guess (which produces strategically incoherent work). The teams I’ve seen operate with the most autonomy and the most coherence are always the ones that have a written strategy they can reference in real time. That document doesn’t replace judgment. It gives judgment a frame. A telling test of the strategy came when I took sick leave. The team made sound decisions without consulting me — unblocked, because they had the context they needed. The strategy gave them a foundation to act on.

The “Show Me” Test

Here’s a simple diagnostic: Go ask three people on a product team, separately, to describe the product strategy. Not the vision, not the mission, not the goals for this quarter. The strategy. The choices, the trade-offs, the “why this and not that.”

If all three give you roughly the same answer, and they can point me to a document that captures it, the team has a strategy. If they give you three different answers, or if they all say something vague like “we’re focused on growth” or “we’re building the best platform,” the team doesn’t have a strategy. They have a direction at best, and an assumption at worst.

What makes this test revealing isn’t the question. It’s what happens in the silence before people answer. That pause, where someone searches for language they’ve never actually had to produce, tells you whether strategy is an operating tool or a comfortable fiction in your organization. I’ve never run this test and been wrong about the result.

I encourage you to try it this week. Don’t warn people in advance. The uncoached version is the honest one.

What Good Looks Like

A written strategy doesn’t need to be long. Some of the best ones I’ve seen are two to three pages. What it needs is specificity. Here’s a structure I’ve pressure-tested across multiple product organizations:

Context. What’s true about your market, your customers, and your position right now? Not aspirations. Facts. If your context section reads like a pitch deck, you’ve already gone wrong.
Diagnosis. What’s the core challenge or opportunity you’re choosing to address? This is where most strategies fall apart. They skip the diagnosis and jump straight to solutions. A team that can’t clearly name the problem it’s solving will build confidently in the wrong direction.
Guiding approach. What’s your overall method for addressing that challenge? This is the heart of strategy: the set of choices that guide everything else. It should be specific enough to rule things out. If your guiding approach is compatible with every possible initiative, it isn’t guiding anything.
Coherent actions. What specific moves follow from that approach? These should reinforce each other, not just be a list of unrelated initiatives.

You’ll notice this structure forces you to do something most strategy documents avoid: make a diagnosis before you prescribe solutions. In my experience, the diagnosis is the hardest part to write and the most valuable. It’s where you have to say, out loud, “this is the real problem.” Not the polite version. Not the version that makes every stakeholder comfortable. The real one.

Don’t confuse this with vision docs, roadmaps, or goal frameworks. Those are outputs that a strategy should inform. They’re not the strategy itself.

The Hidden Tax

Every unwritten strategy carries a cost that doesn’t show up on any dashboard. It shows up in the time spent re-litigating priorities. In the features that get built because someone assumed they were strategic. In the talented PMs who leave because they can’t figure out what the organization actually cares about.

That last one deserves emphasis. The best product people I’ve worked with can tolerate ambiguity, but they can’t tolerate the absence of intent. When a strong PM starts asking “what are we actually trying to do here?” and gets a different answer from every leader they talk to, they don’t file a complaint. They update their LinkedIn. The cost of an unwritten strategy isn’t just inefficiency. It’s the quiet departure of the people you can least afford to lose.

You can’t measure this tax directly, which is part of why it persists. But if you’ve worked in product long enough, you’ve felt it. That nagging sense that the team is busy but not making progress. That the roadmap is full but the strategy is empty.

Start Here

If you don’t have a written strategy today, don’t try to produce a perfect document by Friday. Start with one page. Answer three questions: What are we choosing to focus on? What are we choosing not to do? Why?

Share it with your team. See if they agree. See where they push back. That pushback isn’t a problem. It’s the whole point.

A strategy that lives only in your head feels safe because nobody can challenge it. A strategy that lives on paper feels risky because everyone can. That’s not a weakness. That’s the mechanism that makes it real.