Leave a comment
Get the GH Bookmarklet

Ask GH

How did you discover the Jobs to focus on? How did you articulate those Jobs? How has it shaped and affect you current product development process?

  • AM

    Alan McAlpine

    almost 3 years ago #

    Hi @philipla 👋 - great question (and one that's forced me to dig into the Curve archives a little)! I'll try and run through those questions:

         1️⃣ How did you discover the Jobs to focus on?

    As @timdechau pointed out, it depends a little on the stage of your product. The way we've been doing it at Curve is starting from the top, i.e. with JTBD interviews. If you've not yet got a product out , maybe select people using what you assume to be your competition (taken with a pinch of salt) and ask them more abstractly about the progress and motivations behind picking up *that* competitor.

    If you've got a product out there, try and talk to people who have been displaying both the traits of a *sticky* user, and those of a *churned*/ *bad* user to see where the points of convergence/ divergence arise.

    A starter for 10 is this script (see reading list), but I'd add questions such as: (a) At what point did you realise that you needed XXXXXX to solve a problem for you? (b) and what did you feel this problem was at that time? (c) How’d you get around this before? Can you tell me about the solutions you tried? (d) Did you have any anxieties about purchasing XXXXXX? (e) What could we change to better meet your needs?

    -- these questions help flesh out the big issues and anxieties/ kick-ass points. From here, you get a better sense of the progress that your (potential) users are trying to make. From here, you can start articulating those forces of progress and the "jobs".

    Sample size? You can learn a lot from 15 - 20 users at hour long interviews.

    📚 Reading - if you're into that:

    *"When Coffee and Kale Compete" (A. Klement)
    *"The Mattress Interview" (Jobs-to-be-done [dot] org) - http://jobstobedone.org/radio/the-mattress-interview-part-one/
    *"Script to Kickstart your JTBD Interviews" - https://jtbd.info/a-script-to-kickstart-your-jobs-to-be-done-interviews-2768164761d7

         2️⃣ How did you articulate those Jobs?

    [Disclaimer] - we're working on this one at Curve at the moment, but I'll share my thoughts so far.

    One of the best practices I've come across is to start with a classic affinity map, grouping the responses to your surveys by a sorta theme. You might want to focus on the following:

                Context: Discrete situations in which users hired or fired solutions
                Struggle/s: Challenges faced in the above contexts
                Progress: How users (wanted to) make strides toward their goal
                Hiring Criteria: Pre-requisites for hiring a new tool

    From there, clump together these "job" themes in order to see what the job is (a) "more about" and (b) "less about" - absolutely factor the functional elements of the jobs into here as well as the social and personal ones, too. These may vary a lot between your users, so be ruthless with how you word them and which ones you keep.

    📚 Reading - if you're into that:
    *"Job Stories from JTBD" (Intercom) - https://blog.intercom.com/using-job-stories-design-features-ui-ux/
    *"Two JTBD Rules for Customer Motivation" (Alan Klement) -https://jtbd.info/two-jtbd-rules-for-customer-motivation-6fe471fb21d9
    *"JTBD..." (Geckoboard) - https://www.geckoboard.com/blog/jobs-to-be-done-customers-product-development/#.WWPFl9PytMI

         3️⃣ How has it shaped and affect you current product development process?

    [Disclaimer] - we're working on this one at Curve at the moment, but I'll share my thoughts so far.

    Job Stories seem to be the most valuable, here. Once you have a set up of: "When I __, {VERB} me __, so that __." it becomes much easier to pick out the big unmet needs and plug solutions in.

    I'd recommend being solution agnostic when writing job stories down, as it will bias your designs. When designing new features, keep doing that litmus test of "am I helping users overcome XXXXXX struggle?" "have I taken into account YYY and ZZZ anxiety or existing habit?" etc. - coming up with ideas from there is almost natural!

    Whilst I can't say much for the development process specifically, having the Job Stories written down and perhaps accompanied by micro-user-personas will mean that developers, designers, and marketers have a common language of the problem statement and solution story w.r.t. your "jobs".

    Once you have an MVP ready, check that back against the litmus test mentioned above, and possibly follow up with the users using the same questions you used earlier, to see if this future product is one they'd "fire" a solution for and use everyday.

    📚 Reading - if you're into that:
    *"Replacing User Stories w/ Job Stories" (A. Klement) - https://jtbd.info/replacing-the-user-story-with-the-job-story-af7cdee10c27

    Still with us? Hope the above helps!

  • MM

    Marni Melrose

    almost 3 years ago #

    I use the product management software called Aha to collect ideas from my client's customers as well as internally. They then get graded according to the ICE method. From there they will go into a backlog and get graded again depending on the type of thing it is. From there they will be allocated to a sprint cycle.

    Hope that helps.

  • TD

    Timo Dechau

    almost 3 years ago #

    It depends a little bit about the stage of the product.

    But I usually start with the JTBD interviews. The target group depends on the stage. If I have no customers yet I would search for potential ones. If I have Customers then I would look there. Check out http://5by5.tv/criticalpath/146 how theses interviews could look like.

    After the interviews I will come up with potential job stories mainly focused on the emotional struggle. Then I would think about possibly features that could help to overcome these struggles.

    This will become my test backlog.

    And than it's time to build a MVP.

  • CA

    Carlos Abad

    almost 3 years ago #

    We incorporate Sprints during our projects to come up with JTBD that we think our customers have and create a small prototype to them test it with them and validate the JTBD.
    After we know the JTBD and have some comments and suggestions from customers we create a small experiment to validate with a larger crowd and test it before incorporate them in our next Sprint.

  • AC

    Anthony Capetola

    almost 3 years ago #

    SCRUM - and while some software has been used purely for ease of communication/tracking, the foundation of SCRUM remains constant throughout not only our product development but also a number of other processes etc.

  • SC

    Shengyu Chen

    almost 3 years ago #

    On a broad level, the scope of the study is very important since each and everyone of the jobs relate to some other jobs. If scope isn't well defined then you'd end up with a very long list of jobs.
    Next, to define the scope, understanding the intents of the study is very important. For example, is this study focused on solving a specific question related to the current product? Or there's no product in place and the study is simply a discovery process? Either way, there's a underlying core problem, though may not have been very well defined. Try to think about the core issue and then follow the following steps to map out the list of jobs.
    Tactically, the following is a list of the things that would help:
    First you'd need to know what the list of jobs are and their frequency. (A job can be defined to be a group of tasks conducted to achieve something. There's a sequence to the tasks. A job may allow multiple different sequences. The job of creating a Monthly Sales Report can start with gathering the sales data, inputting into excel and so on and so forth. It can also start with looking at the previous monthly sales report and copy the template. The frequency for that job, as hinted in its title, is monthly)
    Second you need to figure out how these jobs relate to each other from a dependency and flow perspective (e.g. job 2 doesn't initiate until job 1 is drafted, passed the initial review with the stakeholders, finalized, and published the data to the downstream system. so on and so forth)
    Third, you need to fill in the details for each of the jobs from the technology standpoint, the deliverable standpoint, the key parties/entities involved, and the so on and so forth. (E.g. what are the tools used for each job. What are the inputs for the job, what are the outputs for the job. Who's involved in every step along the way.)
    Fourth, looking at the laundry list or map of the things, you'd get a pretty prescient idea of what jobs are important relative to the problem you are thinking about. That is finding the bottle neck.
    Fifth, looking at the list you have made and feel proud. Then go talk to more senior people or actual parties involved in this process to validate and iterate on these items. Voila! You then feel like a genius by asking yourself and these people why they are forming the jobs and so on and so forth. You'd find a lot of interesting insights there. Keep on asking why.

    At last, the jobs to be done list is incredibly important to the product dev process. A living and breathing jobs-to-be-done document shared and constantly updated to account for different contexts and scenarios will help you catch the aha moments and help develop the product into things that people will actually use.