Customer value or career value?
We all believe product development should deliver customer value. But how do we judge if a company is doing a good job? The ratio of the share price in relation to an appropriate stock index is a reasonable reflection of the performance. Share prices are linked to growth and profit and, as R&D efforts (product development) can be seen as an investment in future growth or profit, it makes sense to calculate the ratio profit over R&D expenses – the so-called return on research capital. When we link RORC to the development of the first ratio, we get a feel for the performance of our product development. My own research shows that there’s a strong correlation between the two ratios: a high RORC is associated with outperforming the market and vice versa. Leading tech companies such as Apple, Google and ASML all have a RORC above 2.
Products are developed to create value for different customers. The worst use of our scarce R&D resources is bespoke engineering for one of maybe a few customers. To meet the above benchmark when you sell R&D engineering hours, you must make a 200-euro profit for each 100 euros for each hour – very few customers will accept such a price. Often, there’s just not enough room in the entire value chain to allow for wide duplication of R&D efforts and charge the customer for that.
Oddly, this value chain argument is hardly used in make-or-buy decisions; there, it’s typically all about efficiency or competencies. Few stop to ask whether the market is really prepared to pay for yet another navigation stack, for example. Is there enough customer value in a proprietary on-board automation system for vessels? Or even worse: is the customer prepared to pay for a proprietary development environment, with dedicated processes and tools? Recently, an IT manager explained to me, the operation became much smoother when they didn’t tailor the IT solution to the process but rather took a standard process with a standard IT solution, allowing them to focus on real customer value.
This all seems so obvious, and it makes you wonder why companies so often duplicate efforts and spend a huge amount of money on developing their own tools and process standards. As if teams can’t decide for themselves how to best deliver customer value. If they can’t, managers should work on that rather than compensating through a rigid set of procedures and dashboards full of KPIs, which often kill motivation and the highly desired team ownership.
In many of the cases I studied, the answer lay with the manager: just as engineers like to (re)invent stuff, managers desperately try to prove they have added value in the organization and create an illusion that they are in control and therefore can’t be made redundant. There’s even a new Dutch industry standard (NEN NPR5333) to help managers define their dashboard to support that illusion.
In hindsight, I made that same mistake many times in my career. For example, I was, and still am, a strong believer in quality and its positive impact on productivity. I also strongly believe in the value of static code analysis to improve quality. But instead of letting the teams decide on the best analysis tool, I’ve been rather sensitive to product features like a management dashboard or ease of adaptability to a company process. Why not just trust the teams that they can do a good job and let them select the tools they need?
Without that standardization and organization-wide KPIs, I had to find other ways to prove my added value, as just creating the conditions for success is often not recognized by top management as a valuable contribution. Or, as McKinsey expressed in a recent article, facilitative leadership may be best for the people and their performance, but it’s often not the best for a manager’s career. Dashboards and process standardization may not generate customer value, but at least they create career value! That’s a big market for these toolmakers and standardization bodies to go chase.
