Engineering CAN replace Product Management
As Cofounders are you thinking of how your Engineering teams can replace product teams? Well, here's a few preconditions & how that could all be made possible.
Definition & Scope
Not too long ago, delivering a seminar on the topic “Human aspect of Engineering”, I happened to pick one of the definitions as dished out by Google via those default dictionaries.
This is how it looked (as it is even today):
And this here is a proposed redefinition of it (holding good for the current age of 2023 with an open mind that it could all change over the years to come):
Engineering deals with building the product based on a certain set of requirements that are identified as suited to serve a purpose. So, the questions it addresses broadly are:
“what exactly do we have to build?”
“how it ought to be built?”
“how do we go about building it?”
I can’t help but see how there seems to be some prevailing confusion in some pockets over the scope of engineering and it’s application towards the expectation of outcomes, some real, some absolutely surreal.
Point of Confusion!?
Take a look at this VENN.
It shows how product managers effectively ought to operate at the quaint intersection of:
Business – the high-level goals of a business
Tech – the effective use of technology
UX – the eternal quest to deliver the best of user experiences
But, now for the moment of truth, take a good close look at this VENN.
But, so does Engineering, operating at the very same intersection.
NOTE: Some engineering purists may argue that it has absolutely nothing really to do with Business. But, if any time you’ve had a stint with coding, I suppose every one of you can roll the date back to that day in your lives when you happened to have tons of questions over why you are building something that just didn’t make any sense at all.
Let me prove it to you here.
Scenario 1 – ZERO Business Context – ONLY Engineering:
Here’s a conversation most of us would correlate to from 2 decades back.
Two Engineers in conversation
Eng1:
no, this part of the code where it is looking for the incumbent file just isn’t working at all, there’s a lot of confusion over the timing of the file’s arrival
it just flashes some crazy errors & crashes down
Eng2:
how about we try inducing a delay in triggering the function
doing so may resolve the error as the input file might have been populated
→ you see how working without context could be really edgy!
Scenario 2 – Clarity on Business Context – SPECs defined:
The same conversation would now look like this.
GIVEN:
Business Context: the business units have got to populate the day-end records for us to process it, calculating stock, inventory, unit sales & report PnL
Eng1:
no, this isn’t working, I see a NULL exception caught
we’ll need to implement an active listener which would ensure that the input file is dropped indicating that it is time to trigger further processing
but, we may need to implement some checks to ensure there’s no data loss as the file is moving over servers being populated at multiple touchpoints (SKUs - data collection)
only after these checks should the processing functions get triggered
with of course, proper error reporting covering nuanced cases / sub-cases
→ context is worth its weight in gold for all teams!
But now, going back to where it started from, here’s an important question:
If both engineering & product management happened to operate at the same intersection (Business, Tech, UX) how’re they different then?
Subtle Differences
The difference primarily is at the level of outcomes and also their inherent scope as applicable to the parlance of the problem space and the solution space.
Product Development / Engineering
Engineering operates deep in the solution space. In essence if one is talking about product development, it simply ought to mean that the product has cleared all the initial tests and stood its ground validated and teams now have a thorough understanding of the Feasibility & Viability at a very high level and the research leading to an unambiguous understanding of the market’s & user’s needs / pain points at a much granular level.
The outcome of engineering is a fully functional working product that’s coded according to SPECs and if not totally bug-free is at least managing to keep it below a set and accepted standard.
Engineering regular day’s workflow:
Product Management
Product Management operates at a much higher scope in the problem space & then gets down to using that clarity thus obtained to define and draw out the details of the solution space as well.
The outcome of product management often involves taking ideas from a nascent concept stage and seeing it through right from there (0) to product build (1) growth (n* x | where 2 < n < ∞) and beyond over iterative cycles of improvement.
Product Manager’s regular day’s workflow:
As is evident, a product manager’s role has a much wider intricate scope, ownership & accountability as opposed to that of engineering / product development.
The Quaint Overlap
Being disjoint isn’t at all a possibility even in the remotest nook of the planet over the way teams work as of today. And, of course, there is clearly a visible overlap between engineering and product.
Look at the PM’s PIE, the ones in BLUE – SPECs, Tickets, Sprint Planning have directly to do with product development / engineering & their outcomes.
SPECs – The mandate of what is to be built ought to reach the DEV teams in the form of SPECs & ought to be unambiguously clear for any tangible work & progress to be achieved
TICKETS – It’s only obvious that any piece of working software is bound to carry some bugs or get reported randomly while being used on the field which ought to be addressed within a stipulated time to keep up the experience of the users
SPRINT PLANNING – With software development boasting of going Agile ever since a decade top, the word phrase sprint planning has been a de-facto association, building team’s accountability over facilitating the SEM (Software Engineering Manager) by spelling out of their deliverables so as to add up to outcomes
CAN Engineering replace PM?
And now to the main question:
Can engineering replace product management?
The answer simply is a “YES”, but over a few preconditions.
Case 1: Early Stage Start-ups
Startups is often the place where there seems to be ample room for role overlaps & seamlessly too. When most of that happens on the back of a lack of choice & being strapped up too tight, there has been a history of engineers taking over product roles in part and whole.
Quick Fix:
Perhaps, hire a product guy or get an external product consultant who can assist in stepwise planning & chart out strategies, helping teams deploy them!?
Case 2: Big-ticket MNCs
Take a look at the big ticket MNCs where there are tons of people holding individual positions clearly demarcated over their roles. When the problem doesn’t seem to be a total lack of choice, it is how they seem to be spoilt for it.
Quick Fix:
That’s the talking point. There isn’t a straightforward one in this case. Talk of implementing a change and the TAT to propagate that Top-Down is so high that one’d have to wait a few silos before any visible changes are seen.
Here’s a generic list of blockers you’d have to address before going ahead with that long-tall replacement.
The Blockers (And yes, it is a long list)
When Engineering taking over or doubling up as Product function is an operative model alright at some places, its fraught with many problems which ought to be looked at as blockers as they could be resolvable, but which of course comes with a “BIG IF”:
(PS: We’ve all been here and back, haven’t we?)
1. Lack of research / Lack of immersion in research
If Engineering gets into doing research, it could lead to a pattern where they happen to stop at the first instance of some findings without penetrating the touchpoints. Also, the understanding built could be purely from a solution’s standpoint & not the problem’s standpoint.
2. Cognitive Bias
The fact Engineering believes in exactness & having ready answers to things, it could lead to some trouble over coping with cognitive biases induced while dealing with problems.
3. Thinking from engineering / solutioning standpoint
I know I’ve been guilty of it coming from a solution’s background myself when I started out as many of them out there would agree as well. The tendency & propensity to rush towards solutioning is so rich that it could lead to pondering deeply over architecture, data structures & robustness aiding optimal information retrievals when those user problems are heard first-up.
4. Lack of idea validation
The bias again is to proceed towards the next stage of solutioning when one ought to go into pretty deep immersive research & discovery over talking to the future / existing users and building an understanding of their pain points & the emotions / motivations behind them as well.
5. Lack of establishing a market need, building for no-one
Guilty & guilty as charge. Engineers could get so excited about stuff like cutting edge Tech being employed and that could easily overshadow the necessity to establish a market need before going ahead and building something.
6. Making decisions under total chaos
Many a times a PM’s workflow would be fraught a real mammoth complexity where there are tons of requests / demands for features which correlate to deeply validated issues in the user’s workflow but one can’t go ahead and build for all of them as the subtlety of requirements may vary sharply per persona per user group per customer as well in B2B which would mean a lot of tradeoffs, opportunity losses, churn leading to many degradation of important metrics.
7. Dealing with multi-level ambiguity
Ambiguity is embedded deep into a PM’s workflow as building for a market need that’s 90% would no doubt end up disappointing the 10% which could end up being a really large significant number to tackle.
8. Marketing and Sales could be weak points for eternity
Engineers may or may not have the propensity to deal with the marketing / sales teams interface as these demand a totally different skillset altogether. Marketing would require one to be totally creative and sales would need one to be very dynamic in capturing the user’s essence over his responses and alter the pitch dynamically to suit their needs. Both of them require a deep understanding of the user’s perspective and truckloads of empathy.
9. Customer Support could suffer
CS teams’ interface could work very well in the sense that Engineering could understand and be able to quickly pin on the exact part of the workflow that is leading to some friction when it comes to the UI. But, talking in the parlance of the UX it could suffer as it often involves a much wider scope.
10. Tons of Tech Debt to deal with
The whole modus operandi of Engineering approaching the problems from a solution’s standpoint could be a real big spoiler and it could lead to tons of Tech Debt as one would choose and build solutions with shorter time cycles as opposed to taking the longer route in terms of getting over to the user groups and researching / discovering the problem and its whereabouts.
Revisiting the Question
So, can engineering replace product teams?
If Engineers are to replace product people, they first ought to start off by thinking from a much higher and wider scope to start with, operating in one of the most uncomfortable places they could ever imagine stepping into – the problem space which could be totally devoid the whole clarity they are otherwise so used to operating with.
Not to mention the high agency that at time could demand highly accurate & well thought-out calls about the product / the market yet quick-off-the-blocks & razor-sharp decision making.