It is unclear how I haven't heard about this before. I came upon it by chance, because I was contacted about a job in Australia who are using JBDT methodology. Am not applying for the job, but wondered, what is this JBDT?
What is Jobs To Be Done?
I am not going to give a long history about it as there is enough about this online. The first thing to recognise, is JBDT is a trick, a very useful trick in re-framing what needs to be achieved. I can explain it as, being able to explain a need without getting technical.
- Expected Outcome.
The key, is understanding what somebody really wants. As a company, we tend to imagine users want improvements on what we build. Instead if we focused on what problem they are trying to solve, there may be an entirely different way of solving their problem. A good example I read was;
Customer just wants their grass to be short.
- Lawnmower company A thinks adding a new cutting mode to their latest range of lawnmowers will increase sales.
- Company A sells to the customer, all the features their lawnmower has.
- Lawnmower company B two builds a robotic lawnmower that runs several hours a day and keeps the grass short.
- Company B tells the customer they can keep their grass short with minimal effort.
A second example I read.
"A customer doesn't want a better drill, he just wants a 1/4 inch hole."
What makes JBDT so useful compared to other methodologies?
Why does JBDT outperform other approaches? It removes all of the technical jargon from the requirements. Rather than trying to talk in terms of features, or the user story leading up to the outcome - it focuses on the outcome first and why it is needed.
This post isn't about Agile and in particular Agile Scrum, but Agile has never sat well with me. Agile Scrum adds all this process, makes the user king, when perhaps we should be focusing more about outcomes. Agile always focuses upon features rather than just getting stuff done. There doesn't seem to be an end point, no commitment to costs, and too many people involved in the project who aren't doers.
A lack of formalisation
One of the best things about JBDT is you understand the concepts, you then decide how to implement JBDT. In many ways, this is exactly what Agile should be about. Agile Scrum as a mechanism to train people to work more effectively is perfectly valid, but to be enslaved to doing it correctly is a nonsense.
Goodhart's law -"When a measure becomes a target, it ceases to be a good measure."
Examples on how technologists can use Jobs to be done
Thinking about software engineering
A key frustration with software - building applications with data, is just how hard it is and yet, how tricks attempt to make it sound easy. Agile Scrum breaking tasks into smaller tasks to apparently make development easier and more manageable. Iterative development, just lets you keep adding functionality as required. Waterfall methodology is optimal for delivering exactly what is required.
Whilst all of these paradigms are valid, they miss a key point - sometimes writing solutions is really hard. Some problems are hard to solve, and require great concentration, planning and thinking. There will be trial and error, testing won't go perfectly, bugs will sneak through.
This is what I have found throughout my career, and will present some examples of where things are mostly true but sometimes false;
|Breaking requirements into smaller tasks makes development manageable and easier.
||Breaking tasks down to really small tasks can make the code unmanageable and hard to understand. Sometimes code is just complex and that is it.
|Development is about releasing small bits of code incrementally to phase in development.
||Often, one person working on a large piece of functionality start to end is more effective than splitting it up into tasks. There is a risk of a lack of knowledge transfer, but who needs to know about something that just works?
|Creating a feature list and small user stories makes it easier to build a quality application.
||A lot of times, the person defining the requirements cannot keep an accurate mental map of all the interactions. This can lead to a lot of wasted development and testing time and rework.
|Having a team of developers with similar skills is better than a team of differing skills.
||A developer with an advanced skill in one technology, may be able to deliver functionality ten times faster than the average developer of another technology. A great example is a development team who can develop in Microsoft Excel or a developer who can build SSRS Reports.
So, we find ourselves operating within a world where everything is easy, everything can be managed, but my experience is - it can't. Detractors may say, "ah but we deliver roughly on time", to that we can say - "but how much better could you have delivered?"
Jobs to Be Done is not prescriptive
What opened my eyes to JBDT was when I started thinking about my property platform I have been building for findigl. This platform is very close to being a working product with real data being published to it. The amount of work undertaken has been huge, and the vast majority of the work has been (strangely enough) along the lines of JBDT without realising it.
Here is an example;
- I want an application to compress downloaded files and archive that folder incrementally.
- Are there any applications that does this in the way I want?
- Can some libraries be adapted to what is needed?
- Will have to build a fairly small application to be reused within my platform.
- I want to increase business and footfall to my company.
- Most of my company's presence is on websites.
- Does paying for SEO guarantee this? Seems a bit hit and miss.
- Does social media help? Hasn't seemed to.
- Does backlinking work - seems to, but will take time?
- How does other successful software companies achieve success? They have referral programs. Apparently referral programs have a 25% success rate on referrals.
- Are there referral programs which are cheap, can guarantee GDPR and integrate mailing effectively? No - they seem to cost between £10,000 and £40,000 a year in licensing fees for something I could build myself in a week or so.
We can revisit the above and say - do users want to use a website at all? This is a profound question, and not one this phase can answer - but this is where JBDT wins, step back completely.
So it seems, that whilst I wasn't following JBDT, by thinking about outcomes, and not caring too much about the way to get there, you are already on the right path. JBDT is not prescriptive - nobody is going to beat you over the head and say "It wasn't really Agile".
Making sense of your platform with JBDT
At the end of this year, I have a lot of applications, there is a data warehouse ready to deliver awesome reports but just in the nick of time - JBDT was to the rescue. Some examples;
Now, we could argue whether these are genuine jobs to be done - but, whenever we go to a website, we make quick judgements on whether it can help us.
Despite all the technology and complexity of the platform. It has been possible to reduce most of the core requirements to around 20 outcomes. Now, when I think about those 20 outcomes - I can reduce complexity to; do I need a data warehouse right now, can some data get published in a simple form to satisfy some of those outcomes, how does users want to find information?
JBDT facilitates conversations without technical detail
Another major stumbling block when talking to non-technical people is you go down this rabbit hole of talking technically to users. Personally, I think users should educate themselves on technology a bit but anyway. By focusing purely on the situation, motivation and expected outcome that sign-off criteria is only when the outcome has been satisfied.
The example of looking for a house, understanding all the costs, so the buyer knows they can afford it can be approached in many different ways - but the outcome is what matters.
Avoid focusing on the users
One criticism of user stories and personas, considerable fluff is added to the requirement definition. Suddenly we are targeting men of between 30-40 who happen to drive a white Mondeo. This is a major area where Agile fails, because it makes individuals too powerful because of attributes. In Enterprises, we overly care about how a particular person does their job - then they leave and the whole feature set changes.
My mind is made up - JBDT is the way forwards
For whatever reason, Quora brings up umpteen questions for me to answer on Agile. There are always these Agile zealots, and invariably I set them straight. Well, no I don't - they think Agile is the best thing ever. Questions like - Agile vs waterfall, Am I agile enough, why is agile so much better than waterfall? Friends of my mine who were developers have said to me, they want to leave their job because the company isn't doing agile.
There are people who say - "Oooh, it shouldn't matter about the methodologies, good developers overcome methodologies." Why? Why should anybody knowingly make people's jobs harder just to adhere to a methodology?
So, am putting this post online so people who are wondering about whether a world outside Agile exists have some point of reference.