X — Why do you insist on a « technical » product manager? Why not someone like me, always in touch with the customers, from the marketing or the sales department? Like all product managers from all other companies…
Me — And what do these « product managers » do?
X — Simple, they talk from time to time with customers and users then come back with a list of features to be implemented.
Me — And how do you choose which set of features gets to be implemented first?
X — Again, that’s quite straightforward: I would ask the technical team to put every feature in a 2x2 matrix. One axis would be « Easy / Difficult » to implement and the other would be « Very Valuable / Nice to Have » for the customer. The magic combo is making sure we’d do the « Easy / Very Valuable » first. And the rest if we have time.
Me — And where would you put the « Very Valuable » stuff for the team? Don’t you think it has something to say about the product while building it?
X — I’m pretty sure they could set aside some time for that kind of stuff. I’ve heard teams setting about 20% of their time to internal work: I wouldn’t have any kind of authority on those tasks, making sure they have enough freedom.
Me — And would you trust them on doing the right stuff for the long term good of the customers? Or the company?
X — Well, I guess it would depend on how much they know the actual users. For example, if they choose to work on the issues arriving through the support desk, that would be OK. I also heard another story where the technical team wanted to update their stack but the product manager insisted to get a big feature out: a few months later, the feature was indeed released and the team just skipped a release or two in their framework. The customer was happy, there was no harm involved.
Me — How much luck was involved?
X — What do you mean? They didn’t report any problem, as far as I know anyway.
Me — Skipping a version or two in a framework usually means some vulnerabilities weren’t patched for a while. So my best guess is the customer was probably under some security risk, at least for a while.
X — That would have been really unfortunate… I guess the team knew what it was doing.
Me — Let’s jump to another topic. Have you ever heard about the 737-max crashes? Boeing needed to have a bigger engine on the plane to competed with Airbus: the decision created a trade-off between a redesign for the plane (effectively long and painful) and a software patch (usually short and easy). But with a CEO without an aviation engineering background, the management team probably chose the « Very Valuable / Easy » combo: the engineers were silenced, the redesign shelved and the software outsourced to $9-an-hour engineers. And 346 people died.
X — You’re taking an extreme case: we’re not dealing with life and death decisions here.
Me — Alright then, here’s a second anecdote: I was visiting a company and during the gemba walk, I had the privilege of hearing two kaizen presentations. The first one by a sales person: she spoke fluently, with a large smile, happy to show off how well her team was performing. The second one by a tech guy: english wasn’t his first language and it showed, his presentation was choppy, punctuated by digressions and the poorly readable graphics didn’t help much. It was obvious he was struggling to get his points across. But everybody there knew how important he was to the local endeavours. Change the CEO and nine time out of ten, she’s first on the line to get a seat to the board.
X — So is avoiding costly mistakes the reason you insist on a technical leader for our product management?
Me — Not really, you could follow Marc Andreessen’s advice: « find the smartest technologist in the company and make them CEO. »
X — I guess it would be the inverse. And Apple would have been very different since Steve Jobs was not that technical.
Me — Actually he probably was one of the greatest Chief Engineer of all time: making opinions based decisions and explaining why, willing to articulate trade-offs and to share the vision, delaying data driven decisions. But more importantly capable of embodying the product. For example, should the iPhone screen be in plastic or in glass? Made of plastic, it would get a lot of little scratches inside your pocket. Made of glass, it would break badly when falling on the floor.
X — It’s obvious: glass should be chosen. And indeed it was.
Me — But in the late 2000s the Blackberry was loved by its users for its robustness and its rock solid keyboard. It was already made of street-proof plastic.
X — OK, maybe it wasn’t so obvious back then.
Me — The Chief Engineer holds the answer and the « why » would usually be found inside his concept paper or in his head. Every design decision can be traced there. He’s the guarantee the product holds true to its vision, from the design phase and all the way to the customer care phase. Including the production and marketing phases.
X — So « why » did Apple chose glass over plastic?
Me — They argued that putting a phone inside a pocket was a « normal » thing to do, so it would be their fault if a scratch would appear. But if you let your phone fall in the kitchen, it was obviously your fault: Apple had nothing to do with it.
X — But again, you’re arguing with an extreme case: we can’t all be Steve Jobs.
Me — Precisely. Chief Engineer is probably the most difficult position to fill inside a company. Usually the founder doubles up as the first Chief Engineer: it was certainly the case for me. There's no product and no company to start with so it boils down to my vision of the current landscape, the potential customers, the close competitors, etc. But fast forward ten years and I had to kill our second product when I realized I couldn't carry it forward to the marketing and sales phases, two years after we’d started working on it. I couldn't clone myself to create a second Chief Engineer.
X — But that was more than 4 years ago!
Me — Exactly: that’s when I started exploring what a Chief Engineer actually does when not the CEO. And then examining who could be our next Chief Engineer. It took three years of mentoring and teaching to get there. Finally Opentime (our time management SaaS product) got its new Chief Engineer and my best guess is I need about three more years to learn how to become a non-Chief Engineer CEO.
X — So what it's your plan then?
Me — I've read quite a few books on the subject over the years: Takao Sakai's The Secret behind the Success of Toyota and Cécile Roche and Luc Delamotte's Lean en Ingénierie have been quite influential for example. But since summer is here and summer means kids, next on my list is Hayao Miyazaki's The Wind Rises. It's the story of Jiro Horikoshi, one of the original Shusa - the name in Japanese for Chief Engineer - during the 1930s. Should be interesting to look at it with this perspective in mind!
