How do Jobs to Be Done, UX, and Product Management work together?
Some thoughts on UX and Product Management
Published April 14, 2021
Sunday, Jeff Gothelf linked to his article,"Do OKRs work with Jobs to Be Done". I like Jobs to Be Done (JTBD) and Objectives and Key Results (OKRs), so I was all-in. Then he posted a picture of a milkshake with a big straw to go with the link, and that’s where he sidetracked me. A big straw is the wrong kind of straw, and why it’s the wrong straw illustrates how Jobs to Be Done, UX, and Product Management work together.
(The milkshake photo is Photo 35598168 © Irenevandermeijs)
Product Management vs. UX
The difference between UX and Product Management has confused me ever since Product Management really exploded as a job title. When I read Product Management job descriptions, I think, “that's what I do, and I'm UX.” This isn’t the first time. I’ve been through this before. I was an IA, then they said what I did was UX or Content Strategy.
Call me whatever you want as long as you call me, amirite?
But I want to understand difference, so I know what teams might expect from me when I work with a Product Manager. Or, even more valuable, if you know the difference, it helps you focus on what jobs you should actually look for.
It confuses me (and others!) because UX and Product Management’s activities and responsibilities overlap with one another. Surprisingly, that big milkshake straw helps push aside some of the underbrush to reveal how UX and Product Management work together and why Jobs to Be Done reveal such critical information about your users.
Milkshakes and Monotony
Jeff’s photo references the famous milkshake in the seminal article about Jobs to Be Done by Clayton Christensen, "Marketing Malpractice The Cause and the Cure”. You might recognize Christensen from his highly recommended books on Innovation, The Innovator’s Dilemma and The Innovator’s Solution.
In that article, Christensen and his co-authors, Scott Cook, and Taddy Hall describe a researcher hired to research milkshakes. Sign me up, right? These are the researcher’s surprising results:
40% of all milk shakes were purchased in the early morning. Most often, these early-morning customers were alone; not buy anything else; and they consumed their shakes in their car…. Most bought it to do a similar job: They faced a long, boring commute and needed something to make the drive more interesting…. The milk shake, it turned out, did the job better than any [other food]. It took people 20 minutes to suck the viscous milk shake through the thin straw, addressing the boring commute problem.
— Harvard Business Review, December 2005
Now, I love milkshakes. They’re my comfort food on rough days and a celebratory treat when I have a big win. And I love big milkshake straws. They let you get to the milkshake pretty quick. It's not like milkshakes with thin straws where you really have to apply the suction to lure that first bit of milkshake into your mouth.
If you want to make the milkshake experience better, you’d think big straws would make milkshakes better because they make them easier to enjoy. Yet, that’s exactly the opposite of what commuters wanted in Christensen's story. They wanted to spend 20 minutes sucking a viscous milkshake through a thin straw.
All together, JTBD, UX, and Product Management
In that story, commuters wanted slow, difficult, orally interesting milkshakes. Big straws make milkshakes fast and easy to drink. This illustrates why the user’s mindset, the job that they hired the milkshake for, is so valuable to a product team. UX designs the system to align with the user’s goal. For fast milkshakes, UX designs big straws. For slow milkshakes, UX design thin straws.
This leads to where product management comes on stage.
Would bigger straws sell more milkshakes in the afternoon and evening?
Would bigger straws reduce the number of milkshakes you sell in the morning?
Would the increase in afternoon milkshake sales outweigh the decrease in the morning milkshake sales?
You can model those questions, but you really need a pilot in the field with real customers to evaluate them. Do you have the budget, time, and space at the top of the backlog to prototype and launch that kind of pilot?
Product Management answers those questions.
Research discovers why and what's important, the user’s Job to Be Done. Product Management decides whether or not to make that information a priority, and UX kneads that information into a system that fulfills product priorities and user goals.
Of course, research and UX and product management roles change from team to team. That's one reason why new team members seem a little slow out of the gate. New teams and team members have the same role confusion. No mater how well-defined you defined the roles, the new person isn’t 100% sure how your team actually does it.
Outcomes over outputs
That every team defines roles a little different highlights a counter-intuitive idea. The roles aren’t important. Your real goal is outcomes, not clear roles. Good teams hand activities and responsibilities off to one another. If you can’t cover something, someone else can take up the slack.
Those kinds of cross-functional teams and cross-functional team members leads teams to success. But here's the other crazy part.
Success isn't product success. Product success isn’t the outcome.
Success is a team that works well together, hands-off roles, and shares activities, the kinds of cross-functional teams and cross-functional team members that work well together, know how to talk to one another, understand one another, know what to expect from one another.
How UX and Product Management work together and use Jobs to Be Done, that's just a starting point. As you spend more time with your team, look for opportunities to learn skills from other functions. Not to master them, not to take them from someone else. It's not a zero sum game. But learn them, so your team works better together, overall.
Success is teams that work better together. Nail that, and product success follows on its own.
If you know someone this post would interest, share the link by email.
11 practical tools and 100s of tips from the trenches so agile, remote teams can build better products: Collaborative Product Design.
