The real reason Product Managers are needed
It's Monday, and so time to ruffle some feathers...
The real reason Product Managers are needed… is because you do a shitty job without them.
Another Monday, another round of wavy-hand attention-seeking in the world of Product Management. Though not exactly an original thought on this occasion - this particular argument on the need and value of product managers is almost meta in itself.
Specifically, this is a perspective reportedly shared between start-up leaders and early-stage developers and engineers.
“Product Managers just slow things down”
“Product Managers do not add anything”
“[Founder] tells us what to build and we go and build it”
What has been interesting to read, however, is the opinion that this setup, of [founder/leadership - engineering] direct relationship, applies to any business, any size.
Lovely. Let’s sack off every Product professional, from PM to CPO. Not needed any more in any business from a tiny startup to the big mega-corporations.
Only, this is absolute horseshit.
Let’s examine a few of the possible reasons behind this thinking:
The engineers get frustrated with building more and more features with greater pressure from the business to deliver faster - possibly with fewer people or resources, and certainly not focusing on the mountains to technical debt under the hood.
The engineers are not being shared the context of why x is being built, just being used as coders-for-hire, or are being given rigid pseudo-technical requirements with any ability to feed into the plans or comment on the feasibility.
Founders want a feeling of more control over what is shipped, either through ego or simply because of a lack of visibility.
Founders find it difficult to communicate their true vision or have a discussion in a way that is practical to implement it.
A little story about the founder who thought he could Product
Day 1, things look rosy - the founder and engineering leaders meet, have pizza, talk tech for hours with plenty of feature-creep and end the day energised and high-fiving each out of the room.
Around day 10, everyone meets for more pizza and high-fives, and the founder has cogitated on some tweaks and new ideas, very excited, while the engineers have questions about the original set of requirements. Everyone is accommodating, and plans change
Around day 30, everyone meets and is looking for a different lunchtime takeaway as the founder is asking for updates regularly on progress, or things to be able to show their sales teams, their board or investors. Engineers respond with they had to rework a lot after their last set of changes, and are behind.
Around day 90, everyone hates pizza for life and things are fractious between the tech and commercial teams, as there has been sporadic communications, no documentation, and little by way of understanding of what the product is, does or when it is coming. The founder now has other priorities within the business to focus on, like investors, building a sales team, and meeting high-value clients. Engineers have little further contact with them and are interpreting and assuming a lot.
Around day 180, an advert for Pizza Hut causes psychosomatic vomiting amongst the longest-serving engineers, and things are in a bad way. A product is out, but it is not aligned with the vision, or what customers need. Sales folks are in hysterics asking for changes, fixes, and new additions, and are all scheduling calls with different engineers, taking their time away from developing the product, and even then are all working in different directions. The founder doesn’t have time for this as he is focused on ‘building the business’ and delegates all product-related queries to the engineers - ‘just ask them and they’ll sort it’.
It’s a fun story, it is cliched, and we would think unrealistic, but it is sometimes closer to the truth in reality.
While Product professionals are battle-hardened to under-appreciation in what they do, often unknowingly to the larger business, this does not diminish the value they bring by way of organisation, interpretation, filtering information and a voice of reason and calm.
They gate-keep engineering teams to allow them to focus on actually building, not the constant demands from many individuals, many agendas and many requests or demands for updates, ‘my’ feature, ‘we’ll lose this customer if we do not’.
From that, they prioritise and are tasked with understanding where the most value with the least effort can be found. If they are not doing that well, that is another story, but that is at the core of the job.
They focus on what is best for the business goals and spend a lot of time understanding this and comparing it with customer needs. It is not all about what one individual, one team or one customer wants.
They mitigate the risks, investigate and remove assumptions, and guard against inefficient, unnecessary work or changes and flip-flopping between initiatives.
They provide documentation, updates, demos, webinars, plans, gather designs, speak to customers, research, data & analysis, competitive, pricing & market analysis…
Product professionals provide a lot more than this, and there is a mountain of evidence and guidance on the role of Product Management that I do not need to repeat. The point, however, is all of these tasks are critical and well-established in tech businesses. Without Product - then who does this?
Will engineers want to take this on?
Will founders want to take this on?
And as businesses scale, will either of those want to or be able to do these tasks at scale too?
And if the answer is to delegate - then to whom?
I have absolutely no doubt that a business can be without a Product Manager - the questions are: for how long? And what does the landscape look like down the line?
Perhaps that variable is critical the next time Product critics need their next dose of attention.
Graham