Don't Take Over. Earn the Handover.

When I read the job description, it said I'd own product strategy. The organisation chart backed that up but the founder hadn't handed it over.

I noticed it in the details: decisions I thought were closed got reopened, conversations I thought I owned got redirected, meetings that should have moved forward kept circling back to him.

He wasn't necessarily being difficult. From his perspective, handing over product decisions was still risky.

This is where new product leaders often get caught in founder-led companies. They arrive with the title, the responsibility and the expectation to make an impact, so they start acting like the authority has already transferred: reorganising the team, replacing the roadmap process, introducing a prioritisation framework from their last company and running a workshop to explain how decisions will now be made.

It looks like leadership. To the founder, it looks like someone changing a business they don't understand yet.

The founder knows things that aren't written down

A founder has usually spent years making product, customer and commercial decisions. Some of those assumptions will be outdated, some will be personal preferences dressed up as strategy and some will just be wrong. But there's usually history behind them: the enterprise client that nearly left, the feature everyone wanted and nobody used, the pricing change that looked obvious and quietly damaged sales, the customer segment that sounded promising until the company tried to serve it. That context rarely makes it into a strategy document.

The incoming product leader needs to understand where the founder's judgement came from without getting trapped inside it. The job is to understand what they're protecting, which instincts still hold and which assumptions need to be challenged, not to think exactly like the founder.

Authority isn't transferred in a meeting

You earn the handover through decisions, not by proving you know more product frameworks.

You catch a problem before it reaches engineering because the commercial case doesn't hold up. You speak to customers and find the requested feature isn't the real reason they're considering leaving. You challenge a large client request because it would eat months of capacity without reducing renewal risk. You recommend solving an issue through pricing, onboarding or account management instead of automatically turning it into software.

Sometimes you land on the same conclusion as the founder. Sometimes you don't. What matters is that they can follow your reasoning: you understand the customer, the economics, the constraints and the consequences of the decision.

One sound call leads to another and the founder starts asking fewer questions. Decisions stop getting reopened. He no longer feels the need to join every meeting, because being absent no longer feels risky.

That's the handover.

Moving too quickly usually slows it down

The common mistake is establishing authority before establishing judgement. It's understandable: you were hired to lead and you want to show progress.

Process is an easy place to start because it's visible and controllable. You can change meeting cadences, templates, team structures and roadmap formats within weeks. Understanding the business takes longer.

You need to learn:

• how the company makes money
• which customers retain, expand or leave
• what has already been tried
• where delivery gets stuck
• which decisions still depend on the founder
• where the founder's view is helping
• where it has become a constraint

The timeframe depends on the situation. A company with limited runway can't spend six months observing, a fractional head of productFractional Product Leadership might only get a few weeks and even a risky decision doesn't need months of study if it's reversible.

The sequence matters more than the duration: understand the context, make a sound recommendation, show your reasoning, check the result, then take on the next decision.

The real outcome isn't trust

Founder trust matters but it isn't the final goal. The real goal is a company that can make good product investment decisions without every one of them passing through the founder, where decisions connect customer evidence with commercial outcomes, product and engineering understand why work deserves capacity and the founder can focus on the decisions that require them instead of reviewing every feature, project and roadmap change.

Sometimes that transition works. Sometimes the product leader demonstrates sound judgement and the founder still pulls every important decision back. At that point, it's the operating model, not a trust-building problem and a founder who can't let go will remain the product bottleneck regardless of who gets hired beneath them.

But when the handover works, there's rarely a formal moment. The founder stops joining some meetings, fewer decisions return for another round and the team starts moving without waiting for permission.

The title gave you responsibility on your first day. The handover happens when your decisions no longer feel like a risk the founder needs to manage.