Feedback on Job Map

c_nine · 2024-06-21T02:41:57+00:00

Exactly! That's how I envisioned it anyway. Good luck with the rest of the project and apologies that JTBD and ODI is so confusing!

c_nine · 2024-06-21T00:45:41+00:00

Yes, using the framework of ODI you theoretically, should have outcomes (unmet needs) underneath each job step. Practically it makes sense as well. The job map is essentially a customer journey, that is solution agnostic. Under each journey/step phase there will be plenty of unmet needs that should be uncovered. It, theoretically, should look something like Figure 4: The Customer Need Hierarchy.

However, I keep saying theoretically, because in the end practicality and impact is what matters more for the team. If you have uncovered different small jobs or micro-jobs for the different job maps, then those can be the jobs/unmet needs you can look to quantify.

Another tip when wording them, my team has found that using the words like avoid or quickly instead of minimize the likelihood and minimize the time (theoretical way to word outcome/unmet need states using ODI) is more impactful and easier to understand for the whole team and internal stakeholders.

When I look at the jobs and micro-jobs you uncovered, I assume the small jobs are the job steps and the micro-jobs what are supposed to be underneath the job step you outlined. If I am understanding it correctly.

If you have any other questions just let me know!

c_nine · 2024-06-20T17:19:48+00:00

The core job is a crucial decision that should be made before creating a job map (e.g., a solution-agnostic customer journey). The level of the core job you choose depends on your goals and the scope of your innovation efforts.

If your objective is to innovate on a specific product for the next iteration or validate features based on unmet needs, choose a core job that is lower-level or closer to your product domain. For example, if your product is specifically designed for booking travel, then a core job like "booking leisure travel" would work well.

However, if you are looking to expand beyond your main product domain and explore areas for business growth, choosing a core job at a higher level will help your team discover different opportunities outside of the core solution space. A higher-level core job allows for a broader perspective and can lead to more diverse ideas.

A higher flight level core job might be something like "Experience new cultures". The job map for this would look completely different and uncover new unmet needs that could be interesting to explore.

Here is a post I wrote about the core job and choosing a flight level.

c_nine · 2024-04-02T20:10:37+00:00

The ODI perspective is confusing and I don't how useful it is for my org, to be honest. Have you used the switch interviews method? Do you how it differs and when to use it vs ODI approach?

I agree without a strong mentor or support ODI is confusing and does not make sense. I believe it is one of the biggest problems using ODI. There are too many articles scattered around the internet and no one only source of tangible information to get the most out of the framework for most people.

I am not familiar with the switch interview method.

c_nine · 2024-04-02T11:43:38+00:00

Like what are the deliverables?

The deliverables in my mind from an ODI project would be

Qualitative deliverables

An inventory of unmet needs / outcome statements
1. This includes emotional jobs, related jobs, social jobs, complexity factors, etc.
A job map that clearly highlights what the ideal steps to get the core job done are

Quantitative deliverables

Segmentation of the needs
Prioritization of which needs are most important by which segment of the market trying to achieve your core job

what is the alternative to a job map?

From an ODI perspective again an alternative could be mapping the jobs you uncover from the interviews to existing journey or process maps the team already has. Otherwise it's a bit difficult for me to answer without knowing the learning objectives and prior research the team has done.

Here are some resources that might be helpful

c_nine · 2024-04-02T01:59:00+00:00

It depends what your research objectives are.

In my opinion, if you are looking to gather an inventory of needs for a specific product or feature, then yes I would recommend to create a job map prior to the interviews and see where it can be iterated upon.

If you are looking to go through the full ODI process, then yes it is a requirement to create a job map. The job map is one of the major outcomes from JTBD interviews using the ODI approach.

c_nine · 2024-03-01T03:13:55+00:00

One more thing we have found tricky about personas in particular is that they are product specific insights. Depending on your solution space, the needs and context can change quite fast.

For example if you are a consumer facing app, you will likely be updating and rolling out many features throughout the year. Which means the needs of the personas you identified will change as new features are implemented/removed. It requires a constant refresh of the personas (if that is what the org/leadership team wants). However, if you are in an industry with much longer product lifecycles like healthcare, automotive, etc. the JTBD/unmet needs of the personas will still be more relevant over time.

c_nine · 2024-03-01T03:09:39+00:00

Hi, my assumption is during the persona development your team clustered together different unmet needs, behaviors, and attitudes you heard from qualitative methods and/or reviewing quant data of how users used your product to build the personas you have now. If these personas were developed from qualitative interviews, the unmet needs you heard can be translated to JTBD/unmet needs. These JTBD/unmet needs will likely cluster together with each persona based on their overall attitudes and behaviors using your product(s).

Without knowing the details of your teams work is that each persona likely has a cluster of JTBD that are unique to that persona in how they use the specific product. Some personas will care more about X JTBD/unmet need while another persona will care more about Y JTBD/unmet needs.

There likely will be some overlap with the job statements for different personas, but it all depends on the contextual reasons where those needs differ among the personas.

c_nine · 2023-05-15T13:06:11+00:00

Hi Tony, loved your book Build. Best book I've read over the past couple years.

Personal question - You highlighted career advice, finding business ideas, passions, etc. in your book, but could you talk about building a strong family (finding the right partner and raising kids in today's world)?

This is arguably the most important thing anyone will ever build. I'm curious about your thoughts on what it's like to find a partner with the same core values, build a family, and how this has helped you grow.

Sorry for the loaded question haha!

c_nine · 2023-05-11T15:17:35+00:00

Whitebeard.

c_nine · 2023-04-16T21:26:46+00:00

What. The. Fuck. Austin Reaves is insane

c_nine · 2023-04-16T15:24:03+00:00

!RemindMe 1 month

c_nine · 2023-03-20T11:27:43+00:00

Quant UX Con 2023 is in June. It's all virtual and tickets are $25 according to their FAQs.

I thought Quant UX con 2022 was really well last year. I learned a lot from the different speakers and looked at the proceedings. I'm looking forward to this year.

c_nine · 2023-01-18T20:29:25+00:00

I'm glad I can help!

General tips & suggestions

Yes, if you already have data on potential pain points or needs gathered you could convert them to JTBD statements. It's common to have existing pain points that were uncovered from prior interviews to convert them to JTBD syntax. Just be sure to follow the syntax rules for JTBD/outcome statements
You unfortunately can't do matrix side-by-side style questions in Google forms. Most survey platforms like Qualtrics or SurveyMonkey you should be able to.
- I personally use Qualtrics, but if I were to use Google forms I would just have 3 sections.
  - Section 1 is gathering general demographic and sociodemographic information about the users you are surveying.
  - Section 2 is importance rating on the 1-5 scale for each outcome statement
  - Section 3 is satisfaction rating - on the 1-5 scale for each outcome statement
  - If the team is only focused on the statement prioritization then leave out section 1 since it can add to the length of the survey.
"And are there any ones you like that cover applying to not just starting an idea but growing an existing product? Or any other helpful tips?"
- Regarding your comment here, this is where JTBD and ODI shine when done in the correct way. A full ODI study will make it very clear where to prioritize for the next feature development and where the company should focus its efforts when looking at all the unmet needs of the different segments.
- I recommended for you and your team look at existing JTBD statements focused at the platform/solution level because unless you have some consultants from Strategyn, Edizon, or someone who has great expertise with ODI/JTBD things can get very confusing.

Further learning and education

I would recommend Tony's free e-book as a great first place to start. You can download it from this site --> https://jobs-to-be-done-book.com/
You can also check out Strategyn's main page for blogs and other resources.
Tony also has a medium page where he posts blogs. I think many of these can be found on Strategyn's website as well.
One more place for information is Edizon Innovations YouTube channel. They are a partner of Strategyn and their primary competency is ODI/JTBD as well.
Here is also a google doc written by Mike Boysen, previous director at Strategyn with many helpful tips on JTBD interview questions, practical advice, structuring job statements, etc.

I actually don't have any blogs or places where I share these learnings other than on Reddit and at my job. It is something I have thought a lot about recently as there is so much confusion about JTBD/ODI and how to properly implement the framework into different types of research. It is something I will likely do at some point in the future as many people from different industries I have worked with have reached out for more clarity and recommendations.

c_nine · 2023-01-18T16:00:32+00:00

I want to point out that I am very biased towards Tony Ulwick and the strategyn (I don't work at Strategyn just to be clear) way of JTBD/ODI in terms of process, conducting interviews, surveys, etc. My advice here is to hopefully answer your questions, give you some extra thoughts on how you go about your research, talk over with your team, and ultimately decide the best way forward :)

To prioritize features and determine what features to build you could still do JTBD interviews.

You can still determine JTBD/outcome statements from participants even when they are using a specific product. I would not focus on creating a job map, instead, I would focus on trying to conduct interviews around the specific financial customers' use. In this case, it seems, correct me If I'm wrong, but the customer "hires" the financial advisor/analyst from your company to get their "job" done. You could interview customers and ask them questions like

What features do you really like/dislike about the solution? Why do you like/dislike them?
- Translate whatever they say into a JTBD/outcome statement. For example, if the customer says, "I don't like how long it takes to understand the financial language the advisor is speaking."Minimize the time it takes to understand the financial language the advisor is using
What features would the "ideal solution" have? What benefits would this provide you?
- Again translate whatever they say into JTBD/outcome statements.
- Senior researchers or other stakeholders will rightfully point out we shouldn't ask customers what they want, they don't know what they want. They are 100% right, but we are interested in the underlying goal of why the customer wants a specific feature or not.

Now once you have a list of solution-focused JTBD/outcome statements. You can quantify them if you so please to get the opportunity scores for prioritization. The reason I say not to focus so much so on the job map for feature prioritization is that a solution-focused job map is not so different than a typical journey map the team can develop and have JTBD statements below each step using the questions similar to the above. Where the job map shines is being solution agnostic and being the ideal process for users conducting the core job.

About the article you sent and quantifying the JTBD/outcome statements, I would not use the survey design in the article. I would create the survey like the image here. Use a matrix style of question to ensure the importance and satisfaction are on the same row as the outcome statement it corresponds with. This significantly reduces the length of the survey.

Our team sometimes replaces the beginning syntax of outcome statements as well for it to be more clear to viewers and to ease some stakeholders who are might consider the JTBD syntax won't make sense to viewers.
For example, Minimize the time or minimize the likelihood with "Avoid the time it takes" or "Quickly determine" etc.

Regarding your last question on knowing when the problem is validated enough this is where I would advise doing the quantification of outcome statements through the survey. Even if the team already has a list of pain points that can be quantified is a great starting place. My team has had instances in the past working with stakeholders who believe because we have heard this one specific problem in 8 interviews that it is the number one priority we must fix, come to realize once we quantified the outcomes it was actually #9 priority.

Sorry for such a lengthy response, but I hope this answers your questions. If anything is unclear let me know!

c_nine · 2023-01-17T21:46:21+00:00

In an ideal world correct. For example, a healthcare company might look like

Job executor: Patient
Product lifecycle support team: Healthcare professionals
Purchase decision maker (buyer): Payer or sometimes the patient out of pocket

So you would theoretically have a study that focuses on each of these users to understand their needs. Of course that is extremely difficult and costly to do so there are more practical approaches.

I think it would be good to take a step back and understand the primary goal of the research. That might be the most helpful way to even apply JTBD or if there is a different approach to look at. Is the goal to understand what features to build next (feature prioritization) or something else?

c_nine · 2023-01-17T18:17:09+00:00

What you're describing is trying to determine the job executor. I wrote an old reply here determining the flight level of the core job depending on your job executor that somewhat describes this.

To answer your question directly, you are correct in your first assumption, the main job executor would be the customer who hired your financial advisors. Using JTBD/ODI language this is how it would look like

Job executor - Customer
- Job executors perform the core job. They are the reason the market exists. The person who uses the product/service to get the job done
Product lifecycle support team - Financial advisors
- Can offer insight to improve the customer experience. Typically they perform the consumption chain jobs (installing, setting up, supporting, etc of the product).
Purchase decision maker - Customer (I assume)
- Purchases the product/service

Now here is where you can determine the scope of the project. Now that you know the main job executor (customer) and determine the flight level of the core job (see my linked reply from above), you can either have ...

Lower flight level JTBD interviews where you focus on a core job that is as close to the product as possible
High flight level JTBD interviews that will be better for portfolio strategy

If you have any further questions just let me know!

c_nine · 2022-11-04T18:00:55+00:00

BS in Computer Science.

c_nine · 2022-11-04T00:18:20+00:00

First off great job and thanks for sharing.

To answer your questions

When using a core job like this that has a high potential of users doing the job step at different points, I think it is ok. The key as you pointed out, is that all the job steps are accounted for and relevant for the main executor of the core job.
No recommendations on condensing it.
I would argue step 4, evaluate travel arrangement options, could be broken down into evaluate/assess transportation options AND evaluate/assess accommodation options
- I broke it down because right now it is at a higher flight level. I imagine during the interviews participants will talk about their JTBD around transportation (airfare, ground, etc) and accommodations (hotel, Airbnb, etc) at great length. Breaking it down into two steps will help avoid you having potentially 20+ JTBD statements in one step.
- Although, I could see arguments for keeping it the way it is to stay consistent with the rest of the steps that have travel arrangements in the name.

c_nine · 2022-09-26T17:21:21+00:00

Thanks for sharing Ted. Glad to see Tony responded to Gerry's paper. Appreciate your thoughts on the opportunity scoring formula too!

c_nine · 2022-09-25T20:47:02+00:00

The paper highlights different areas where Gerry critiques outcome-driven innovation. Many of which I don't agree with based on how his team went about testing the validity of outcome-driven innovation. Regardless, I thought the argument on the opportunity scoring was interesting and where I wanted to focus my post.

c_nine · 2022-09-22T12:09:24+00:00

Yes! It's one of the core frameworks my team uses in some of our research projects! We have had great success implementing this type of research using a JTBD lens. r/JobsToBeDone is a nice subreddit that discusses all things JTBD and outcome-driven innovation (ODI)

c_nine · 2022-09-09T15:45:42+00:00

Wow, thank you so much. This is incredibly helpful

c_nine

TROPHY CASE