Farfetch — Understanding the jobs-to-be-done of luxury fashion merchants

Overview

At Farfetch, the largest luxury fashion platform, I developed a model to catalogue the goals and needs of luxury merchants that use our B2B tools. This became the backbone of our research repository, and organise teams and tools around customer needs instead of technical solutions.

Problem statement

It started from a simple phrase: “know the purpose of our tools”, then transformed to “understand what our users need from our tools”, to focus more on the users than the tools.

I advocated to the team that if we could clearly say what the most important user needs are, we could start to question if we have the right tools, spot duplicates or disjointed journeys and ask how well each need is served.

Users and audience

• The core audience for this work was product trios (design, PM, engineering) to help make more customer-centric decisions about the direction of our tools.
• If this went well I hoped that the framework could be used for improved communication with business stakeholders, and even users themselves through product marketing.

Roles and responsibilities

The project grew out of discussion in the design team, and I took ownership of defining and driving it, with support from my head of design and a principal designer. My primary responsibilities were:

• Researching and developing the framework, drawing on JTBD and other methodologies
• Planning and leading workshops to harvest harvest content from past research
• Evangelising the power of problem-space thinking, what it looks like, and how the content we'd built up can be used

I worked closely with two other product designers who provided tons of feedback including running some workshops to validate with customer-facing teams in their area.

Scope and constraints

I knew there could be a risk of huge scope so I ensured to get aligned with the rest of the design team on the scope, and we agreed to keep things quick:

• to harvest and normalise user needs from previous research (no new primary research)
• to focus on one customer segment to start with (boutiques), excluding big brands and enterprise customers
• to focus on needs that are primarily currently served by digital tools and exclude human and operational processes which are covered by the operations and service design teams

We believed this would provide good material to underpin future strategic projects to spot new opportunities, evaluate product quality and understand where our org chart might be undermining the experience (Conway's Law).

Process

1. Selecting a draft framework

Researched a few frameworks such as Mental Models (Indi Young), JTBD (ODI vs Switch), Goal-directed design (Cooper), Use Cases (Cockburn).

While the content is more important, I felt that a good framework would help us capture needs consistently, disambiguate between the different types of need: pains, functional goals, broad aspirations, underlying human needs, qualitative success metrics. I followed most closely the framework in Jim Kalbach’s The Jobs to be done Playbook because it seemed to tick most of these boxes.

2. Gathering needs

Each area has conducted their own user research in the past, and I wanted to use what they already knew to assemble the first version:

• I held a remote workshop with designers from all areas of the B2B team
• Asked people to brainstorm alternative phrasings of the main job we are hired for, and all the smaller jobs that they know about from past research in their area
• Enforced a strict format for writing jobs (start with a verb) and outcomes (start with maximise / minimise). We then annotated with confidence level, e.g. “we know this job exists from research”, “hypothesized job - research needed” etc.

3. Iteratation

I iterated on the content, splitting and merging some jobs, and changing the way we group smaller jobs - creating “contexts” inspired by Indi Young's Mental Models. I dropped some concepts used by Kalbach: the job stages/steps which didn't seem to help with our main job (“sell luxury fashion online to a global audience”) which was more of continuous engine than a process with a start and finish; I also dropped the concept of “consumption jobs” because we were finding it hard to clearly separate consumption jobs from true jobs in the case of software tools.

4. Publishing

I created a unified map as a visual artefact and one-pagers for each smaller job.

5. Application

• We aligned questions in our annual partner survey to the jobs-to-be-done defined here, so that we could start to gather quantitative feedback on which jobs were being best or worst served
• We used the jobs to frame an experience vision in an area
• We added new outcomes when we learned of new needs and used updated jobs statements to frame new initiatives

Outcomes and Lessons

Outcomes

• The framework has been adopted by customer insights team as the backbone for our knowledge repository.
• The annual partner survey questions have been rewritten around these jobs, to start measuring how well each job is fulfilled and whether it's getting better or worse each year.
• We've started to discuss ways to better organise teams around these customer jobs rather than technical functionality and whether PMs can take responsibility for more of the job rather than just the technical pieces
• We talk about the job more frequently and confidently than we used to - e.g. price products, reconcile finances, instead of artefacts - pricing tool, financial report. I think this is evidence of us achieving one of the goals: to have a mode customer-centric way of working.

Lessons

• Kalbach's job steps didn’t seem to work for our main job which is more continuous
• People interpret the words “need” and “job” differently, but “goal” is quite unambiguous - maybe next time I'd just use that word instead.
• People were confused between consumption jobs and normal jobs
• The names of my altitudes not self-explanatory - there was no real anchor
• Granularity was tricky but it helped to ask “how do you know when this job is done?”
• There was ambiguity how to slice jobs when there are iterative jobs or jobs with natural follow-ups between them
• I could have gone a lot further - I lost a bit of confidence to push for faster adoption of the technique, focussing in my own vertical not spreading to other verticals or to product team. But this was remedied by our amazing insights team who adopted it and pushed it much further.