The Missing Layer Between Founder Vision and Shipped Product

When I joined Chainflip as the first product hire, the CEO had never worked with a product person before. Neither of us had a playbook for what this role should look like. But he could describe the pain perfectly.

The company was pre-mainnet launch. A few testnet launches had already happened, and they had not gone as expected. Everything was taking too long. The CEO did not know if the teams were working on the right things and the right way. There was frustration all around. Neither side could name what was actually broken. But the fact that he recognized something was missing and hired for it is exactly the kind of move that separates founders who get stuck from founders who get through.

Most founders think they need better engineers or more engineering capacity to move faster. The thing is, they are wrong about what is missing.

The gap between what a founder envisions and what engineering ships is not a communication problem you can fix with better standups or more detailed tickets (though everyone tries that first). It is a missing function. Someone needs to take the founder's vision, pressure-test it (is this viable? is this feasible? is this usable? does anyone actually want this?), and produce a spec that engineering can build against with confidence. Most early-stage teams skip all of this and go straight from idea to code.

This is even more true now. Frontier AI models are making it faster than ever to ship code. Engineers are not writing every line manually anymore. They are reviewing and steering. But the models still need to know what to build and why. The discovery work has not gone away. Its output has just changed shape: instead of detailed tickets and documents for humans, you produce the artifacts, the constraints, the guardrails in .md files that tell the model what success looks like. Skip that, and you are just shipping the wrong thing faster.

The cost is not abstract. Products launch late. Engineers burn out from rework and shifting priorities. Founders feel their vision was betrayed. And because nobody knows what the team is building, marketing, and comms cannot tell a coherent story either. For a startup still searching for product-market fit, this is the kind of mistake that kills companies.

You do not need to hire a full-time product manager to fix this. You can start by pairing with an external product expert who acts as a second brain for translating your vision into something your team can ship well.

What I found when I got there

On the engineering side, the frustration was mirrored. Engineers and designers saw competing priorities, shifting goals, and unclear direction. In their eyes, things kept changing. But the real issue was simpler: all the context about where the company was going and why lived in the CEO's head, which is normal for a founder who built the company from nothing. The problem was that there was no process to get it out. What engineering received were requests for specific solutions, not problems to solve. An engineer cannot deliver a good solution if they do not understand the problem. That context was completely missing for product and design.

Now, the first thing I did was not build a roadmap or set up a new process. I interviewed the CEO. I spent weeks extracting the business strategy, the product vision, the reasoning behind every decision from his mind and translating it into something the team could understand and build against. Why we were doing these things. Why we decided not to do other things. What the solution should look like and what constraints were non-negotiable.

That single act of translation fixed most of the problems within the first three to six months. Not because the engineering team suddenly got better. They were always good. They just finally had the context to do their best work. Chainflip went on to process over $6B in cumulative volume.

What most people get wrong about this

Most founders who have never worked with a product person picture a project manager: someone focused on delivery, timelines, process. A process cop. That is understandable, because most of what they have seen labeled "product management" in their world looks exactly like that. Especially, in the european tech scene.

But here is where most people get it wrong: the work that matters most is not delivery management. It is discovery. It is the work of figuring out what to build before engineering writes a single line of code. Reducing risk. Validating assumptions. Translating vision into scope.

Some companies genuinely just need a project manager, someone to keep engineering organized and accountable on delivery. That is fine. But if you are a tech startup, especially in crypto, chances are you have a smart engineering team that would be perfectly happy to self-organize if you gave them clear direction. In that context, what they need is not someone managing their sprints. They need someone doing the discovery work alongside them, reducing risk, and then getting out of the way so they can ship.

What to do about it

If you are reading this and recognizing your own team, ask yourself: are you doing the product work yourself, and is that really the best use of your energy? Could your engineering team do better with the talent and capacity they already have, if someone gave them the right context?

You do not need to hire a head of product tomorrow. I do product audits. Two weeks, one diagnostic. I look at how your team works, where the translation breaks down, and what is getting lost between your vision and what ships. Here is where to start.