Categories
Events Research

JTBD for Health meetup wrap-up

Last Monday saw a great crowd of almost 30 people turn up at Brain Mates to hear Justin Sinclair of Neo speak about a health case study at the JTBD Sydney Meetup.

Justin shared how Jobs-to-be-Done research was applied to investigate customer needs and behaviour when choosing a health provider. His client had hit a crossroads in the development of an online solution for provider selection and decided that some customer centred research was needed.

Some background to JTBD (and the case-study)

For those unfamiliar with JTBD, it is a research technique that focuses on the moment where a customer has made an explicit choice to switch between one product or service to another. The underlying rationale being that all priorities have been crystallised in this moment of decision making which can then, in turn, inform product development.

For the health study, Justin and his team from Neo recruited customers with a range of health needs who had chosen new providers.

The next fundamental concept of Jobs-to-be-done is the job itself which in JTBD terms is framed as a problem that a product or service is “hired” to solve.

The problems discovered in the health study went far broader than diagnosis and treatment. The problems involved the whole experience; some examples:

  • The convenience of location and appointment times.
  • Cost, and lack of information around insurance.
  • History of information with an existing provider as a reason to stay and a barrier to change.
  • Comfort, trust, and alignment of values between patients and health practitioners.
  • Questions of expertise and credentials of health practitioners.

The research successfully illuminated the customer journey. It also posed a challenge because the importance of all decision making factors and touchpoints varied significantly depending on whether the patient had chronic needs, a new serious illness, a minor illness or was simply organising a check-up.

Applying Jobs-to-be-Done to customer research

Jobs-to-be-Done was incorporated into the research discussion guide and all researchers received training in how to do a “switch interview”. Group analysis was done using the “Four Forces” model: looking at the forces driving a customer to a new solution and the forces that are holding them back.

In this case study two of the four forces in the framework – habit and anxiety – proved fundamental to understanding customer choices and the difficulty faced by the client’s solution in trying to solve far-ranging problems with their online product.

So consider for a moment that this approach seeks to find and define customer “jobs” in order to make products that do those jobs. What was most fascinating to me was hearing about the challenge the researches faced in framing the job at the right level. Defining the “job” too broadly, at too high a level, gets us insights that aren’t actionable. Defining a job too narrowly or specifically categorises customers by type and fails to capture the needs of the behaviour around the task or job of choosing a provider.

Interestingly for the client, the research brought into question the fundamental value that this product was bringing to the market. The product is now on hold maybe because of this insight: “Discovering a job isn’t enough if you can’t viably solve it.”

Questions from the audience

I think what I am beginning to like most about Jobs-to-be-Done is the diversity it attracts. We had user experience designers, product managers, and developers in the audience. Their questions reflected how diverse these disciplines can be in their approaches. We had side conversations about personas and the value of qualitative research versus quantitative research.

It’s difficult to baseline the understanding of such a wide audience with a new toolset. Jobs-to-be-Done is quite jargonistic to someone new to it. This made it all the more valuable to hear about it applied in practice and also shows how much awareness and education around this and related techniques are needed. Which is the reason for the meetup so come along to the next one Monday July 13.

The Jobs to be Done Sydney meet up was founded by Christian Lafrance and is organised by Christian and yours truly. 

Follow Justin Sinclair on Twitter at or check out where he works at Neo. Thanks to Justin and Neo for sharing your work at our meetup. 

New to Jobs-to-be-Done. Check out http://jobstobedone.org/

Thanks as ever to our hosts and event sponsors Brain Mates

Categories
Design Events

Meetup wrap up: Product Roadmaps, what are they good for? at Product Talks

I’ve not yet been responsible for a roadmap but I have certainly fed information into them, so I was very keen to check out yesterday’s meetup and hear from a panel who disagreed and agreed on the merit and use or uselessness of product roadmaps. The panellists were

  • Michael Pearson, Director Product & e-commerce at Expedia
  • Michael Bromley, Head of Digital Strategy and Chief Innovation Officer at SMS Management & Technology; and
  • Chrissie Zenonos, Head of Product at Mi9 (Channel 9)

While the panelists weren’t in perfect alignment they generally agreed on the following.

What is a product roadmap?

  • A communication tool
  • A list of priorities

What should a product roadmap communicate?

  • Needs, problems
  • Goals and objectives
  • The business value to be delivered
  • The vision
  • The capability

How should a product roadmap behave?

  • It should be flexible
  • It should accommodate a test and learn approach

What value do product roadmaps provide?

  • Provide visibility to different teams to enable them to align to a singular vision
  • Show how everything fits into a greater scheme, to provide context
  • Provide clarity to tackle ambiguity

What a product roadmap is not, or should not be or do

  • Should not be a features list
  • Should not describe granular detail
  • Should not explain how something is to be delivered

The aversion to product roadmaps was best expressed by Michael Bromley:

“Because I can’t predict the future I don’t try.”

And with technology and the market changing so rapidly its easy to see why people need to work in differently. What the panelists had in common was a way of working which was flexible, agile, and iterative, applying a test and learn approach. From what I could gather Michael Bromley, of SMS and Chrissie Zenonos of Mi9 could do away with the traditional concept of a product roadmap deliverable because they worked with co-located teams. They used walls of post-its and the business model canvas as alternative tools. Michael Pearson of Expedia, unlike the others was still an advocate for product roadmaps. He works with distributed teams of developers and needs to communicate the wider context and timelines to engineers and call centre channel teams who need to know when a feature will drop. His version of a product roadmap is a JIRA workflow where the hypothesis to test eventually becomes the code then the feature.

My big takeaway was realising that so much documentation—product roadmaps, feature lists, test schedules, project plans, even the business case—are really communicating the same thing. The challenge is rationalising tools that so many feel so comfortable with to avoid duplication, focus on communicating the vision, and work iteratively and flexibly towards achieving it.

Product Talks is a meetup organised and hosted by Brainmates for Product Managers. Their next topic “Is UX a Part of Product Management” will be on 9 June.