We have spent the last several years investing heavily in our software development process. Moving from Java to Javascript using frameworks like Angular and now React. We have been able to deploy new releases every minute rather than once per quarter like we had historically done, building out thousands of lines of code for automated testing, logging everything that our product does and tracking every last detail to know what our reliability is. And last but definitely not least, hiring UX designers and focusing on the user interface, but, despite all of this we were still not quite there. We kept building the wrong stuff, focussing on the wrong things, and not getting the results that we wanted.
This is when we realized that we had pretty much solved all of our software development issues and that we had an incredible engine for software creation, BUT, and it is a big BUT, we weren’t aiming it very well. We could build just about anything but we weren’t building what really mattered, or at least we were having a very hard time separating what mattered from what didn’t. We were missing an innovation strategy and we lacked a framework to guide our design thinking.
And then we discovered Jobs To Be Done. Before adopting this framework we were using a variety of strategies (often user stories), which left us with vague ideas of where to take our product and who are best customers were. When it came to decision-making, we were guided by our mission statement, which went more along the lines of this is what our product is, rather than this is why you want our product.
Jobs To Be Done has shifted our focus from our product to our user. Now, we are focused on identifying the problem, the job our customers are hiring us to do, and perfecting our solution to that job so that our users keep coming back. We are still in the implementation stages of this framework, but we thought we’d share how we have gone about introducing it.
Before we discovered Jobs To Be Done we defined our user and their motivations through user stories. But this framework came with many problems - it was vague, and we were making too many assumptions about our users with nothing backed by evidence.
To explain the flaws of a user story versus Jobs To Be Done framework, I would like to introduce you to Acme Inc.
Acme Inc. sells hair gel at an affordable $4.99 per tube and they believe their customers are people like John. Acme Inc. describes John as a man between the ages of 18- 25, and they have made the following assumptions about him: John likes nice cars, he doesn’t have much money, he recently moved out of his parent's house and he frequents coffee shops on weekends. They hypothesize that John buys Acme Inc. hair gel because it’s inexpensive and it does the job when he wants to gel his hair in the morning. From here on out they focus all their strategy on customers who match John’s description because he seems like their ideal market.
But Acme Inc. has just spent time, money, and resources defining John when 58 year old Joe, another user of Acme Inc. hair gel, buys the product for the same reason. And 11 year old Tony also buys this hair gel for those reasons. Even 14 year old Audrey buys Acme Inc. hair gel because it’s an inexpensive gel to use before dance competitions.
When they defined John as their “ideal” user, they limited all of their marketing and advertising to John, and sadly their sales to John. In reality, they have Joe, Tony and Audrey interested in Acme Inc. hair gel for the same reasons- it’s an affordable solution to their problem.
Jobs To Be Done tells us that Acme Inc. is being hired by their customers to gel their hair at an inexpensive price. But, when they used user stories to understand their market, Acme Inc was instead focused on defining their customer's attributes- their likes, dislikes, hobbies and experiences- when they should have been focused on the why. Why does John, along with all of their other customers hire Acme Inc. hair gel? What is the job they are being hired to do? And how can they make this job as simple, painless and appealing as possible for their customers?
At Rise, Jobs To Be Done has clarified the reason our users come to us and it has strengthened our decision-making process. We have begun to understand the job we are hired to do and we are using that information to guide decisions that will help us to deliver on it.
The Jobs To Be Done framework doesn’t tend to use persona’s, but at Rise, we’ve found that giving context to the job we are fulfilling has strengthened our understanding of both the job and the framework. That’s why we use Miranda. She is our fictional Flower Shop owner who lives in the city and she hires Rise Vision because she wants to engage customers in her shop.
Miranda came about during our days of user persona’s, and she never went away. But the thing about Miranda is she doesn’t come with a set of attributes. The only thing that defines her is the reason she uses Rise Vision. She embodies the job we believe we are being hired to do and reflects what the Jobs To Be Done framework means to us through her motivations. Miranda has helped to build empathy for our user. She has contextualized our users motivations, and so she has become a common language across all of our teams for understanding the Job To Be Done.
Now we are using Jobs To Be Done, along with Miranda, to define and to validate new potential projects. For every project we consider, we ask “If we do this, how does it improve our ability to execute the job we are being hired to do?”. If the answer to the question is “It does nothing to help” or “It causes a bigger problem” then we don’t touch it because it doesn’t strengthen our ability to deliver the job.
When outlining a project we specify The Problem To Be Solved and How We Measure Success. The Measure of Success is typically defined as one of our key performance indicators such as improvements in new user acquisition, retention, store sales, or cost reduction, etc. If solving the problem that the Job To Be Done requires isn’t expected to move a key performance indicator then it is very likely that this isn’t a high priority project and there are others that will have a bigger impact and should come first.
If the problem truly existed and we solved the job to be done in the right way then shortly after we ship the solution we should see the improvement that we defined for the key performance indicator that we went after. Every project goes through this validation to determine if it succeeded or failed and if it did fail, we didn’t move the key performance indicator needle, we then either define what we will do next to attempt to solve the problem one more time, or we may determine that we just can’t solve it right now and move on.
We have learned that we are what our users hire us to do, not what we think they should hire us to do. We have learned to commit to one job, to deliver on that job, and to do it really, really well. And last but not least, we have learned to simplify and focus only on the projects that will improve our ability to execute the job, because the rest will only drag us down.
Now, we are working on implementing the Jobs To Be Done framework across all of our teams, and perfecting the way we go about using it. We want to develop and grow our understanding of the job so that we can meet its demands at every end of the equation. We want to provide the best solution for the job that our users are hiring us to do.
