Four Good Reasons to Use Jobs to Be Done
Stephen Wunker shares an article that explains why Jobs to Be Done improves agile development.
Agile development has become the norm in software, yet it often overlooks a key challenge – how to objectively prioritize product roadmaps. Without this, the results of agile sprints can focus on the wrong features, developed for the wrong users, and executed in the wrong way. That’s a tremendously expensive waste.
Perhaps worse, firms prioritize product roadmaps using fuzzily-defined and often politicized methods which take considerable time and lead to development efforts spread thinly across use cases rather than in a concerted manner which satisfies key users in a complete fashion.
There is a better way. Jobs to be Done, developed by my mentor Clayton Christensen at Harvard Business School, creates strategic focus and coherent execution. Jobs to be Done is a method to understand what people are fundamentally trying to accomplish, rather than looking only at what they say they want, what they use today, and what pain points they’re experiencing in their current user journeys.
Jobs to be Done creates the needed focus in a way that avoids lock-in to features, so it is a natural fit with agile development. Here are four reasons why you should use it and four ways how:
Reason 1: Jobs to be Done creates a clean link between personas and use cases to features
Tech firms typically root product development in targeting personas and use cases for their products. That’s sensible, but jumping from those right into feature prioritization misses a key step. You have to know what these individuals are trying to get done in their use case context, on both a functional and emotional level. By embedding Jobs within the Jobs Atlas, you get a full sense of what features must accomplish, in what contexts, at what point of a journey, and in what ways to generate rapid user adoption.
Reason 2: Jobs enables prioritization of features while maintaining flexibility about how to execute them
A key principle of agile development is to maintain flexibility. Customer research is sometimes avoided because of fear that it will create undue lock-in to concepts. The Jobs methodology avoids these issues. By prioritizing Jobs to be Done, rather than features per se, you can keep the focus firmly on the customer, and you can stay flexible about how you execute on key Jobs. As you debate features and the UX around them, you can set them within the appropriate Jobs context and have a clear measure of what will and won’t constitute successful accomplishment of the focal Job.
Key points include:
- Maintaining flexibility
- Sidestepping major obstacles
- Speed up the development process
Read the full article, Prioritize Software Product Roadmaps Using Jobs To Be Done: Four Reasons Why And Four Steps How, on NewMarketsAdvisors.com.
