Your Company Already Has a Head of Product. Nobody Told Them.

Somebody in a meeting asks why we're building this, and four people answer.

Sales says it's what the customer keeps asking for. Engineering says it's what's feasible this quarter. Support says it's the thing generating all the tickets. The founder says it's where the market is going. Every one of those answers is true. The meeting feels fine, nobody argues, everybody in the room is well informed about the particular thing they happen to be looking at, and then they all go back to work.

Something happened in that room that nobody noticed. Over the next year it will cost that company more than any of the decisions they think they're making.

I want to carry one company through this, and and because it's a composite and not anyone's real business, I'll call it Meridian. Forty people selling shift scheduling software to mid-size logistics operators, which is about as unglamorous as software gets, and they're doing fine. Sixty customers, six engineers, one designer. Nobody there has the words product manager anywhere in their job title. The founder is also the CEO and he still owns product himself, which he'd tell you happily and without embarrassment, because at that size it's a perfectly normal way to run a company.

On the wall of the room where they plan, there's a roadmap. It's a good one. Four quarters across, color coded, every initiative with an owner and a date against it. It gets updated. People point at it in meetings. When somebody new joins, that roadmap is the thing you show them so they understand what's going on.

Hold onto it, because it's real work and it's useful, and by the end of this it's going to answer none of the four questions the product job owns. Not answer them badly. Not answer them at all.

The artifacts are not the job

Go looking for what this job is and what comes back is a list of activities. Own the roadmap, talk to customers, write the specs, run the standups. Every one is a real thing a real person does, and I'm not going to pretend otherwise.

You'll also be told, correctly, that the role has no single definition, that it varies by company and by stage and by whoever else happens to be in the room. That's true, and I think it's true for a reason people don't usually follow up on. Define a job by its activities and the definition has to keep moving, because the activities keep moving. Define it by its decisions and it holds still.

The roadmaps and the specs and the standups are the artifacts of the job. They're what gets left behind after the work has been done. Here's the uncomfortable part: you can produce every single one of them in a company where that work never happens once. Meridian is producing all of them right now, beautifully.

So here's the version I use instead. The product job is four decisions. Not four skills or four responsibilities, but four decisions, in the sense that somebody chooses and then the whole company lives inside that choice for a year. You won't find this in a textbook and I'm not going to pretend it came from one. I got to it by watching what breaks in companies that have all the artifacts and none of the judgment.

Four decisions

Which problems we solve, and for whom. Out of everything a customer could want from you, which slice are you in the business of fixing, and for which customer? Notice what that isn't. It isn't a feature list, because a feature is an answer to a problem, and this decision is about which problems get answers at all. It sits upstream of every item on any roadmap you have ever stared at.

The second half of that question does as much work as the first. A dispatcher juggling a hundred drivers and a finance director signing off on payroll are living completely different working lives, and if you solve for both at once you'll build something that fits neither one particularly well. For Meridian that means choosing between two perfectly good businesses. They can be the company that makes shift scheduling effortless for the dispatcher, or the company that connects scheduling through to payroll and billing for operators who've outgrown their spreadsheets. Both are real. Both have paying customers today. They are not the same company, and they don't even need the same engineers.

What evidence justifies solving them. Before you spend four engineering months on something, what would you need to have seen to believe it's worth four engineering months? Evidence is one of those words that gets waved around until it stops meaning much, so let me be concrete. Eleven of our sixty customers asked for this unprompted last quarter, and four of them described the same workaround without being asked. That's evidence. One very angry email from your largest account is not. It might well be a reason, and reasons are allowed to exist, but quietly confusing the two is how roadmaps end up written by whoever shouted most recently.

Setting that bar is a decision and not a process, because somebody has to set it before you commit. If nobody does, the bar becomes whoever asked last, and it moves every week without anybody deciding that it should. You might have eight customers rather than sixty, and eight people can't give you a pattern. Fair. The answer isn't to wait until you have sixty. It's to lower what counts as proof and say so out loud. Three of our eight asked for this, and I watched two of them do the workaround with my own eyes is a bar somebody set on purpose.

What we decline. Not what we're deprioritizing, and not what's been parked in some later quarter where it can quietly rot. What are we saying no to on purpose, and expecting to still be saying no to a year from now? Companies almost never write this one down, and I've come to think it does more work than the other three put together. A strategy that only tells you what you're doing isn't a strategy. It's a wish list with dates attached.

For Meridian, the decline is enterprise custom integrations. The big operators want their own bespoke connectors, they'll pay real money for them, and every one of those deals is genuine revenue walking through the door. So declining it isn't declining money. It's declining a version of the company where six engineers spend their year building integrations for four customers.

Declines are hard to write down because they look like losses, and nobody wants a document listing what they've agreed not to earn. But an option you haven't declined isn't gone. It sits there costing you a little every quarter, in the meeting time it takes to re-argue and in the roadmap slot it holds open just in case. Meridian has had the enterprise integration conversation four separate times in eighteen months. Nobody has ever said no to it, and nobody has ever said yes either, so it comes back every quarter, eats an afternoon, and leaves in exactly the condition it arrived in.

One thing turns a preference into a decision, and that's writing it down. If it's written down, then when the deal shows up, and it will show up, the conversation is about whether to change the decision. If it was never written anywhere, the conversation is only about whether to take the deal. Those are two different meetings, and they tend to end differently.

What outcome we expect, and how we'd know. Before you build the thing, what has to be different afterwards for this to have been worth doing, and what exactly would you go and look at to find out? For Meridian, if they build that payroll connection, the outcome isn't that it ships. The outcome is that dispatchers stop exporting to spreadsheets on a Friday afternoon, and that's checkable. Shipping is a date on a calendar. The outcome is whatever changed in somebody's working week because of it.

This one has to be settled in advance for a human reason, which is that afterwards everybody turns out to be remarkably good at finding a number that says it went well. Usage went up, and nobody asks which users. Support tickets went down, and nobody stops to ask whether people gave up on reporting them. Deciding what you'd accept before you start costs nothing except the discomfort of writing it somewhere another person might read it.

Those four aren't a framework you have to go and adopt. They're a description of something already happening, because every company that ships anything is answering them continuously, whether or not a single person has written them on a wall.

Holding the roadmap up against them

Back to Meridian's wall. The roadmap tells you what's being built, and when, and by whom. It doesn't tell you which problems the company is in the business of solving. It doesn't say a word about what evidence got any of it onto the list. It says nothing about what they've declined, and there isn't an outcome written anywhere on it, because every item's definition of done is that the thing shipped.

Four decisions, and the company's central planning document, the one everybody points at in every meeting, is silent on all four.

Meridian's roadmap is not a bad roadmap, and it would be easy to hear this as sneering at it. It's doing its actual job, which is coordination: telling forty people what to expect from each other over the next few months. It was never designed to hold decisions, so it isn't failing at anything it was trying to do.

The trouble is that it looks like the job. It's the most visible thing the product function produces, so when it exists and it's tidy and everybody has agreed to it, assuming the thinking behind it happened somewhere is entirely reasonable. Sometimes it did. Often nobody did, and what you're looking at is a schedule everybody has agreed to believe in.

So who answered them?

Here's the part I find most interesting. Those four questions still got answered. They don't wait around for somebody to own them. Meridian has a live answer to all four running through the company right now, and not one person in that building chose it.

Which problems we solve is being set by whichever customer escalated most recently, because escalation is what reaches the founder's inbox. What evidence justifies it is answered by nobody at all; that one is sitting vacant. What we decline is being decided by engineering capacity, by the team running out of hours somewhere around week seven. And the outcome we expect is never stated, so nothing that ships gets judged against anything.

You'll hear this role described as responsibility without authority, usually as a complaint. I'd put it the other way around. The authority was never missing from the building. It got handed to people who didn't know they were holding it, and who are using it to answer questions nobody ever asked them.

None of those people is doing anything wrong. The customer who escalates is telling you something true about their own business, and knows nothing about your other fifty-nine. Engineering running out of capacity is a real constraint and not an opinion, and engineering knows exactly what's expensive to build without being placed to know what's worth building. Sales knows what would close this quarter. Every one of those is a real and accurate view of the company, taken from one window.

I've stood on one side of this myself. In my own startups, as CTO, product management reported to me, and early on that's the right structure. You need one person holding both sides of the fence: what customers are telling you on the outbound side, and what engineering understands on the inbound side. It works, and then the company grows and it stops working. You end up with a technology executive who has a conflict on one side of the fence or the other. Either I'm putting undue pressure on product management to do or say what I want, or I'm putting undue pressure on engineering to just do what I want, instead of letting those groups interact and operate more organically. Not because CTOs are the problem. Because I was a legitimate, well-informed, partial view too. I had a window, it was a good window, and it was still only one of them.

What the lost year looks like

Go back to that meeting, where four people answered the same question four different ways and every one of them was right. They weren't disagreeing. Each was reporting accurately from exactly where they happened to be standing. Four true answers, four windows, and no fifth person in the room whose job it is to choose between them.

Four windows and no chooser is what makes this so hard to see while it's happening, because the failure never looks like a bad decision. Every individual call was defensible, made by a competent person, for a reason you'd nod along with in the room. It's only when you line up a year of them that you notice they were answering to four different ideas of what the company even is.

Incoherence doesn't announce itself. Nobody can point afterwards at the quarter where you lost the year, because there wasn't one. Every individual month was fine. It shows up as a product that's slightly wrong for everybody and clearly right for nobody, and the roadmap is on the wall the whole time, still updated, still agreed, still the thing you show a new hire in their first week. The artifacts are all present and correct, so it never feels like anything is missing.

On the ground at Meridian, it's a payroll integration that's eighty percent finished, because it got started for the finance director and then quietly re-scoped halfway through for the dispatcher. It's two half-built onboarding flows sitting next to each other, and neither one is bad work. Both were sensible on the day they started.

Which is also why the instinct to fix this by hiring somebody usually doesn't fix it. Bring in a product manager while those four decisions still belong to nobody in particular, and what you've hired is another person to produce artifacts, often very good ones, while the company carries on being steered by whoever escalated most recently. That's worth sitting with if you happen to be writing a job description at the moment, because the description is downstream of all of this. You can't write a good one until you know which of the four you're handing over and which you intend to keep.

Ten minutes, on one page

Write the four down. Which problems we solve, and for whom. What evidence justifies solving them. What we decline. What outcome we expect, and how we'd know.

Do it for your own company, not a hypothetical one. Take the last significant thing you shipped and ask which problem it solved and for whom, what evidence you had before you started, and what you'd have accepted as a good reason not to do it at all. Most people find that three of the four have answers they can reconstruct if they think hard enough, and one of them is completely blank.

Don't try to answer them properly yet. Just write them down and sit with them a while, because the writing-down is the part that stings. You'll get to the third one, the declines, and find you can't name a single thing your company has ever said no to on purpose.

Once they're written down, the harder question is the one that took me years to start asking. It isn't who should own these. It's who's answering them today, because somebody is, right now, in your company, and they almost certainly never volunteered for it.

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 →