Product Development Methodology #JTBD

There are various effective theories and methodologies for efficiently performing the implementation part of software development. This is…

There are various effective theories and methodologies for efficiently performing the implementation part of software development. This is the part where the features are already known and agreed upon and need to be implemented. Within this implementation microcosm, there are breakdowns, but these are usually management issues that are solvable by following the process de jour. Not so when it comes to product design. To this day, most companies view this as dark art and have a problem doing this on a systematic basis.

Over the last few years, based on empirical observations, I began to evaluate how product development is done in the places I've seen. The lifecycle must be fluid to succeed, but in most environments I've worked, the lifecycle was cracked in various places with a big water main break looming in the intersection of product design and implementation. Sometimes the cracks are small enough that the product still somewhat succeeds, but that success is mostly constrained. The water main break though must be fixed if the product is to have a better chance of successful growth.

The breakdown dilemma deals with product design intersection with implementation. How does one go about knowing what product to build, what features to include, who are the customers and who aren’t, what should we focus on first? Great implementation is important, but implementing something that isn't going to succeed is a failure of greater proportions if it can be avoided. Traditionally the methods for product development were more adhoc rather than based on sound theory. Some people have better intuition about these sort of things, just like some people are better artists than others. Unfortunately it’s hard to gauge this type of skill and hard to succeed using it on an organizational level. Without a sound reproducible theory backing product development, as more people get involved, the results are often futile.

Good marketers have for ages worked with consumer behavior psychologists to define the most effective marketing campaigns. Good programmers employ sounds computer science principles and engineering practices. What should good product designers do? I’m not saying we need to formalize it and take away from its creativity. Marketing is just creative of an endeavor, but more effective with the use of psychology. Software development is as much art as it is science, but the knowledge of computer science and engineering principles allow for better software. Product design is art, but business and consumer products aren't designed for the sole purpose of demonstrating artistic abilities, rather they have a purpose to fulfill a need in a customer’s life. In order for that customer to engage the product, we need to understand the causal mechanism in play that allow the user to employ the product. The mechanisms in play are functional as much as they are social and emotional.

One methodology that has firm academic and practical principles is the Jobs To Be Done framework. This framework grew out of Clay Christenson’s work detailed in the books Innovator’s Dilemma and Innovator’s Solution. I encourage anyone that cares about product development from any angle to read the books. I’m rather convinced that this is the methodology that product development teams everywhere should employ. It will not only help them create more commercially successful products, but also better understand the products they are building and how they are employed in people’s lives.

The methodology is grounded in the theory that people have jobs in their lives that they are looking to get done. These jobs aren't new, so you don’t introduce a new job into someone’s life, rather you displace or enhance what they are currently using to fulfill that role. This metaphor allows one to look at product development from a completely different dimension. You no longer build features based on verbatim customer requests, you no longer add things because it seems like they enhance the product, rather you question everything using a rather standard interviewing method that allows you to develop a causality model. In some cases you dispose of features or never develop them, in others you realize a product/feature that will truly fulfill a role in getting the job done. This feature might completely diverge from what was initially thought by the customer or others to be the solution to their need. What you really want is to get a deep understanding of the actual need and getting to the bottom of it is what JTBD is all about.

I recently returned from a one day workshop hosted by Bob Moesta and Chris Spiek of the Rewired Group. The workshop teaches how to apply the interviews part of the JTBD methodology. I strongly recommend the workshop to anyone doing product development in any capacity.