So you crowdsourced a bunch of job statements, now what?

Note: I use the terms “job stories” and “job statements” interchangeably.

Recently, I’ve been involved in a few workshops where people are brought together to generate a lot of job statements related to a particular topic. These are statements with the format

When ____, I want to _________ so I can _________.

This has been described as a great way to get stakeholders or subject matter experts to collaborate and be empathetic.

If that’s your goal, great, but these made-up statements have the potential to derail your product design activities, rather than help refine or focus them.

A few of the problems with this activity of “let’s brainstorm some job statements”:

1. The statements made up. The team is guessing at the motivations of others, which runs the risk of devolving into stereotypes or assumptions.
2. Whenever we brainstorm or generate options, we need to follow on with some means of validating or prioritizing what we’ve generated. It’s too easy to come up with job statements, so we can burn a lot of time trying to then whittle down our list. Better to focus generative activities on solutions, not problems.

This is not to say there is no place for job statements in the product design process. But the early discovery phase isn’t it.

Double diamond of design

In the discovery phase, you’re looking to gain insight into the problem. A job statement is too small a unit to be generating at this point. You risk generating too many possibilities. Instead, at this point I recommend focusing on designing a job map; the end-to-end map of what the user is trying to achieve. Then once you’ve agreed on the map, you can use job stories to describe what is important to the user along each step. This way, your job stories are anchored to something and you can more easily prioritize what to work on.

Refer to this blog post from MURAL to see how they align product development with jobs to be done at MURAL

A few years ago, I was a technical reviewer for The JTBD Playbook by former colleague Jim Kalbach. I was a bit surprised to come across this little excerpt in the book, because I don’t actually remember ever articulating job stories in this way. But I like it, and it definitely seems like something I’d say :-)

An excerpt from a book mentioning something I’d said before. Yes, I’m citing a book that cites me.

I have blogged before about how I believe the format of the need statement can really offer a lot of clarity and focus in product design.

In case you don’t want to leave this post to go off to another, the premise of the need statement is that all customer needs can be expressed as either “minimize the time to {do something}” or “minimize the risk of {something}”. We can focus our discovery research on identifying these needs within a specific context, and then refer back to these needs through the design process. We will be able to gauge if we’re improving the product by measuring against these needs statements.

One of the issues I’ve had with unstructured job statements is that we are only guessing at peoples’ motivations, plus there is the risk that what we include is very specific and can’t be generalized to create a solution for a broader group of users. If we ‘keep ourselves honest’ by sticking with customer needs that we’ve identified through research, then we can feel more confident that we’re solving for a real problem.

Once we restrict the “so I can” part of the statement, we have fewer variables to work with. Ideally, we know what circumstances we are designing for, so that also cuts down the number of job stories we’re creating.

Once we’re in agreement on

• the circumstances we’re designing for (the when), and
• how we will measure whether our solution is successful (the so I can)

NOW we can start to generate job stories. What are all the different ways we can try to solve the users’ problem?

Only working with a single variable at a time, we can actually compare possible solutions. We’re not trying to compare different solutions for different problems with different success metrics.

Then once we have a job story that includes one circumstance, one solution and one need, we can pass that statement off to the product team to work on the implementation.

In this way, a job story is a way to refine or define the work to be done, NOT a way to generate a bunch of possible ideas about ‘what could we do’?

So what do I do with the statements I generated before I read this?

It’s understandable if you don’t want to just throw away all the job statements you created.. I just caution you not to use them as a starting point. Instead, do research to first develop a job map, and then associate your job statements with steps on the map.

I do believe that if you’ve created unstructured job statements, their applicability may be a little limited. Like any data project, you may need to spend some time normalizing the data so it can be understood and applied. For example, if you have agreed on a handful of circumstances you’re designing for (i.e. new to the product, new to the field, or experiencing a new life event), then any job statements that have been created with other circumstances in mind won’t “fit”. In that case, I encourage you to put those statements to the side. In a world of limited time, resources, and users’ cognitive abilities, we can’t try to solve every problem or optimize for every circumstance.

If you can be disciplined in your creation of job stories, you’ll have much more confidence that you’re focusing on the right problems to solve for your users. Hopefully, that’s the reason you’re doing this work, not just to do a fun activity with stakeholders, right??

But wait! How else could we involve stakeholders if not this?

Glad you asked! I’ve engaged stakeholders by walking them through a job map and asking them to generate statements within the constrained form. Or I’ve asked them to vote on what they think are the most critical needs to be solved. We definitely want to engage stakeholders, but in a way that we can be confident their input can be acted upon. Adding a little structure to the engagement can help everyone feel like the activity is valuable and helping the project move forward.