Those who work with me are, I’m sure, quite sick of me saying the phrase “jobs to be done”. At first they give me a quizzical look, as if I am talking about some unspoken to-do list. But whenever you are developing new or improved products it is the central question around which all others revolve.
Horace Dediu explains it succinctly like this:
The reason a product deserves to exist is that it can do a job that needs doing and that few, if any others can also do it.
Unfortunately, the question of the “job to be done” is strangely absent from pretty much all the product development teams and I.T. leadership discussions I have been privy to. So much of the talk about Lean and Agile seems to be about getting stuff faster, or cheaper, or with less risk. Rarely is it about whether the “stuff” we are building faster is the right stuff. The sad truth is that market risk is by far the greatest risk in product development: That you build something, but it has no value to anyone. We tend to be so focused on solutions we tend to forget the words of Theodore Levitt:
“People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
Benjamin Mitchell tells some great stories from his time working for a global financial services company. I sat next to Benjamin at a conference dinner in 2010, and he shared with me the immense frustration he had with senior managers that seemed to ignore this completely. His team were beavering away, improving both the product and how the team worked, to the point where they were quickly delivering the features they were asked to deliver. The problem he was trying to highlight was that only a very small number of customers were actually using the things they were developing. No one seemed to want to hear this, ignoring the need for double-loop learning: Just deliver what we ask for and don’t question it.
In Product Development, value trumps flow, and flow trumps waste elimination. It is pointless to talk about speed or efficiency unless you have at least an equal focus on whether the end result will be of any value. John Seddon highlights this as one of the key risks of Agile when applied to I.T. and asks the question “Is Agile doing the wrong thing faster?”. He goes on to say “So often, because the real problems are not understood, agile techniques are employed to speed up doing the wrong things. Where this is the case, agile’s features are not benefits.” Because Seddon works predominantly in services, he perhaps oversimplifies a little by suggesting the real problems can in fact be understood in advance. If you replace “real problems” above with “job to be done” you get closer to the complexity of product development and the real challenge with the whole concept of jobs-to-be-done. The “double-loop learning” that tells you whether the goal itself is correct was missing.
The truth is, for innovative products we cannot determine the right thing in advance — we have to grope around in the dark, hoping to find a light switch that will shed some light on the subject. As Dediu explains, the job to be done is usually “unstated and difficult to percieve”, which makes the way forward uncertain. “..the difficulty behind jobs-to-be-done based design is that jobs are never plainly evident”.
What makes this even more challenging is that the situation we find ourselves in with product development is distinctly different to many of the problems we are trained to solve as we navigate our way through school, university and even our first few years in the workforce. We are very well trained and rewarded when we select the one best answer, and success typically goes to those who can present and defend that answer as best they can. But this approach is simply wrong in the complex world of innovation.
Again, Horace:
In contradiction to invention, where the problem being solved must be as clearly stated as its solution, value-creating innovation meets new and unarticulated needs. Even when created, the value is more subtly perceived, often only after prolonged use.
Being only obvious after the fact is one of the hallmarks of a Black Swan event. It turns out that Black Swan farming requires a different culture, a different way of working and a different mindset.