The Role Your Startup Is Missing, and Why It's Worth Paying For

On a platform I built recently, the engineer in me wanted to start with a full billing suite. We don't have a single customer yet, and the first five can be billed by hand.

I have the opposite weakness too. The product side of me can fall hard for a clever feature that nobody will ever use. Both instincts are mine, and it took hands-on experience across multiple projects to learn that the job isn't picking one. It's knowing which to trust on which decision. On that platform, the full billing suite became a fast follow, and onboarding for the first customers will run through a JotForm.

In my last post I said somebody has to own the decisions between the product vision and the technical build, and that in most early teams nobody does. That somebody isn't a senior product manager, and it isn't an AI architect. It's someone who can tell you what each product decision costs to build, and the only people who still know that cost are the people who still build.

The Job Is Deciding What Not to Build Yet

Part 2's open questions need answers, but the more valuable call comes one step earlier: whether the feature belongs in v1 at all.

For every feature, this person makes one of three calls. Build it now, because the product doesn't work without it. Handle it by hand or with an off-the-shelf tool for the first five customers, because doing it manually teaches you what to build. Or cut it, because nobody has asked for it yet. The billing suite and the custom onboarding flow were both the second kind. The clever feature is almost always the third.

Getting those calls right takes both instincts at once. The engineer knows what the billing suite really costs, including everything it drags in behind it. The product side knows whether the first five customers care. Left alone, the engineer builds too much of the right thing, and the product person asks for too much of the wrong thing.

AI changes one part of this job. When building was slow, a prototype was a commitment. Now a rough version takes a day, so this person can build to decide instead of building to ship. When a question won't settle on paper, they put something in front of a customer before the team commits a sprint to it. The prototype gets thrown away. The decision is what you keep.

Look for People Who Never Stopped Building

Here's the honest truth: this is my own path. I started strong on the engineering side in college, then shifted into consulting, then into the business side, then into product management. What I never did was stop writing code. I kept building my own projects to learn, and I Am Black Business was one long learning project.

It also taught me the first trap to avoid. A product manager who used to code knows what things used to cost. Those prices go stale fast, and AI made them go stale faster. Someone who stepped away from building five years ago will price your decisions from a five-year-old list.

The backgrounds that tend to produce the real thing:

Engineers who moved into product and kept building. They've paid for bad decisions in code, so they price them honestly. Watch for a bias toward whatever is most interesting to build.

Founding engineers at companies that had no product manager. Product calls fell to them by default, and they lived with the results long after launch. Watch for the urge to build for a scale you haven't reached.

Technical leads from development agencies. They've turned dozens of vague client requests into buildable plans on fixed budgets, so pricing decisions is the whole job. Watch for someone used to letting the client make every final call.

The ones that look right but usually aren't: the PM who took a bootcamp, the "product-minded" senior engineer who has never owned an outcome, and the big-company specialist from The Right People for an Early Team, who designs for traffic you won't see for years.

To tell the real thing from a good imitation, ask for two stories. One about a feature they cut because it cost too much to build. One about a technical approach they dropped because it was wrong for the product. Someone strong on only one side will tell one story well and stall on the other. Then hand them a line from a real spec, like "users can manage their appointments," and ask them to turn it into decisions with a rough cost on each. The good ones ask questions, put prices on things, and cut. The others write a longer description.

Price It Against the Team, Not the Salary

Someone like this isn't cheap, and founders instinctively hold their rate up against a senior engineer's salary. That's the wrong comparison.

On that same platform, I measured what I built with AI against an estimate for one senior engineer doing the same work the traditional way. I'm not putting the figures here, because a number invites exactly the wrong comparison. The gap wasn't close. To ship the same scope in the same calendar time without AI, you'd have needed a team. A security hardening pass on the platform since then measured out the same way.

The point isn't that the role is cheap. Most of the cost of building software was never the typing. It was the rework: features built to a guess and rebuilt once someone decided, integrations wired one way and then rewired the other. AI made the typing nearly free and did nothing for the rework. The person who owns the decisions is the one who removes it, so price them against the team and the rework they replace.

Two objections come up every time.

The first is headcount: you can't add a senior hire right now. You may not need to. The role is heaviest while decisions are being made and lighter once they're written down, which is why many people who do it well work part time or on contract.

The second is dependency: what happens when the one person everything runs through leaves? Look at what they produce, though. Their output is written decisions, so done right they leave you less dependent on any one person, not more. If the decisions only live in their head, you hired the wrong one.

If you want your own number instead of mine, count the features your team built last quarter that got rebuilt, reworked, or quietly turned off. Put a rough cost on each. That total is what the missing role is already costing you.

Ask for Both Stories

On Monday, find whoever is making your product decisions right now. It might be you, a developer, or nobody in particular. Ask them for the two stories. If they can tell both, give them the authority to make those calls and ask them to write each one down. If they can only tell one, you've found your gap, and filling it is the work I do at Genesis 37 Labs.

Notice that the JotForm was a build-versus-buy decision. It was easy because the definition was already done. Next time, I'll take on the version of that decision teams agonize over most, and why it was never actually hard.