Defining The Problem: Using Data And Insights For Upfront Product Success

Richard Maraschi at UXDX Europe. Video: https://youtu.be/lWU9mEBex7g

Readable transcript: edited from the recording's captions for readability (fillers and false starts removed, punctuation and section headings added). Wording is the speaker's own. Timestamps are positions in the video. Names marked [?] could not be verified against the audio.

Why jobs to be done

[00:00:05] Host: Okay, great. We've got a lot of people in the audience, obviously, who work on products and spend a lot of time really focused on how they can build features and new technologies into their products. Jobs to be done is a little bit different, because it focuses teams (product teams, and marketing and sales teams) on the customer's job. Since you have a lot of experience with it, my first question is: what interested you, as a product executive, in jobs to be done?

[00:00:36] Richard: I think there were a few things, Jay. First, when we think about jobs to be done, if anybody is familiar with it, it's a needs-first methodology. I know that seems very obvious, but a lot of times when you're doing customer research and trying to understand customers, you'll look into things like psychographics or life stage or lifestyle. These can become important variables when you're considering your design and the implementation of your product, but you really need to start with the customer problem first. Jobs to be done breaks it down with high fidelity into 60 or 80 needs, and those actually become variables you can use. So that's the first thing.

[00:01:17] Richard: Secondly, what I really liked about it is that it's highly actionable. One of the other challenges with customer research is that you might get an output, but then you take a need to your dev team, and if you describe a psychographic need or a lifestyle need, the dev team is like, "Okay, what do I do with that?" Jobs to be done really seeks to get highly functional and prescriptive around those needs, so you actually can action against it, and teams can say, "Okay, now I understand how to develop a solution to that very specific problem."

[00:01:55] Richard: And the third thing is that it's a methodology, and methodologies live on. They are applications of theory that you can iterate and improve on. A lot of times customer research ends up as a PowerPoint, these days in a Dropbox or OneDrive somewhere, and it never really gets used. It's really a reference document. Jobs to be done is something that integrates UX, dev and product teams together, and it really becomes part of the culture. I think that is probably the thing that attracted me most to it.

Contrasting jobs to be done with other methods

[00:02:29] Host: That's great. Since you've had a long career as a product executive, how would you contrast the jobs to be done methodology with other methods?

[00:02:39] Richard: Other methods that I've tried, or that were mentioned before, are traditional second-party or third-party research, where you hire a really smart market research company. Maybe they have some sociologists who do ethnographic, living-in-the-wild research on how users are trying to execute a job, and then they hire the stats people to do some quant. The other method is studying it internally. We talked before about measuring the product experience and looking at customer effort. So there's the internal way to do it, and then there's hiring third parties.

[00:03:15] Richard: They're very good methods to use, but the advantage jobs to be done brings is, first of all, that you're integrating your team. Your team is actually working on structuring the needs, scoring the needs, and then seeing how your product maps to those needs, how you're scoring. If you're familiar with needs, they're very much described around how quickly and how accurately you can solve that need with your product for that customer. There's risk with third parties, even though they're super smart and come up with really good insights, that either your team is not bought into it or something gets missed. Because who knows the problems we're trying to solve better than the people who are focused on them, which is us? So the methodology actually integrates your team, and I think that's probably the biggest advantage.

[00:04:17] Richard: The second big advantage, when you're comparing it to internal research, relates to one of my favorite double-meaning mantras, which I always say to my product teams: the solution is not the problem. We are builders by nature. We love to jump to our beautiful designs or our beautiful code or our beautiful product features, and we tend not to be able to separate out the actual customer problem in the market, where there are 52 other solutions for executing on that problem. What jobs to be done does is force you to study the customer problem in the market without immediately jumping to your solution and looking at the pain points along your solution. If you're doing a customer effort score internally, while that's great for starting to parse apart how your customers are struggling through the user flow of your product, it does not highlight the struggles they may be having that you're not covering with your solution or product. So that's the other thing, I think.

Applying it across B2B and B2C markets

[00:05:17] Host: That's great. Just to inform everybody about jobs to be done: Rich mentioned the customer struggle, and one of the key elements of jobs to be done is figuring out what the customer struggle is. Behind the theory is that the reason people switch products, the reason they look for new products in the market, is that they are struggling to get a job done. My next question: I know you've worked on using jobs to be done in both B2B and B2C markets. Maybe you can talk a little bit about why you think it's applicable in different types of markets.

[00:05:56] Richard: Absolutely. Markets can be defined by geography, by product segments or business segments, or even by customer segments. I actually think jobs to be done can apply anywhere. Let's look at some jobs: driving to a destination on time, creating a mood with music, acquiring new customers, making yourself feel beautiful, becoming more healthy. All these jobs have inherent needs.

[00:06:26] Richard: One of my favorite ones is selling a used car. I don't know if any of you have ever sold one of your cars; I've sold many. One of the challenges is trying to qualify serious buyers when you're getting people from your 20-kilometer radius where you live. How do you know who's a serious buyer? Do you actually have time to talk to 25 different people to find who's serious? There's no really great solution for that. That need is probably common across markets.

[00:06:59] Richard: Now, the interesting piece is that there might be a particular market condition where that need becomes more or less served. Let's say you're in a geography or country where data privacy is much more strict, versus another where you have less strict data privacy laws. A company might be able to create a solution by pulling publicly available data about those people and actually scoring for you who is higher quality versus lower quality, based on their credit score or some other attribute you can learn about them. That wouldn't be the case in a place where there was high data privacy. Therefore, you might see that need being more highly underserved in a certain geography. Yes, you have to solve it a different way.

How teams respond to jobs to be done

[00:07:48] Host: That's great. Speaking of solving for the needs and satisfying those customer needs, that requires effort from your teams, and I know you've worked with teams at different companies using jobs to be done. How did those teams respond to jobs to be done, and what were some of the challenges of getting the teams aligned?

[00:08:07] Richard: That's a great question. Like anything else, I think it depends. I like to think jobs to be done is like, and we had a slide before about getting married, developing a relationship. Some people fall in love with it right away, and for some people it takes a bit of commitment and working through some challenges to really create a long-term, sustainable relationship with the methodology.

[00:08:35] Richard: But in general, let's segment the people in the audience here. UX people tend to take to it like fish to water, because you're really starting to break down the customer struggle into its job steps, which can be 10 to 12, and then break those job steps down into needs, which could be 8 to 10 each, so you can get to 60 to 80 needs. When you think about user flows, UX people tend to think that way functionally anyway, in that linear fashion. So they're like, "Okay, we get it. A different way of doing things, but we love this. We've been telling people to evaluate the customer problem for years, and they don't listen to us." Joking around.

[00:09:16] Richard: And then I'd say dev people tend to take a little bit longer to understand the methodology. The magic moment for devs is when the needs get broken down and then scored, and you actually have a quantitative measure to prioritize which needs are higher priority for customers. And the second magic moment for devs is when you can actually measure the speed and accuracy of your solution in satisfying those underserved needs. Now it becomes very much a quantitative exercise. As you release new features and new versions of your product, you can start to see if speed and accuracy went down. You can also measure your competitors' solutions on speed and accuracy. People joke, but devs tend to like numbers, because code is precise and words are not; words are ambiguous. So that's where I think the magic happens for devs.

The hardest part: adoption

[00:10:13] Host: That's great. You mentioned that jobs can have multiple steps. For example, getting to a destination on time can have ten or fifteen different steps, and each one of those steps can have different needs, so you can get to 60, 80, in some cases 100 needs. That's a lot of data and information to then analyze competitors and figure out the segments you're going to target. So what was the hardest part of using jobs to be done?

[00:10:40] Richard: I think the meta challenge is user understanding and adoption. Again, you might have a few people, some UX people, some product people, maybe a dev or two, who go through this process to structure the job steps and the needs. You can't use a team of 200 to do it; you need a small team of five to ten. Those people will tend to get religion, because they actually wrote the book.

[00:11:13] Richard: The problem then is that next step. How do you start to get other people on board: other product teams, the executives in the company, even people like sales and marketing, where it's really valuable? As we talked about, systematizing down below the level of the iceberg there and getting sales and marketing on board, that's the real challenge. Because jobs to be done is inherently complex, how do you simplify, either visually or in some other way, and abstract up that complex set of underserved needs, to quickly get people interested and understanding it without having to throw up 80 needs on a PowerPoint and have them read through each one? I think that's the core challenge.

The fuzzy front end and alignment

[00:12:00] Host: That's great. Jobs to be done can be used for different reasons: to identify a new market you want to enter, for example, if you're a startup, how big that market opportunity is, or if you're a larger company entering a new market. It can be used to respond to competitors that have entered your market and are maybe taking share. So what was the main problem you were trying to solve when you first started using jobs to be done?

[00:12:26] Richard: Many problems, but again, I think the meta problem, which all product, UX and DX teams face, is that fuzzy front-end piece. How do you align and prioritize all the teams around a set of ideas, to then go design and execute against them? I don't know if any of you have found this, but even in a two-week sprint, the first couple of days you're really trying to get alignment. I think that's the main problem: we spend cycles and cycles subjectively arguing over different ideas and scoring them. But they're our scores, not the customer's scores, and our scores are inherently biased, generally, whether we know it consciously or not.

[00:13:18] Richard: So the meta problem is how you separate yourself from that and actually have the market, a set of customers, score the needs along a continuum. Then you can step back and prioritize what you're going to invest in. You might find a highly underserved need, and you and your team may say, "We're not going to build a solution against that. That's too risky, that's too hard, that's too far from the apple tree of what we do." But at least you can have that objective discussion and align not to invest in it. And maybe the passionate devs say, "But I already have code to fix that problem," but then, "Okay, I understand we're not going to go after that as a group." I think that's the meta problem, because there's a lot of wasted time around alignment.

Bringing executives along

[00:14:01] Host: That's great. I think we heard earlier about statistics on the rate of failure of a lot of new product launches, or launches of new features into products: how frequently they fail to generate the revenue and profitability growth that companies are looking for. You mentioned that deciding what to invest in is a key use for jobs to be done, which is interesting, because at the end of the day, even at larger and smaller companies, the executives are like venture capitalists. They're looking for a portfolio of opportunities at the company to invest in, and they have to create equity returns and equity value for the company. With that in mind, how did your executive colleagues respond to jobs to be done, and what did you do to help bring them along, to show that this can help them make those types of investment decisions?

[00:14:55] Richard: I think there were two things. It's funny you mention investors and VCs. We tend to beat up our executives sometimes, but remember, they've got to answer to investors, and those could be internal or external investors. That's a pretty hard job. I don't know if any of you have sat in that seat, but you could spend a good amount of time doing that. So I think point number one is risk mitigation. It is a wonderful tool for feeling that your team, your resources and your dollars are focused on the things that really matter in the market and give you a competitive advantage. You may not land a punch with a new design, solution or product, but at least you know you've probably mitigated your risk.

[00:15:42] Richard: The second valuable thing is that some executives will actually start to dig in on the job steps. Maybe they're ex-product people, maybe they're ex-sales people. And who can argue with really focusing on the customer problem as a way to think about what you're going to build and invest in? So you'll actually start to get more alignment top-down. The executive might be an ex-strategy consultant who doesn't understand the dev or UX process. This is common ground, I think, for anybody across the organization. I've seen a lot of executives get more involved and more aligned, in a good way, with their product teams, instead of being detached and beating them up based on results, metrics and performance.

[00:16:25] Host: That's great. You mentioned risk mitigation, which I think is such an interesting concept for product teams to think about. Let me ask the audience really quickly: how many people, before you start investing in a product roadmap, when you're going to develop your new product, do some sort of quantitative risk mitigation? So far nobody, I think. Oh, one person. There we go, we have one person. That's interesting, because essentially everybody here is asking their company to take capital, literally money, time and resources, and invest it in your product ideas, and yet we're not doing any up-front risk mitigation. So I think that's a really interesting way to use jobs to be done: to mitigate that risk before you make that big development investment.

How problems were identified before

[00:17:16] Host: Before jobs to be done, you talked a little bit about the research, but what was the process you used to really identify the problem you were going to solve? Maybe you can contrast that a little with jobs to be done as well.

[00:17:31] Richard: I'll go back to the third-party research. Call it the fuzzy front end, call it the discovery portion of dual-track Scrum, or whatever name you want to put on it. You would go through many processes. You would get user groups in a room, go to Starbucks, issue online surveys, hire that third-party firm I mentioned before to do qualitative and quantitative segmentation. There are various ways to understand and discover customer problems, but they're not necessarily structured methodologies that have a process. There are some frameworks and some structure, but what happens is that you tend to reinvent the wheel every time you're trying to understand customer problems. They're not very systematized. I've tried it, invested in it at bigger companies and spent a lot of budget, and at smaller companies done it myself. I've tried all various ways, but I think they fall into those two buckets.

Short-term and long-term outcomes

[00:18:46] Host: That's great. Can you talk a little about the short-term and long-term outcomes, the results from using jobs to be done, maybe internally and externally?

[00:18:59] Richard: I think short term, particularly as it relates to product development speed and quality... it's always hard to put a number on these things, but I would say one of the short-term effects, if you implement it correctly, is that you're able to speed up the efficiency and effectiveness of your dev process by as much as 50%. What you've accomplished in a two-week sprint you can probably accomplish in three quarters of that time; you're shaving off two or three days. A lot of that has to do with what I talked about before, which is that you already have alignment, you already have understanding. So the team can immediately focus on, "Okay, this week we're going to solve need number 71. We're going to brainstorm a set of ideas on that, select the best one, and go build it," as opposed to aligning on what to solve, or having several ideas that solve different problems, et cetera.

[00:19:53] Richard: That's short term. Long term, and this is where the magic happens, is when you get this process going of iterating on these customer needs, and everybody's contributing. Devs are contributing. We talked about how the whole point of UXDX is integrating that cross-functional team up front, and this is about as far up front as you can get. Everybody is aligned and focused on those ideas, so the quality of the ideas and the quality of the solutions that come out are laser-focused, because people understand very prescriptively the problem they're going to try to solve this week, this month, this quarter, this year.

[00:20:30] Richard: I think you'll just get higher-quality solutions. One of the jokes, and I've heard you say this, Jay, is that people think there are no bad ideas. Actually, there are a lot of bad ideas. The ideas may be good for some other purpose, but generally, for a particular need for a particular customer, we've seen products that don't hit the mark, and that's generally the result of a bad idea. So this starts to eliminate those things, and people start to get laser-focused because they understand what they're trying to solve.

Stable jobs, changing technology

[00:20:55] Host: That's great. One of the core concepts behind jobs to be done is that a job remains stable over time. It doesn't change like new technology, like blockchain or machine learning; those are all technologies that change very rapidly, and it's very hard if you're chasing something that's changing very rapidly. So has that ability to look at a stable job, one that isn't going to change next year or even ten years from now, helped with the outcomes?

[00:21:26] Richard: Absolutely. I think that's probably one of the hardest concepts for product people to wrap their brains around, but also one of the most valuable. One of your favorite ones is creating a mood with music. Let's take this hall, which maybe at some point was used for music. If it was 200 years ago, you would probably bring in a quartet, two violins and whatever else. Today we would probably use some algorithm to parse through your respective playlists, look for some commonalities, and then hit a button and pick some songs. The need to create a mood with music has not changed in 200 years. How you build a solution against it, based on available technology or other market conditions, changes rapidly.

[00:22:15] Richard: So again, that separation is incredibly valuable, because people get very, I call it, belly-button centric: looking at themselves, looking at their products, looking at their features, and losing sight of that external job that really hasn't changed over time.

Q&A

[00:22:30] Host: That's great. Well, I have a thousand more questions for Rich, but why don't we open it up to the audience. Let me ask the audience: how many people here have used the jobs to be done method at their companies? That's pretty good, maybe 10 or 15%. That's great. Does anybody have any questions or comments about jobs to be done for Rich? I think we've got people with microphones around. Okay, great, we've got a question back there. Is that someone in the back who had a question? Great. I'm making sure I can see everybody with these bright lights. If you could state your name, your company and your role, that would be great too.

[00:23:20] Audience: My name is Kitty Parkhill [?]. I'm a senior product owner from Aviva, but not Aviva the insurance company; the engineering company. We started implementing jobs to be done two years ago, so we're on our fifth release with it, and we're in a stage of lessons learned. What's your biggest lesson learned from implementing the methodology over many, many customers and many sites?

[00:23:45] Richard: It gets back to onboarding and getting the broader organization to use the methodology. Otherwise, it'll slowly either stay with a small group or die. So I think you need to start educating and bringing people on board early and often, whether that means reading a book, doing an online course, having somebody like Jay come in to speak and educate, or watching some YouTube videos. You almost need a communication strategy. You almost need to get a good comms person to put together a program and really start to get people on board, because it is a bit complex, and it is a bit hard for us to separate ourselves from our products and really look at the customer problem in isolation. I think that is probably the biggest lesson learned for me, because I've yet to get 100% penetration into an organization that's truly using the methodology.

[00:24:42] Richard: The second lesson learned is that with methodologies and processes, you need to be rigorous when you do these things. I've seen people using jobs to be done, but not really, and the methods tend to get a bit bastardized, and then they get misapplied, and then they don't work, and people just assume it's a bad methodology, when really it's based on the misuse of the methodology. So you have to be rigorous in the process as well. Those are the two big takeaways, I think.

[00:25:10] Host: Great question. I think we have time for one more question. Any other questions? We have one over here. Cool, great. And again, if you could state your name and your company, that'd be great.

[00:25:35] Audience: Hi, I'm Mamrie [?]. I'm head of UX at the Financial Times. I just wondered: do you have a central research team that runs the jobs to be done program? And how do the teams that are working consistently on your products understand the customer and understand the jobs to be done while they're actually figuring out solutions to answer those problems?

[00:26:02] Richard: It's a great question. I think it's inherently a bit dangerous to have any one functional product team, in any part of the customer journey, be the owner of jobs to be done. It can start there, but it inherently looks at the entire customer problem, even at needs external to what your current product may be solving. So you can either start with a specific product team that learns the methodology and actually executes against it, but then you need to evangelize and expand it. The other way you can do it is to create a central program, where you actually bring people on board. You have to go through the process of analyzing a job, or multiple jobs, and then you start to bring different product teams, UX teams, dev teams, sales and marketing teams on board. So you make it a central program, just like any other central program. Both can work, and you can do both at the same time. But again, it's that first step past the first team, starting to broaden it out, which is the critical problem to solve in an organization for change management.

[00:27:09] Host: That's great. Well, thanks, Rich. That was really great. Thank you.