Software Failures and Jobs To Be Done

For years we have heard what a dismal track record software development has. How most projects fail and in all of those conversations the blame falls on development, either directly or by implication. This is dead wrong. Software projects fail because software projects build the wrong thing. They build the wrong thing because someone comes up with stupid crap to build that doesn’t deliver on the real job it was hired to do. The “crap” is either based upon someone’s idea of what is needed, this idea is not data driven or user centric, the scope of the project is of some massive and complex scale and won’t be realized for months or years, and everything but the kitchen sink is piled onto the idea, all of which is either not described thoroughly or is over described and you can’t see the forest for the trees. How can software development succeed when the start of the development cycle begins with a load of “crap”. The project is doomed from the start.

Successful software begins with actually setting out to build the right thing and making sure that it is described in such a way that it is clearly understood by those who will construct it, and, that it is of the smallest scale possible that will result in a shippable, and testable iteration. In other words a very small step is clearly described and it has a real purpose and it has a measurable criteria to validate if it works. And once shipped the iteration is closely tested to determine if it achieved what it is supposed to, and the lessons learned from the iteration, whether successful or not, are applied to the next iteration. And so on, until the software is complete. Always learning, and getting better with each iteration made. Build, measure, learn.

How do you do this? How do you make sure that you are building what matters? Everything starts with a problem that we are hired to solve, a job that needs to be done. Something is needed to solve some problem that someone faces. And the problem is the source of the issue, the cause, not an effect. To get to the cause you have to continuously ask WHY? The Toyota 5 Why’s.

For example;

• I need new shoes. Why?
• My shoes are not comfortable. Why?
• My feet hurt after a couple of hours of walking. Why?
• All shoes hurt my feet after a couple of hours. Why?
• There must be something wrong with my feet. Why?
• I have a problem with my feet.

We could very easily have started out by saying that the problem to be solved is “I need new shoes.” But after digging further we discover that the reason I need new shoes is because my feet hurt, but, my feet hurt in all shoes that I wear, which finally leads to the problem to be solved of “I have a problem with my feet.” We almost bought new shoes and they would have never fixed the problem.

If that’s the problem to be solved how will we know that we succeeded in fixing that problem? How do we measure success?. It is very common to describe what we think needs to be done to fix a problem as the measure of success, which in this situation it could be “Get Orthotics from Doctor”. But this isn’t a measure of success. It is a task that we will do that we think will solve the problem. The true measure of success in this situation is that “a 2 hour walk doesn’t hurt my feet”.

At this point it is tempting to say that we’re done. We have a problem to solve, we put it through the five why’s and we know the root cause of the problem, we know how to validate it and we know what we must do to solve that problem. But… how badly could we screw this up if we try to solve this problem? Could we make it worse? What happens if we don’t solve it? Does solving the problem matter to us that much? Do we have bigger problems that we should be solving? And last, but definitely not least, what is it going to cost to solve this? Could I put those resources to better use elsewhere?

How badly could I screw this up? “I live in the arctic circle and the only medical professional available to me is a dentist, but she says she knows feet and we could try experimenting with a surgery she saw on a YouTube video.” I think we could really screw this up.

What happens if I don’t solve this problem? “Nothing really. I am really lazy and out of shape and it is rare that I go for a 2 hour walk and the only time my feet hurt is when I do that.”

What’s it going to cost? “Well I don’t have insurance and the YouTube surgery will cost $10,000. And now that I think of it, it might be better if I joined the arctic circle gym (they have a one month free trial) and saw a nutritionist (a neighbour next door who charges $25 per session) and lost some weight, I am 100lbs over-weight and in terrible shape, which now that I think further about this it could be the reason my feet hurt and in general why I feel terrible all of the time.”

Now here is where it gets interesting. We originally thought the problem was we needed new shoes, five why’s lead us to sore feet, and that we would visit a doctor and get them to fix it. But, further examination of the risks, benefits and costs clearly shows that we might have missed the root problem that even the five whys didn’t uncover. This circular analysis is what leads to true discovery of the underlying cause and motivations.

Problem > 5 Why’s > Validation > Risk Of Solving > What Happens If Not Solved > Cost, and back again we go until we get to the underlying problem or motivation. The true job to be done which is typically described as “When {situation}. I want to {motivation}. So I can {outcome}.”

When {I am walking}. I want to {be comfortable}. So I can {walk for two consecutive hours without pain}.

Given that our hypothesis is that we can solve this job to be done by getting in shape and losing weight and knowing that this is only a hypothesis we need to manage risk by taking small iterative steps and testing the hypothesis at each step to either discard it, or improve upon it. With this in mind the sub jobs to be done are:

When {the gym opens tomorrow I will meet with their Membership Director}. I want to {try a gym membership for one month}. So I can {see if I will stick with an exercise program for the entire month}.

When {I come home from work I will meet my neighbour the nutritionist}. I want to {get my first meal plan}. So I can {see if I have the discipline to stick with her prescribed diet for one week}.

When {I am at the gym every second day}. I want to {do cardio and free weights}. So that I {can improve my circulation, stamina and strength to comfortably walk a little further each week}.

When {I visit the nutritionist once per week}. I want to {review my food log to learn about what to eat and not eat}. So that I {lose five pounds per week}.

Each of the jobs to be done above are iterative. Each has an outcome to be achieved in a very short period of time with little to no catastrophic risk if it doesn’t work. And each iterative validation of the job gives us further data and experience to continue to define what needs to be done to achieve our overall goal of being able to walk comfortably for two hours. We aren’t going to start something and wait six months to see if it works. We are going to take very small steps towards our goal and measure and learn, then adjust, as we go.

Further, we can ask two more questions. Is the job that I am going to do over-serving? Am I throwing too much at the problem and risk lowering my return on investment as the law of diminishing returns has kicked in. Or worst, am I overly complicating the solution and risk losing the user because they can’t figure it out, or I have to charge more than it is worth to the user to cover the cost of my over indulgences and as such they can’t afford it. In this case our overweight test subject may have considered a job to be done of:

When {I come home from work I will meet my neighbour the nutritionist}. I want to {get signed up to have her personal chef prepare all of my meals}. So I {don’t have to prepare my healthy meals}.

The above job to be done would work but it would increase the cost of the weekly nutritionist from $25 by at least a factor of 10 or more, and very possibly our user would stop using the service because they will find they can’t afford it in time. We are over-serving. Pun intended. And at the very least we should start with just the nutritionist visit to see if that’s enough.

The second question we can ask is am I underserving? Our fictional user may have only considered the job to be done of going to the gym and never addressed the other side of the problem. The poor food choices he is making. And as we all know you can’t exercise your way out of a weight problem. So in this case we would be under-serving and as such the problem to be solved would never get solved and in time we will lose our user.

Given the above, let’s do the risk analysis on the jobs to be done once again:

How badly could we screw this up? “As long as I start exercising slowly and don’t do a fad diet of just eating celery there is no health risk.”

What happens if I don’t do this? “I could have a heart attack or give myself diabetes and I definitely won’t be able to walk comfortably.”

What’s it cost? “nothing for the free one month gym trial and then $100 per month after that and $25 for each nutrition session and I can stop at any time. All is well within my budget and I am not giving anything else up to do this.”

Are we over or under serving? It seems like we are doing just enough to get the job done and we will monitor our results as we go to make sure that this proves correct.

We started by going out to buy a pair of shoes that we thought would make us feel better. We ended up joining a gym and starting a nutrition program for about the cost of the shoes we were going to buy. And, along the way we avoided having a dentist operate on our feet.

This process is slow, tedious, and requires that you rip up what you thought was the ideal plan multiple times, but in the end, you have truly come up with meaningful work that is absolutely ready to be acted upon. All of this work happens before a single 0 and 1 are brought together to create the software that you think you need. This is how you build successful software. To many software projects are buying shoes or providing unqualified and expensive elective surgery.

Every software project that is undertaken must have a well thought out job to be done, that has been tested with five why’s, the risk of what could go wrong has been considered versus the tradeoff of not doing anything, the cost benefit analysis has been done and weighed against all other competing priorities, and we tested the jobs to be done to make sure that they are not under serving and as such will never solve the problem, or overserving, making the solution too complicated and expensive. And most importantly a quantifiable and measurable outcome for the software is known and stated and that software can be delivered in preferably weekly or less iterations and each iteration is tested and measured against that outcome, the results studied, and the lessons learned and applied to the next iteration.

And to further mitigate risk, no single task, or as we call them “card” within the project can take longer than two to three days before being delivered and validated. And, to make sure that every card is completely ready it should have a well defined job to be one ;“When {situation}. I want to {motivation}. So I can {outcome}.”, or at the very least, refer directly to a parent job to be done that described the situation, motivation and outcome and it can be used to validate this card when shipped.

That is how you have absolutely ready ready backlog for software development and that backlog is truly meaningful work that will deliver value to the end user who is hiring it to perform the job they need done. And… one last rule. You have at least two sprints of ready ready backlog that is good to go but no more than four sprints. Your team may just surprise you and kill two sprints in one and you have nothing in the queue and are scrambling. Why no more than four sprints? Because it is too much inventory and if you are learning from every card you ship you might, and should, change your mind often as to what comes next and how it should be done.

✔ Have a clear job to be done; When {situation}. I want to {motivation}. So I can {outcome}.

✔ 5 Why’s to discover the underlying problem and motivation.

✔ How badly could we screw this up? Can we deliver and validate in 3 day or less iterations?

✔ What happens if we don’t do it?

✔ What’s it cost?

✔ What’s the return on that cost?

✔ Are there better places to spend this money?

✔ Are we over serving?

✔ Are we under serving?