Only where product management is completely misunderstood can I comprehend why a CTO or any c-suite executive would utter the words, "It is luxury to have product management".
Unfortunately product management continues to be misunderstood and poorly positioned within many organisations. Too many technology leaders are confused by this role which is unfamiliar.
The pressure of delivering a product on schedule and to budget can overtake everything. Cost and time are familiar to the c-suite and easy to measure. Ignoring product management is a serious mistake that costs organisations big bucks. This also includes a trend I have noticed of giving project managers the job title 'product manager'!
To address this and support executives who are veering off course we need to go back to product management basics. What is Product Management? It's been said before (by Marty Cagen), but I will repeat it...
- Products job is to build the right thing.
- Engineers job is to build the thing right.
If product is a luxury, it is not needed (like cake), so let's imagine product development without product management... (Queue the dream like music)
Consider a typical enterprise b2b software project. Why b2b, because the b2c story is very short. B2C goes like this, after overrunning schedule and budget the product is released, It fails to deliver a suitable value proposition to the consumer. No one buys it, no one uses it even when it's given away. The product is killed (and in some cases so is the company).
So in the b2b space requirements find their way to an engineering team. They either come directly from the customer (could be internal), through a project manager who is nothing more than conduit or the engineers invented them.
The engineers eagerly design a solution, select the best technology and build a product. They might also be agile and share iteration progress with the customer (So far so good).
The solution reaches customers and the first feedback loop starts. The feedback will be problematic.
The first problem is a project manager asked users (or the user assigned as "product owner") to prioritise the most valuable features so they could be built first (an attempt to be smart and increase ROI). Engineering built their interpretation of these features. Those top features normally have to be connected by some kind of workflow. These "low priority" features were not built. The release is impossible to use in the users context.
The initial feedback gave no learnings around the core features and further development takes place so make the solution usable. At this point the scope of release one just doubled. The project manager is racing around putting expectation fires out and stakeholders have to commit to increased costs, schedule and risks.
This style of feedback continues as every feature slowly becomes "must have". As users start to be able to interact with the product they raise new issues which suggest they didn't really know what they needed in the first place. To avoid throwing away code and to achieve a "quick fix", a suite of configuration options is bolted onto features to better match the users business logic or workflow.
The engineering team begins to hate the "user" as they appear to constantly change their mind and regularly miss out important requirements- engineers curse, "don't they know what they want!?". (Typically in reality the answer is actually "no they don't")
As engineering morale gets worse pressure to finish the project increases. Staff are pulling long hours and working at weekends but the result is no one is happy! A few engineers are tempted away by the weekly recruitment calls they receive. Life gets worse for those that stay and the hiring process is a distraction for technical leads.
Eventually after tripling the projects costs and schedule the focus to ship this project becomes the single overwhelming self preservation focus for leadership, regardless of technical architecture or if the project delivers the intended value.
At this stage the corporate "Teflon" manoeuvres kick in to keep decision makers out of the firing line! For enterprise software analysts spring up and make wild assumptions to fuel reports of exaggerated cost efficiencies for those that use the software. Competitor analysis is carried out - not with the objective of learning from competitors good and bad features - instead to illustrate there is no one who solves the same problem as if to illustrate value through differentiation. The competitor analysis and efficiency analysis justifies the enormous over spend and exonerates leadership.
By this stage the installation for a new customer requires BAs, an engineer and takes at least a month or two to setup all the configurations. (Although it's still pitched as SaaS - ha ha)
The project is now two or three products horribly mutated together resulting in a disfigurement that make normal people cringe. Only those who have lived through creating the mutant are blind to its repulsive appearance.
Finally the solution is complete. Stakeholders & leadership cheer. In a few years when they all have new higher paid jobs based on this projects size and "success", the new leadership will embark on killing the monstrosity and we start again.
Through skilled salesmanship and uncertain buyers, companies will buy the solution. As soon as the employee that decided to buy the solution can replace it without loss of credibility they go to a competitor.
Does this sound familiar?
It is, unfortunately, a common scenario. If solid product management had existed from the very start this story would be very, very different.
Great product managers learn what the value proposition is, then through collaboration define what the right thing to build is.
Product management is not a luxury it is essential to success.
You have been warned!