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

DEFINING THE PROBLEM USING DATA AND INSIGHTS FOR UPFRONT PRODUCT SUCCESS

SPEAKER 1
Okay, great. So, I think 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. And jobs to be done are a little bit different because it focuses teams, product teams, and marketing and sales teams on the customer's job. So, since you have a lot of experience on it, my first question is what interested you as a product executive in jobs to be done?
SPEAKER 2
Yeah, I think there were a few things, Jay, I think first, when we think about jobs to be done, if anybody is familiar with it, it's a needs first methodology. And 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. And these can become important variables when you're considering your design and your implementation of your product. But you really need to start with the customer problem. First, jobs to be done break it down with high fidelity into 60 or 80 needs and those actions become variables that you can use. So, I think that's the first thing. I think secondly, what I really liked about it, it is highly actionable.
So, you know, one of the other challenges with customer research, is you might get an output, but then you take a need to your dev team. And if you describe a psychographic need or lifestyle the dev teams thinks ok what do I do with that. And so, jobs done really seek to get highly functional and prescriptive around those needs. So, you actually can take action against it. And teams can say, okay, now I understand how to develop a solution to that very specific problem. And I think the third thing is, it's a methodology, and methodologies live on their applications of theory that you can iterate and improve on. A lot of times customer research ends up as a PowerPoint, or I guess, these days in a Dropbox or OneDrive somewhere. And it never really gets used, it's really kind of a reference document. And jobs to be done is something that integrates both UX, Dev and product teams together. And really, it becomes part of the culture. And I think that is probably the thing that attracted me most to it.
SPEAKER 1
Yeah, that's great. So, since you've had a long career as a product executive, how would you contrast the jobs to be done methodology with other methods?
SPEAKER 2
Yeah, so I guess, other methods that I've tried, or, you know, they were mentioned before, are traditional sort of second party or third party research where you hire a really smart market research company, maybe they have some sociologists that do some ethnographic lion in the wild research on how users are trying to execute a job and then hire the stats to do some client. And then the other method is also, you know, studying internally, we talked before about measuring the product experience, and looking at customer effort. So, there's kind of an internal way to do it. And then hiring third parties. The problem with those two are, and they're very good methods to use, what the jobs to be done. The advantage that it brings is, first of all, you're integrating your team.
So, your team is actually working on the structuring the needs, scoring the needs, and then actually seeing how your product is mapping to the needs, how are you 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. And so, there's risk with third parties, even though they're super smart, and they come up with really good insights, that either your team is not bought into it, or something gets missed, because who knows, inherently the problems that we're trying to solve better than the people that are focused on them, which are us. So, the methodology actually integrates your team.
So, I think that's probably the biggest advantage. The second biggest advantage when you're comparing it to internal research, is a lot of times one of my favourite double entendre raise or double meeting mantras is and I always say this to my product teams is the solution is not the problem. We are builders by nature, we love to jump to our beautiful designs or beautiful code, or beautiful product features. And we tend to not be able to separate the actual customer problem out in the market, where there are 52 other solutions to actually executing that problem. So, what jobs to be done does is it actually forces 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. While that's great to start to parse apart, how your customer is 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.
SPEAKER 1
Yeah, that's great. And that's interesting just to inform everybody about jobs to be done Rich mentioned, the customer struggle. And that's one of the key elements of jobs to be done is figuring out what the customer struggle is. And behind the theory is that the reason that people switch products, the reason that they look for new products in the market is because they are struggling to get a job done. And my next question, I know that you've worked on using jobs to be done in both b2b and b2c markets. And maybe you can talk a little bit about why you think that it's applicable in different types of markets?
SPEAKER 2
Absolutely, yeah. And markets can be defined by geography, markets can be defined by product segment or business segment, or even customer segments. So, I actually think jobs can be done anywhere. So, let's look at some jobs. So, driving to a destination on time, creating a mood with music, acquiring new customers, making yourself feel beautiful, making yourself becoming more healthy. All these jobs have inherent needs. One of my favourite ones is selling a used car, I don't any of you have ever sold one of your cars, I've sold many, you know one of the challenges is actually trying to qualify serious buyers, when you're getting people pinging you from your, you know, 20 kilometre radius where you live, how do you know who's a serious buyer? Do you actually have time to talk to 25 different people that are that serious, there's no real great solution for that. That need is probably common across markets. Now, the interesting piece is that there might be a particular market condition where that need becomes less.
So, let's say you're in a geography or country where data privacy is much more strict versus where you have less strict data privacy laws, a company might be able to create a solution by pulling public data publicly available data about that person or people and actually score for you, who is higher quality versus lower quality based on their credit score, or some other attributes that you can learn about them. That wouldn't be the case in a place where there was high data privacy, therefore, you might see in a certain geography that needs being underserved, more highly, yes, you have to solve it a different way.
SPEAKER 1
That's great. So, 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. So how did those teams respond to jobs to be done? And what were some of the challenges of getting the teams aligned?
SPEAKER 2
Yeah, that's a great question. As like anything else, I think it depends. I think over the long term, if you're able to, I'd like to think jobs to be done is like, we had a slide before about getting married is like developing a relationship. Some people fall in love with it right away. And some people, it takes a little bit of commitment, and working through some challenges to really create a long term sustainable relationship with the methodology. But I would say in general, let's pick apart people, let's segment people in the audience here, UX people, they tend to take to it like fishing 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 eight to 10 each, or you can get to 60 to 80 needs. And so, when you think about user flows, UX, people tend to think that way functionally, anyway, in that linear fashion.
And so therefore, they're like, okay, we get it, different ways of doing things. But, you know, we love this. We've been telling people to evaluate the customer problem for years, and they don't listen to us, right? Joking around. 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 they get scored. And you actually have a quantitative measure to prioritise which needs are higher priority for customers. And then the second magic moment for devs is when you can actually measure speed and accuracy of your solution satisfying that underserved needs so now it becomes very, 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 also can measure your competitors' solution on speed, inaccuracy. So, people joke but you know, devs tend to like numbers because code is precise. Words are not. The words are ambiguous. So that's where I think the magic happens for dev.
SPEAKER 1
Yeah, that's great. And so, you mentioned that jobs can have multiple steps. So, for example, the example use of getting to a destination on time that can have multiple steps, you know, 10, 15 different steps. And each one of those steps can have different needs. So, you can get to the 60, 80, in some cases, 100 needs, that's a lot of data and information, to then analyse competitors and figure out the segments you're going to target. So, what was the hardest part of using jobs to be done?
SPEAKER 2
Yeah, I think sort of the meta challenge is user understanding and adoption. So again, you might have a few small people, some UX people, some product, people may be a dev or two, that go through this process to actually structure the job steps in the needs, you can't use a team of 200. To do it, you need a small team of five to 10 to do that. So those people will tend to get religion, because they actually wrote the book. 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 systemising, down below the level the iceberg, they're getting sales and marketing on board, that's the real challenge. Because jobs to be done are complex. Inherently, how do you simplify either visually, or in some other way and abstract up that complex set of underserved needs to people to quickly get them to start to get interested in understanding it without having to throw up 80 needs on a PowerPoint and have them read through each one of them. I think that's kind of the core challenge.
SPEAKER 1
Yeah, that's great. So, jobs to be done, can be used for different reasons. So, trying to identify a new market, you want to enter, for example, if you're a start-up, how big is that market opportunity. Or if you're a larger company entering a new market, it can be used to respond to competitors that have entered your market that are maybe taking share. So, what was the main problem that you were trying to solve when you first started using jobs to be done?
SPEAKER 2
Yeah, many problems. But again, I think the meta problem, which all product UX and DX teams face is on that Fuzzy Front end piece. How do you align and prioritise all the teams around a set of ideas, to then go design and execute against them? I don't know even in a two week sprint, I don't know if any of you have found the first couple of days, you're really trying to get alignment. And I think that's the main problem is that we spend cycles and cycles, subjectively arguing over different ideas and scoring them, but there are scores. They're not the customer scores. And our scores inherently are biassed, generally, whether we know it or not consciously.
So, the meta problem is how do you separate yourself from those that actually have the actual market and instead of customers score the needs along a continuum, and then you can kind of step back and then prioritise what you're going to invest in. Now, you might find a highly underserved need, and you and your team may say we're not going to solve that problem, that's too risky. That's too hard. That's, that's far from the apple tree of what we do. But at least you can have that objective discussion and align to not invest in that, and maybe the passionate devs that are like, but I already have code to fix that problem. But okay, I understand that we're not going to go after that as a group. Right. I think that's the meta problem, because there's a lot of wasted time around alignment.
SPEAKER 1
Yeah, that's great. And I think we heard earlier about statistics on essentially the rate of failure of a lot of new product launches, or launches of new features into products, how frequently it fails to generate the revenue and profitability growth that companies are looking for. So, you mentioned that deciding what to invest in is a is a key use for jobs to be done, which is interesting, because as the executive teams, at the end of the day, even at larger and smaller companies, those 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 values for the company. So, 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 say that this can help them make those types of investment decisions?
SPEAKER 2
Yeah, I think there are two things and it's funny you and investors and VCs, I mean, we tend to beat up our executives sometimes. But remember, they got to answer to investors. And those could be internal investors, it could be external investors. So, that's a pretty hard job. I don't know if any of you've 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 to feel like your team and your resources and your dollars are focusing on the things that really matter in the market and give you a competitive advantage. Now, you may not land a punch with the new designer solution or new product, but at least you know, you've probably mitigated your risk. And I think the second valuable thing is, some executives will actually start to dig in on the job steps, right? Maybe their x product people, maybe there's X sales people. And you know, who can argue with, you know, really focusing on the customer problem as a way to think about what you're going to do and what you're going to build and invest in. So, you'll actually start to get more alignment, top down. You know, the executive might be an X strategy consultant that doesn't understand the Dev or UX process. This is a sort of common ground, I think, for anybody across the organisation. And I've seen a lot of executives get more involved and more aligned in a good way with their product teams instead of being attached, detached and beating them up, based on you know, results, metrics and performance.
SPEAKER 1
Yeah, that's great. You mentioned risk mitigation, which I think is such an interesting concept for product teams to think about. So, let me ask the audience just really quickly, how many people before you start investing in a product roadmap when you're going to develop your new product? How many people do some sort of quantitative risk mitigation? so that's so far, nobody, I think I could see, oh, one person, there we go. We have one person. That's interesting. Because essentially, everybody here is asking your company to take capital, you know, literally money, time and resources, and invest in your product ideas. And yet, we're not doing any upfront risk mitigation. So, I think that's so interesting, as a way to use jobs to be done to, to mitigate that risk before you make that big development. So, before jobs were done, you talked a little bit about the research, but what was the process that you used to really identify the problem you were going to solve? And maybe you can contrast that a little bit to jobs to be done as well?
SPEAKER 2
Yeah. So, I'll go back to the third party research, right? So, we would generally, you know, call it the Fuzzy Front End, call it the discovery portion of it, you know, dual track Scrum, or whatever name you want to put on it. But you would go through many processes, you would get user groups in a room, go to Starbucks, issue online surveys. Yeah, you know, hire that third party firm that I mentioned before, to do qualitative and quantitative segmentation. I mean, there, there are various ways to actually understand and discover customer problems. But they're not necessarily structured methodologies that have a process, they're not processes, you can kind of reinvent the wheel each time. And there's some frameworks and there's some structure, but what happens is, you tend to kind of reinvent the wheel every time we're trying to understand customer problems. They're not very systematised. But you know, I've probably invested in bigger companies, spent a lot of money, and in smaller companies kind of done it myself, but tried all the various ways, but I think they fall into those two buckets.
SPEAKER 1
Yeah, that's great. Can you talk a little bit about the short term and long term outcomes, the results from using jobs to be done and maybe internally and externally through the company.
SPEAKER 2
Yeah, I think short term, particularly as it relates to product speed and sort of quality, product development, speed and quality. I would say, it's always hard to put a number on these things. But I would say that one of the short term effects, if you implement correctly, is you're able to speed up the efficiency and effectiveness of your Dev process, even by like 50%. So, you know, two weeks, what you would accomplish in a two week sprint, you can probably accomplish in, you know, three quarters of that time, you're shaving off two or three days. And a lot of that has to do with what I talked about before, which is, you know, 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 which we're going to select the best one and we're going to go build it as opposed to aligning on what to solve or maybe you have several ideas that are solving different problems, etc, etc.
So, I think that's short term. Long term and this is where the magic happens when you get this process going. Sort of this process of iteration on these customer needs and everybody's contributing devs are contributing, we talked, you know, the whole point of view dx is integrating that cross functional team upfront. And this is about as near the front as you can get. And so 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. And I think you'll just get higher quality solutions. Because, you know, one of the jokes and I've heard you say this, Jay is, you know, people think there are no bad ideas, actually, there are a lot of bad ideas, there's not, the ideas may be good for some other purpose. But generally, for a particular need for a particular customer, we've seen products that actually don't hit the mark. And that's the result of a bad idea, generally. And so, this starts to eliminate those things. And people start to get laser focus, because they understand what they're trying to solve.
SPEAKER 1
Yeah, that's great. And one of the core concepts behind jobs to be done is that a job remains stable over time. It's not changed, like new technology, blockchain, machine learning. Yeah, those are all kinds of technologies that change very rapidly and very hard if you're chasing something that's changing very rapidly. So, has that ability to look at a stable job that, you know, isn't going to change next year, or even 10 years from now, has that helped with the outcomes?
SPEAKER 2
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 and so you know, when we think about one of your favourite ones, is to create a creative mood with music. So, let's take this hall, which maybe at some point was used for music. If it was 200 years ago, you know, you would probably bring in a quartet of violins and, and whatever else. And today, we would use some algorithm to probably parse through your respective playlists, and then try to look at some commonalities. And then we would hit a button and pick some songs, right? The need to create a mood with music has not changed in 200 years, how you solve it based on available technology or other market conditions changes rapidly. And 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.
SPEAKER 1
That's great. Well, I have 1000 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? So that's pretty good. That's maybe 10%, 15%. That's great. Does anybody have any questions or comments about jobs to be done for the rich? I think we've got people with microphones around. Okay, great. Well, we've got a question in the back there. Yeah. Is that someone in the back? Who had a question? Yeah, great. Making sure I can see everybody with these bright lights. And if you can state your name, and your company and your role, that would be great, too.
SPEAKER 3
Hi, my name is Katie Parkhill. I'm a Senior Product Owner from Aviva. But not Aviva, the insurance company, the engineering company. So, we started implementing Job's to be done two years ago. So, we're on our fifth release at night and were wondering, we're in a stage of lessons learned and things. What's your biggest lesson learned from implementing the methodology, over many, many customers and many sites?
SPEAKER 2
Yeah, again, it gets back to onboarding and getting the broader organisation 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 bring people on board early and often. So, whether that means, you know, reading a book, doing an online course, having somebody like Jay come in and speak and educate by watching some YouTube videos, you almost need a communication strategy, right? You almost need 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. And so, I think that is probably the biggest lesson learned for me. Because I've yet to get 100% penetration into an organisation that's truly using the methodology. And I think the second lesson learned is, you know, 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 that, you know, the methods tend to get a bit muddy, and then yhey get misapplied, and then they don't work. And then people just assume it's a bad methodology. And that's really based on the misuse of the methodology. So, you have to be kind of rigorous in the process as well. Those are the two big takeaways, I think.
SPEAKER 1
Yeah, great question. Anyway, I think we have time for one more question. Any other questions? Yeah, we have one over here. Cool. Great. And again, if you could state your name and your company, that'd be great.
SPEAKER 4
Hi, I'm Anne Marie. I'm head of UX at the Financial Times. I just wonder, do you have a central research team that kind of runs the jobs to be done program and how are the teams that are kind of working consistently on your products, then kind of understand the customer and understand the jobs to be done? While they're actually kind of figuring out solutions to answer those problems?
SPEAKER 2
Yeah, it's a great question. I think, inherently, it's a bit dangerous to have any one functional product team in any part of the customer journey, be the owner for jobs to be done. It has to be something it can start there. But it inherently looks at the entire customer problem, even external to needs that your current product may be solving. So, you either can start with a specific product team that learns the methodology and actually executes against it. But you need to evangelise and expand it. The other way you can do it is to create a program, right? Central program, where you actually are bringing people on board, you actually have to go through the process of analysing a job or multiple jobs. And then you start to bring different product teams, UX teams, dev team sales and marketing teams on board. So, you make it a central program, just like any other central program. Both can work, you can do both at the same time. But again, it's that first step past that first team, you know, starting to broaden it out, which is the critical thinking problem to solve in an organisation for change management.
SPEAKER 1
That's great. Well, thanks, Rich. That was really great. Thank you.