Alfred AnyanInsights
← All insights

The Spreadsheet That Revealed Who Really Owns Your Roadmap

Top view of office supplies including a calculator, markers, and sticky notes on a wooden desk.

Photo by RDNE Stock project on Pexels

The roadmap survives most of its attackers. The engineer who wants to refactor to the new framework, the marketing lead with the urgent campaign, the investor who saw a competitor's demo and wants parity by Friday. Each one gets a considered no, or a negotiated delay, and the plan holds. The question worth asking is which requests you cannot say no to. In my experience, the answer is almost never another executive. It's the first product-operations hire, the person you brought in to take work off your plate, and the ordinary question they ask changes what gets built.

The question that ends up deciding

I hired our first product-operations person eight months into Asenda's current build. Capable, organised, exactly the relief I needed. The first week they asked for the roadmap. Fair enough. The second week they asked which of the items were truly committed, because a customer had emailed asking about one of them. I explained the distinction between what we'd promised and what we'd merely planned. The third week they came back with a spreadsheet of everything that had slipped in the previous quarter, and asked why the company was telling customers one date and the team another.

That is the moment the founder discovers where the real veto lives. Not the board, not the lead engineer, not even the largest customer. The person whose job is to track what was said versus what was built. Their question is not a suggestion. It is a mirror held up to every promise the company has made, and the founder has to decide which promises are real.

Authority is just the person who has to explain

Organisations route their hardest decisions to whoever bears the cost of being wrong. That is the mechanism, and it's worth naming plainly. The senior people in the room can overrule almost anything because they sit closest to the consequence. The striking thing is how few of them use the veto on the decisions that matter. They use it on the ones that surface in a weekly meeting.

In the winter of 1846, in the Sierra Nevada, a group of settlers got caught by early snows on their way to California. The Donner Party, as they came to be known, made a series of desperate, documented decisions over the months that followed: splitting up, sending a small group ahead on snowshoes, waiting for rescue that kept not coming. The details are grim and well recorded in the histories of the American West. What interests me is the ordinary structure beneath the extremity. Every one of those decisions ended with the same small group of people who had started the trip together. No one else was there to overrule them. The weight of each call, the ones that worked and the ones that did not, sat with the people who had to live the outcome.

Your startup is not the Donner Party. The stakes are a roadmap, not survival. But the shape of the decision is the same. You can hand off execution, you can hire well and delegate properly, and still every call that matters comes back to the founder. The moment you accept that, hiring becomes easier. The product-operations hire does not reduce the number of decisions you carry. They surface them faster, and with better data. That is the entire value. The moment you expect the hire to make the hard calls for you, the company has a new bottleneck with the same name.

What actually reaches your desk

Over two quarters I kept a running log of every decision that landed on my desk despite having a capable team. The majority were not technical. They were the ones nobody else could absorb the risk of. A customer in Accra wanted a custom integration that would take an engineer two weeks and break the published quarter. The salesperson wanted to say yes. The engineer wanted to say no. Both of them could live with either outcome. I could not, because I was the one who would explain the bad outcome to the next customer.

The second category was the commitments other people had already made. A partner in Berlin had been told we would have an API ready a month before the team planned it. Someone had said yes without checking. The postmortem was not about the technical timeline. It was about who had the authority to make a promise, and the answer turned out to be everyone and no one. That is the gap a first product-operations hire exposes immediately, because tracking promises is their actual job.

The third category was the ones I wanted to push away. The feature that made no sense for the product but a good customer had asked for. The hire that felt premature. Keeping the log taught me what I should have known at the start. The veto never left my desk. It had just been unlabelled.

The founder's own question

The practical version of this is uncomfortable. When you hire your first operations person, you are not handing over the authority. You are buying a clearer view of where the authority actually sits. The view is the product. Use it to decide, in writing, which decisions you will never delegate, and which ones you are currently hoarding out of habit rather than necessity. The list is usually shorter than you think on both sides.

The Donner Party's leaders could not delegate their way out of the mountains, because no one else had the same information and the same stake. You have the information, and you have the stake. The question the first product-operations hire forces is whether you will act like it. The roadmap is yours. The veto is yours. The only real decision is whether you admit it before the next quarter slips.

Comments

No comments yet.