The title and inspiration of this blog comes from Chapter 1 of John Bogle’s book “Enough: True Measures of Money, Business and Life”, in which Bogle argues that the financial sector today costs too much and delivers too little value. He quotes the following “old epigram from 19th Century Great Britain”:
- Some men wrest a living from nature and with their hands; this is called work
- Some men wrest a living from those who wrest a living from nature and with their hands; this is called trade
- Some men wrest a living from those that wrest a living from those who wrest a living from nature and with their hands; this is called finance.
Bogle, however, isn’t calling for an end to trade or even finance. These things add clear value to an economy to the point of being indispensible in reality. The undeniable facts however according to Bogle are that “The more the financial system takes, the less the investor makes” and Bogle also concludes that in today’s financial industry norms “The investor feeds at the bottom of what is today a tremendously costly food chain”.
In software product development too it often feels as if we are part of a long food chain that only maybe ultimately leads to something of value to someone. In line with Bogle’ s thoughts on the financial sector, therefore, the directive for IT is clear – that we need at all times to focus on maximising customer value.
A pretty good start therefore is ensuring that we do adopt agile principles including in particular the number one principle underlying the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. Likewise lean thinking guides us that anything that doesn’t add value to the product is waste (muda) and to focus on eliminating all unnecessary waste.
But most important of all is to make sure that we know who the real end customer is and to make sure that we are actually delivering real value to them.
This means tracing our way along the links in the value food-chain. The real customer isn’t the IT Project Manager, or even the Programme Manager. It isn’t the Operations Manager that to whom will be delivering the software. And it isn’t the IT Director that all these people report to. It is the man in the shop, on the internet or on the shop-floor that is using our software to produce or do something of real utility or value to them.
To this end Scrum, for example, encourages us to organize ourselves such that the chain to customer value is short-circuited as far as possible. Reduced to its simplest form, this is sometimes characterized as “getting a product owner and producing what they tell you to produce”.
In the simplest case this simplest of solutions works fine. But life is very rarely that simple. What if our product owner is the not the right (or the only person) to ask? What if they are telling us what they think they want, without understanding what they really need? Are they appraised of all the facts – e.g. what they could easily have versus what is a lot harder or maybe even impossible? What if we’re investing in the wrong product / product lines?
The customer is always right.
The customer is always right.
This doesn’t mean assuming we, the delivery team, know better than the customer EVER. In this sense the maxim that “the customer is always right” should be our guiding credo. But then again, customers are human, and therefore unlikely to be always right about anything.
So what all this does mean is that we need to invest some proportionate amount of effort into making sure that:
- We are investing the right products / product lines (by managing our scarce resources across our investment opportunities)
- We are talking to all the right people to figure out what is really needed
- We are engaging with these people proactively to collaboratively drive out what is really needed (as opposed to what one fallible human being thinks is best for everyone)
- We are investing in a managed way in investigating solution options so that the right product technologies are applied
- We collaborate to ensure that the right features are invested in based on a combined understanding of the relative value and cost of these features.
In conclusion therefore, the key to ensuring that we don’t suffer from “too much cost, not enough value” has to be to major on ensuring that we are at all times focused on delivering customer value. This is not always as simple as appointing a product owner, asking them what value they want us to deliver and then delivering it. It is usually a much more complex endeavour which requires investment in activities to find the real customer, establish the value and manage our scarce resources in such a way that we are focused as far as possible on delivering the right kind of value to the right kinds of customers.