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:
- Product is solely responsible for developing high-quality hypotheses, which are then prioritised on a backlog based on potential value.
- 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?
