Operator’s Guides — Product Leadership · Module 2 of 12

Four People Are Deciding Your Product Strategy. None of Them Know It.

The four product decisions never wait for an owner. When nobody has them, they get answered by whichever constraint pushes hardest and soonest.

All Product Leadership modules
Module 02 20:25 video + article

Watch this module

Module 2 of the video course. The article below covers the same ground in written form, so you can watch, read, or both.

A customer writes in on a Tuesday. The export is broken, she says. It isn't broken, it turns out, it just doesn't do the thing she needs, but she's upset and the founder reads the email himself.

He forwards it to the lead engineer with a note. Can we look at this. Not should we, and not is this the most valuable thing we could do this week. Can we look at this. The engineer looks, says it's about a week, and the founder says let's do it, because a week sounds small and the customer is upset.

Four product decisions just got made, in about ninety seconds, and nobody in that thread experienced any of them as a decision. Which problem got chosen, by the customer. What evidence was required, none. What got declined, whatever that engineer was going to spend the week on instead. What outcome anybody expected, nobody said.

Multiply that by forty in a quarter and you have the whole thing.

The decisions don't wait

In part one I said the product job is four decisions: which problems we solve and for whom, what evidence justifies solving them, what we decline, and what outcome we expect and how we'd know. What took me an embarrassingly long time to understand is that those four never wait for somebody to own them.

They can't wait. The company ships anyway, and shipping is impossible until all four have answers. Think about what it takes to write one line of code on a Tuesday. Somebody has decided which problem that line is for. Somebody has decided it's worth doing. Somebody has decided what isn't getting done that day instead. The answers exist, because the work is proceeding, and work only proceeds on answers.

So when a decision has no owner, it doesn't go unanswered. It gets answered by whichever constraint pushes hardest and soonest. That's the whole mechanism, and everything else here is a consequence of it.

Which means the question was never whether your company has a head of product. Something is performing that function today whether you like it or not. The real question is what that something is, and whether you'd have chosen it if anybody had asked.

Who ends up holding each one

Which problems we solve goes to escalation. Not to the biggest customer, and not the most strategic one, but to whoever escalated most recently. There's a reason it's escalation specifically: it's the one signal engineered to reach the top of the building. A customer who is quietly unhappy sends nothing. A customer who is loudly unhappy sends an email that lands in the founder's inbox on a Sunday, and by Monday the quarter has a new shape.

Notice what escalation isn't measuring. Not how many customers have the problem, not what it costs them, not whether they're the kind of customer you want more of. It measures how willing somebody was to be loud on a particular Sunday. And your quietest customers are quiet for two completely different reasons. Some are perfectly happy. Some have already given up on you and are running a workaround they'll never mention until the renewal conversation. Escalation can't tell those two apart, and neither can anybody relying on it.

What evidence justifies solving them is the odd one out, because it doesn't get answered by a person at all. That seat sits empty. Nobody decides how much proof is enough, so the bar becomes whoever asked last, and it moves every week without anyone noticing it moved. One week a single customer call clears it. The next week a competitor's launch clears it. Neither is a standard, and nobody ever compared them.

What we decline belongs to engineering capacity, and I want to be precise, because this isn't engineers making strategy. The team runs out of hours somewhere around week seven of a quarter, and whatever hasn't started by then is effectively declined. Nobody said no. The calendar said no, and the calendar says no to whatever happens to be last in the list. That's a decline with all the consequences of a decline and none of the deliberation, which is the worst version of it available: the loss without the choice.

What outcome we expect is answered by silence. The feature goes out, and the definition of done is that it went out. Six weeks later, if anyone asks whether it worked, everybody looks at the same dashboard, finds a line that went up, and the conversation ends there.

Naming the humans

A list of roles is one thing. Naming actual people is where this gets uncomfortable in a useful way, so let me do it on Meridian, the composite company I'm carrying through the series.

Which problems Meridian solves is being decided by a dispatcher at a logistics company in Ohio. She isn't an employee. She's never been to the office. But she emails the founder directly when something breaks, roughly every three weeks, and those emails have reshaped two of the last four quarters.

What evidence justifies solving them is being decided by nobody, and I mean that literally rather than rhetorically. There's no person at Meridian you could point at. That decision is vacant, and it's the only one of the four that is.

What they decline is being decided by their lead engineer, who would probably be surprised to hear it. He's not making strategy calls. He's answering the question he does get asked, which is can we fit this in, and his honest answer is quietly setting the company's strategy.

And what outcome they expect is being decided by the fact that their roadmap has a column called Done. Once a thing is in that column, no further question gets asked about it. The column is the answer.

So the four owners are a customer in Ohio, nobody at all, a lead engineer, and a column on a spreadsheet. That's Meridian's product leadership, running right now, while the founder tells people he owns product.

He isn't lying when he says that. He believes it, and he's in every one of those conversations. He forwards the escalation himself, he nods when the lead engineer says it won't fit, and he looks at the Done column along with everybody else. What he's doing is participating in four decisions that were already made by the time they reached him, and being in the room is not the same as making the call.

I want to be fair to him, because he's doing the hardest version of the job. He's the only person in that company who sees all four decisions at all, even partially, and he's seeing them while running sales, hiring, and the board relationship. What he doesn't have is twenty minutes in his week where those four questions are the only thing in front of him. Not a process, and not a framework. Twenty minutes with nothing else open. That absence is the entire problem, and it's invisible, because nothing about his calendar looks wrong either.

Every one of them is right

The fairness of those four is the part that matters more than the audit, and it's where most people go wrong with it.

The dispatcher in Ohio is telling Meridian something completely true about her own business. Her problem is real, it costs her real money, and she's the world's leading expert on it. She isn't manipulating anybody. She's reporting accurately from the one place she can see. The lead engineer is right too: capacity is a fact and not an opinion, and a company that ignored him would ship nothing at all.

Each of them is looking through one window, and it's a real window with a real view. The dispatcher sees her own operation in complete detail and knows nothing about the other fifty-nine customers. The engineer knows exactly what's expensive to build and isn't positioned to know what's worth building. Sales knows what would close this quarter. Every one of those views is accurate. None of them is the view, and there's no fifth window that shows the whole building.

Which brings me to the turn, and it's the thing I most want you to take away. None of those four people experiences themselves as deciding anything.

The dispatcher thinks she's reporting a bug. The lead engineer thinks he's answering a scheduling question. The founder thinks he's staying close to customers. Not one of them thinks they just set product strategy, and in fairness, none of them did. Each answered the question they were each asked. The sum of four honest answers is a direction nobody chose, and that nobody would defend if you laid it out on one page.

That drift is hard to see from inside, because at no point does anything look wrong. There's no meeting where the bad decision visibly gets made. Every individual call is defensible on its own terms. The incoherence only becomes visible when you line up a year of those calls next to each other and notice they were answering to four different ideas of what the company is.

It shows up as a product that's slightly wrong for everybody and clearly right for nobody. Not broken, and not bad. Consistently a little off, in a way that's very hard to name in a meeting. And the roadmap is on the wall the whole time, updated, agreed, and shown to every new hire in their first week. The artifacts are all present and correct, so it never feels like anything is missing.

Why hiring doesn't fix it

Bring a product manager into a company where those four decisions still belong to nobody in particular and you haven't moved the decisions. You've added a person who produces artifacts, often very good ones, faster and more consistently than before. The escalation still reaches the founder, capacity still closes the quarter, and the Done column is still the answer. What's changed is that there's now a better roadmap describing the same decisions, made by the same four people, in rather more detail.

The new hire usually knows. Ask a product manager six months into a job like that what they own and you'll get a careful answer, because the honest one is uncomfortable to say out loud in your first year.

I've been on the other side of this, briefly. In my own startups product management reported to me as CTO, and I didn't feel like a default decider either. I felt like somebody answering reasonable questions all day. That's the part worth holding onto: the people running your product function by accident aren't going to raise their hands, because from where they sit nothing unusual is happening.

Fifteen minutes, one page

Write the four down the left side of one page. Which problems, what evidence, what we decline, what outcome.

Then next to each one write a person's name. A real name of a real person in your company, or the name of a customer, or the word nobody if that happens to be the truth. Don't write a department down, because departments have never decided anything. You'll do three of them in about four minutes and then sit looking at the fourth for quite a while, and that's the useful part. The one that takes longest to name is usually the one that's been running on its own the longest.

When a name turns out to be somebody outside the company, or a spreadsheet column, or the calendar, don't fix it yet. Write it down accurately. You can't reassign a decision you haven't located.

Then add a second column, and in it write what would have to be true for that name to change. Not who should own it instead, which is a much bigger conversation. Just what would have to be true. For the evidence row it might be as small as somebody writing down what counts as enough. For the decline row it might be one sentence somebody is willing to say out loud in a sales meeting. Those are small, and they're the difference between a decision you made and one that happened to you.

That page is a diagnostic and not an accusation. Every name on it belongs to somebody doing their job well under the constraints they can see. Decision by default isn't what bad companies do. It's what busy competent people do when nobody has been given the call.

And once the page exists, it raises a question the page can't answer. Knowing the calls are scattered doesn't tell you whether what you need is an executive with real decision rights, a director executing a strategy somebody else set, or a founder who does this deliberately on a Tuesday morning instead of by accident. Those are three different companies, and three different hires.

Get the next guide

ISO 14971 and product leadership are the first two Operator’s Guides. ISO 13485, IEC 60601, and the GHG Protocol are in the queue. Leave your email and each new guide lands in your inbox the day it ships. Nothing else, no drip sequence.

Done. You’ll get the next guide when it ships.

The course is free. If you want help doing the product job, that’s the work I do.

Work With Dave

Prefer a smaller first step? Book a $500 one-hour working session →

Dave Saunders

Dave Saunders is the founder of Base Reality Group and a Fractional CPO for product companies. He was a founder and operator at Galen Robotics, where the surgical-robotics platform earned FDA De Novo authorization in 2023, and he managed a 35-patent portfolio licensed from Johns Hopkins. He wrote Founders Who Finish and publishes The Build. More about Dave →