In the dynamic and often tumultuous world of high-growth startups, the role of a Product Manager (PM) is of critical importance.

This role is not just about managing a product; it’s about wearing a plethora of hats, juggling a myriad of responsibilities, and being pulled in countless directions, all in the pursuit of one goal: growth.

As the first part of a mini-series on maximising the value of your product function, I wanted to dive deeper into what a typical product manager actually does, and offer an alternative (albeit somewhat contrarian) approach that could help start-ups and scale-ups unlock new growth.

Given the cross-functional nature of the role, this piece also touches heavily on the relationship between product and tech. Later, we’ll look closely at how product teams should work with the CEO and marketing function too.

1. THE DILEMMA: PRODUCT MANAGER OR PROJECT MANAGER?

With so many competing priorities (and very finite resources), how a product manager should be spending their time has become something of a contentious topic in the start-up world. It boils down to identifying and understanding the distinction and balance between product and project manager.

Key to this conversation is understanding not only what the product development cycle looks like, but crucially how the product manager works with the tech team (i.e. engineers, designers, analysts, etc), who bring the vision of the product to life. Tech teams are often a start-up’s scarcest resource, so it’s vital that product managers are able to effectively guide their focus and efforts.

Your product hypothesis could make or break your business: Invest wisely.

In the iterative and data-driven world of product development, the PM plays a pivotal role in developing hypotheses that address unmet customer needs. This continuous cycle of hypothesising, building, testing, and learning is fundamental to improving product-market fit and, by extension, accelerating business growth. It’s a high-stakes game, and spending time on the wrong hypotheses will not only harm growth but could in severe cases threaten the very existence of the business (for example by hampering its ability to capture market share or secure funding).

With this in mind, it would make sense for the PM to be primarily, and relentlessly, focused on developing the highest-value hypotheses. This is where their time and effort should be predominantly invested, rather than being swallowed up by other tasks in the delivery chain.

In practice, however, PMs often find themselves acting more as project managers, with a significant portion of their time (sometimes up to 80%) dedicated to delivery. This includes coordinating delivery, assessing quality, managing dependencies, designing UI mocks, liaising with stakeholders, resolving team conflicts, and even contributing to sales and support activities.

You can see how it happens. It’s understandable that after developing a hypothesis, the PM would become deeply invested in validation, implementation and delivery. And given how unpredictable high-quality hypothesis development tends to be, many PMs naturally gravitate towards delivery, which offers more immediate and tangible outcomes. Ambiguity of roles between product and tech can also be a barrier here.

The misalignment of objectives: Product vs. Tech

In many organisations, there is a fundamental misalignment between the objectives of the Product and Tech teams. While Product is rewarded for creating business value, Tech is primarily accountable for the quality of implementation. This dichotomy can lead to conflicts in priorities and a lack of unified direction.

The consequences of this misalignment are profound:

  • PMs have less time for high-quality hypothesis development, which is often where their intrinsic motivation lies.
  • Engineers become less invested in the business’s success, leading to a more agnostic attitude towards the company they work for.
  • The focus on tech debt limits the autonomy of the Tech team, leading to conflicts in prioritisation between PMs and Tech leaders.
  • PMs with technical backgrounds are often favoured, as they can navigate tech debt discussions more effectively, further entrenching the PM’s focus on solutions rather than hypothesis development.

2. PLAYING DEVIL’S ADVOCATE: A HYPOTHETICAL ALTERNATIVE APPROACH

So what happens when Product focuses less on delivery and more on hypothesis development? In this model:

  1. Product is solely responsible for developing high-quality hypotheses, which are then prioritised on a backlog based on potential value.
  2. Tech takes complete ownership of delivery, deciding in each cycle or sprint whether to work on the most valuable hypothesis from the backlog or on tech debt.

In this approach, the PM’s role is to identify the most valuable problem that can be solved with the available resources (e.g., one story point). The Tech Lead’s role is to decide whether to invest these resources in improving the tech stack or in extending the company’s offerings to the customer. Additionally, Tech Leads are responsible for enhancing the team’s velocity in partnership with Product, Design, and Analytics.

For this model to be effective, both Tech and Product must share the same business objectives. This requires a mutual trust where Tech believes in the PM’s ability to identify the right problems to solve, and Product trusts Tech to allocate resources effectively towards customer value.

The initial proposal on who does what, while promising, is incomplete. A more holistic approach would involve:

  • Product responsible for developing high-quality hypotheses and prioritising them on a backlog.
  • Tech owning both delivery and operation from start to finish.
  • Clear alignment on business objectives across both Tech and Product.

In theory, this approach should lead to a higher return on investment for the scarcest resources and enable faster business growth through more rapidly improving product-market fit. But does it work in practice?

3. CASE STUDY: THE THEORY IN PRACTICE AT BOOKING.COM

At Booking.com, my colleague Sid observed that discussions with PMs often revolved around delivery bottlenecks and conflicts between Tech and Product leaders. Strategic thinking seemed to be taking a backseat. Implementing the proposed structure, where PMs were barred from participating in sprint planning, allowed Engineering Managers to make decisions without immediate pushback, and protected squads from last-minute changes.

It took a couple of months for the teams to fully adapt to the new method, but the consensus was clear: this approach was more effective for both functions. However, adjustments were made, such as inviting PMs back to sprint planning meetings for their insights into business value, while maintaining the new ownership structure.

“There’s an inevitable element of risk in such a radical restructuring of responsibilities and team dynamics. In the short term, PMs, Tech & Leadership, all are out of their comfort zone. But persisting paid dividends, resulting in a more dynamic, responsive, and innovative product development process that was better equipped to meet the ever-changing demands of the market” Sid

Both functions saw benefits from the new approach. PMs appreciated having fewer meetings and more time for hypothesis development. Their initial fear of not shipping new features was overshadowed by the benefits of this new approach. Tech, on the other hand, embraced their newfound autonomy and became more engaged in understanding and achieving business objectives.

This shift led to developers taking greater ownership of cross-squad dependencies and even proposing business hypotheses. However, some challenges arose, particularly with PMs entrenched in their traditional roles and some Tech Leads struggling with the added business responsibilities. These challenges required careful management, including role adjustments for those less comfortable with the new expectations.

Embracing a new paradigm in product management for start-up growth

There is clearly an argument to be made for a more strategic, hypothesis-focused approach to product management. That said, each team and business will have its own unique dynamics and requirements, and it’s not a transition that can happen overnight. In the case of Booking.com, shifting to this less traditional model unlocked significant business value, with product and tech teams working collaboratively and efficiently towards a shared strategic goal.

If you’re open to experimenting with unorthodox tactics, the secret to accelerating your start-up growth may well lie in redefining the role of product management – shifting from a delivery-focused approach to one that prioritises strategic hypothesis development. You never know what you might unlock…