linkedin tracking
icon-sprite Created with Sketch.
Skip to main content
Rapid Product Design in the Real World With Jobs To Be Done July 25, 2014
Design

Rapid Product Design in the Real World With Jobs To Be Done

reading time
Cantina logo

Written by

Share this article

This presentation was delivered to the finalists of MassChallenge to help them think through rapid iterations of their products and to introduce them to the concepts related to job stories.

We incorporated quite a few case studies of projects that we’ve participated in at Cantina, but have not included those here as it would be difficult to include those in a way that easily understood via blog post:

The concept of the Lean Startup has been around for a while now. The idea is simple. You start with building. Launch. Measure the success of your product. Finally, learn from the data to refine your product. Follow this process and then rinse and repeat your way to success.

In the real world, it is not as easy as it seems. Lean does help you ship your product faster. It helps you fail gracefully. Lean can also help can also help you ship quality code if you start with best practices around automated testing, deployment, and coding standards.

The rush to iterate and ship has the side effect of leaving users, their motivations and desires by the wayside as the team hurries through the cycles to get stuff out. This helps you fail early and fast, but by ignoring user’s true motivations for hiring your product you won’t be failing gracefully.

Where Lean Works

Lean works best in development teams that are laser-focused on shipping a quality product. They have the discipline to maintain their coding standards and best practices throughout the project. They possess a strong vision of the product and have a deep understanding of their core audiences.

Teams that are most successful in adopting Lean are typically small. This doesn’t mean that they only exist within startups. Smaller organizations within the Enterprise that possess some level of autonomy are just as capable of pulling off a successful Lean methodology as any startup organization out there. They just need some freedom to work through the initial speed bumps that may occur and pivot as the data and audience feedback dictate.

Lean works best in development teams that are laser focused on shipping a quality product.

Where Lean Fails

Lean falls flat on its ass when the team lacks the disciplined standards that are required of fast-moving projects. These teams will be quickly mired by the technical debt they create.

Lean also falls down when the team isn’t focused on getting their product to market to get validated by their core audience. This lack of focus typically leads to lack of overall vision for the product. This quickly allows products to become a convoluted potpourri of half-assed features that customers will quickly abandon or ignore all together.

These are challenges that are fairly easily fixed with trust falls and other team building exercises - or simply getting the team on the same page with regard to vision and standards.

The most complex failing in Lean is through the lack of knowledge about users.

Lean falls down when the team isn’t focused on getting their product to market to get validated by their core audience.

Users

Your product has an audience, or it should once you launch. Customers that choose to hire your product to complete a job for them are motivated in some way. Your challenge is to figure out what that is.

In my case it’s BBQ. I will buy your product if you give me good BBQ.

You should be able to tell your audience what problem it is that your product is solving and how you solve it better than anyone else. This one simple thing is the thing that you should focus on, and it should be the thing that you ship. We like to call it your “kernel”.

When mapping out your product, you’re probably going through the process of creating personas. In the startup world, those personas may be a bulleted list on the back of a napkin from the bar, but needless to say every user story is tainted by the concept of personas.

Personas are divorced from reality and ignore the true contexts and motivations that will turn window shoppers into customers. Traditional user stories incorporate these personas into sentences that look something like such:

As a {PERSONA}, I want to {ACTION}, so that {OUTCOME}.

The persona is the villain in this story. It clouds us from discovering the true needs of your customers.

You should be able to tell your audience what problem it is that your product is solving and how you solve it better than anyone else.

Enter #JTBD

At Cantina, we’ve begun adopting the concepts of job stories more often. Job stories allow us to map the motivations of customers into discrete stories. We are able to utilize data that is discovered during user research and interviews to determine how to best innovate on ideas.

The job story looks very similar to the user stories that we are all used to. It looks something like this:

When {context/motivation}, I want to {job}, so I can {result}.

The assumptions associated with the persona have been removed and we can now focus on the core job to be done. From here we can plan out our apps to provide the solutions that customers need.

Job stories belongs to a experience design methodology called Jobs to Be Done. Jobs to Be Done is a process through which you collect data on your core audience, begin to formulate questions for that audience and then interview them.

If you listen to some interviews - the mattress interview being the “famous” one - you will see that the interview is almost a friendly police interrogation. These interview can often be done by anthropologists. Since most startups aren’t running out to hire anthropologists, this set of skills that allows you to ask very detailed questions about your customers, and potential customers, motivation must be developed internally.

Job stories allow us to map the motivations of customers into discrete stories.

JTBD + Lean

Jobs to be Done fits nicely into the lean process. It can be used in the context of the learn phase of Lean to get to know users. It’s a helpful tool to begin to solve the kernel problem that is central to your app, and it can help to focus the team on the goal of solving that problem for your customers.

Insights

Contact us

Talk with our experts today

Tell us how you need help. We’ll be in touch.

Thank you! Your message has been sent!

We’ll be in touch.

Want to know more about Cantina? Check out our latest insights or join us at one of our upcoming events.