Every Product Manager, if you ask them directly, will tell you the same thing. It is about building something great. Something users genuinely need, that solves a real problem, that creates value in the world and in the business. That is why most of us got into the role in the first place.

And yet.

Look at how most PMs actually spend their time. Meetings that could have been messages. Approval chains for decisions that should never have required approval. Prioritisation frameworks applied to problems that needed a judgment call. Alignment sessions that produce slide decks rather than decisions. Roadmap ceremonies that consume the quarter they were supposed to plan.

None of that is product management. It looks like product management. It uses the vocabulary of product management. But it is something else: a sophisticated and socially acceptable way of avoiding the thing that makes product management genuinely hard, which is being accountable for outcomes you cannot fully control.

Agile will not fix this. AI will not fix it either. Waterfall certainly will not. The frameworks are not the problem, and they are not the solution. The problem is the behaviour that the frameworks are being used to enable, which is the substitution of process for judgment and the substitution of alignment for ownership.

Today I want to examine what it actually looks like to do the job properly, across eight principles that have nothing to do with which framework you use and everything to do with whether you are willing to lead.

Let us dive in.

Before we get into the specifics, it is worth naming the dynamic that produces the behaviour described above, because understanding it is the first step to changing it.

Process is safe. If a decision was preceded by a discovery phase, a framework application, a stakeholder workshop, and a sign-off chain, and it still does not work out, the PM has a defensible account of how they arrived at it. Nobody can say the process was not followed. The decision was, in some formal sense, correct.

Ownership is not safe. When a PM makes a call based on their own judgment, moves quickly without waiting for full alignment, and ships something that does not perform as expected, there is nowhere to hide. The decision was theirs. The outcome is theirs.

The entire apparatus of meetings, frameworks, approval chains, and alignment sessions that consumes so much PM time is, in significant part, a collective mechanism for distributing accountability so thinly that nobody is clearly responsible for anything. It feels like rigour. It is often the opposite.

The PMs who build the best products are almost always the ones who are willing to be clearly responsible. Not recklessly, not without doing the thinking, but without hiding behind process when the thinking is done and a decision needs to be made.

The instinct to say yes to everything is understandable. Every stakeholder request represents a real need. Every backlog item was added for a reason. The PM who pushes back on scope feels, in the moment, like they are being difficult rather than strategic.

But a PM who is nominally responsible for twelve priorities is not actually responsible for any of them. Attention divided twelve ways is not attention. It is the appearance of coverage with none of the depth that meaningful product work requires.

The discipline of fighting for fewer, better-chosen priorities is one of the most important and least practised in the PM toolkit. It requires the ability to say, clearly and with reasons, that this initiative matters more than that one, and to hold that position under the pressure that will inevitably come from the stakeholders whose priorities were not selected.

What it produces is a PM who is genuinely accountable for something specific, who can track the progress of that thing closely enough to intervene when it is not working, and who can point to concrete outcomes that resulted from their choices. That is a very different professional profile from the PM who is across everything and driving nothing.

Fight for two priorities that truly move the needle. Build them properly. Then do the same again.

The quarterly roadmap is one of the most durable rituals in product management, and one of the most frequently misused.

A roadmap that commits the team to three months of work based on assumptions that have not yet been tested is not a plan. It is a forecast dressed up as a plan, and it has the brittleness of all forecasts: it is accurate until reality diverges from it, which it invariably does, usually sooner than the plan anticipated.

The alternative is not the absence of planning. It is planning at a shorter cadence with faster feedback loops. A team that ships something meaningful every week, observes how it lands, and adjusts accordingly, accumulates learning at a rate that a team planning three months in advance cannot match. The weekly momentum is not just more efficient; it is more energising. There is something qualitatively different about a team that ships regularly and sees the results of their work in the world, versus one that plans for months and then delivers in a single release.

The smaller bets also inform the wider strategic choices. When you have run ten experiments in a quarter, you have a much clearer empirical basis for deciding where to focus the next quarter than you would have had from planning alone. The experimentation is not a substitute for strategy. It is the most reliable way of building one.

A PM's calendar is a record of their real priorities, not the ones they state in planning documents. If the calendar is dominated by syncs, status updates, and stakeholder check-ins, then syncing, updating, and checking in are what the PM is actually prioritising, whatever the roadmap says.

This is worth examining with genuine honesty, because the calendar rarely gets that treatment. Meetings accrue. Standing syncs that served a purpose at one point persist long after that purpose has been served. Invitations get accepted because declining them feels impolite or signals disengagement.

The practical discipline here is to audit the calendar regularly and ask, for each recurring commitment, what would actually happen if this meeting did not exist. Would the work stop? Would important information fail to flow? Or would people find a more efficient way to communicate what needs to be communicated, because the meeting was not serving the function it appeared to serve?

A concise written update replaces most status meetings. A well-structured Slack message replaces most quick syncs. The meetings that remain after honest scrutiny are the ones that genuinely require real-time conversation: the complex discussions, the high-stakes alignment moments, the sessions where the thing being worked out cannot be worked out asynchronously.

Protecting time for actual product work is not a luxury. It is a prerequisite for doing the job.

There is no state of complete clarity in product development. There is only a current state of understanding, and a decision that needs to be made against it.

The PM who waits for full alignment and complete information before moving will wait indefinitely, because full alignment and complete information are not available. They are conditions that feel achievable from a distance and recede as you approach them. The stakeholder who was aligned last week has a new concern this week. The data that seemed conclusive last month is complicated by a new dataset this month.

Eighty percent clarity is, in most product situations, enough to move. The remaining twenty percent will resolve itself through action faster than it will resolve itself through additional deliberation. Course correction in a moving product is almost always cheaper than the cost of the delay that perfect certainty requires.

This is, incidentally, one of the genuine insights that Agile frameworks contain. The value of iteration is not just that it produces better outputs over time. It is that it produces clarity about what the right outputs are, clarity that planning alone cannot generate. The commitment to moving, and learning from what happens when you move, is what makes the method work. A team that interprets Agile as a framework for planning more carefully in two-week increments has missed the point.

The backlog is not a to-do list. It is a statement of what the team believes is worth building, ordered by the value that building it will create.

When everything that is suggested makes it into the backlog, the backlog stops being a statement of priorities and becomes an archive of requests. And when every request generates a ticket, and every ticket generates a conversation, and every conversation requires a PM's attention, the PM's energy is distributed across everything and concentrated on nothing.

The discipline of protecting the backlog from low-value additions is unglamorous and politically uncomfortable. The stakeholder whose idea does not make it into the backlog feels that their input was not valued. The PM who says no repeatedly earns a reputation for being difficult that requires ongoing management.

But the backlog that is not protected becomes the product that is not coherent. Features accumulate without a unifying logic. Technical debt grows because the team is always building new things rather than building existing things well. The product experience fragments because each addition was optimised for the stakeholder who requested it rather than for the user who has to live with the accumulated result.

Not every idea deserves a ticket. Not every request deserves your attention. Protecting your energy and your backlog is not selfishness. It is the primary act of product stewardship.

This one is direct, because the indirect version tends to get rationalised away.

You were hired to make product decisions. Not to surface product decisions for approval. Not to build consensus around product decisions before making them. Not to check whether leadership is comfortable with product decisions before they are implemented. To make them.

The culture that requires a CEO or equivalent to sign off on every meaningful product move is a culture that does not actually have a Product Manager. It has a product administrator who executes decisions made elsewhere, and who bears accountability for outcomes they did not control. That is not a viable professional position, and it is not a viable organisational structure for building competitive products.

When the sign-off culture exists, the PM's job includes pushing back on it. Not through confrontation, but through the gradual accumulation of a track record that makes the approval requirement feel unnecessary. Make calls. Document your reasoning. Own the outcomes. When you are right, point to the decision and what it produced. When you are wrong, own it clearly and explain what you learned. Over time, that track record is the argument for the autonomy that the role requires.

If you are right, you earn trust. If you are wrong, you learn fast. Both of those are better outcomes than the slow erosion of waiting for permission that never quite comes in the form you need.

There is a version of the PM role that is primarily about communication: the decks, the dashboards, the roadmap reviews, the stakeholder updates. These things are necessary, and doing them well matters. But they are infrastructure for credibility, not the source of it.

Real credibility in a product organisation comes from one thing: the consistent production of outcomes that matter. Features that users actually use. Metrics that move in the right direction. Problems that get solved and stay solved. Those outcomes are what earn a PM the trust to make bigger calls, to be given more autonomy, to have their judgment deferred to when reasonable people disagree.

No presentation has ever built the kind of trust that a string of well-executed product bets builds. No dashboard has ever created the kind of confidence that a PM earns by being reliably right about what matters and reliably effective at making it happen.

Invest in the work. The communication of the work will be easier, and more credible, when the work itself is real.

This is the principle that ties everything above together, because it names the failure mode that the entire article is really about.

Frameworks are tools. RICE, OKRs, the Kano model, the Eisenhower matrix, Jobs to be Done: each of these exists to help a PM think more clearly about a specific kind of problem. Used well, they impose useful structure on situations where structure is what is missing. They are genuinely valuable in that role.

Used badly, they become something else: a way of appearing to make decisions without actually making them. A framework applied to a situation that needed a judgment call produces the appearance of rigour without its substance. It generates a score, a ranking, a quadrant placement. It does not generate the thing that the situation required, which was a PM willing to look at the available information and say: here is what I think we should do, and here is why.

The PM who reaches for a framework every time a decision feels difficult is not being rigorous. They are outsourcing their judgment to a system that cannot actually exercise judgment, and calling the output a decision.

Frameworks clarify. They do not decide. Knowing the difference, and being willing to step in with actual leadership when the framework has done its clarifying work, is what separates a PM who is leading from one who is hiding behind the appearance of it.

You cannot fake ownership. You cannot delegate courage. And no framework, however sophisticated, will make a weak product decision feel strong in retrospect.

The PMs who build products that matter are not the ones with the most elaborate processes or the most comprehensive roadmaps or the most disciplined sprint ceremonies. They are the ones who are willing to be clearly responsible for what they build, to move when they have enough clarity to move, to say no when no is the right answer, and to own the outcomes of their choices without hiding behind the process that surrounded them.

That is harder than following a framework. It is less comfortable than consensus. It produces fewer opportunities to point at the process when things do not work out.

It is also the only way to actually do the job.

Build with purpose. Decide with clarity. Move with intent. The rest- the tools, the methods, the meetings- exist to support those three things, and only those three things. When it stops supporting them, it is getting in the way.

A question worth sitting with: if every framework and every process you currently use disappeared tomorrow, what decisions would you still be able to make confidently, and which ones would leave you paralysed?

The decisions in the second category are the ones worth examining most carefully.