Project - Clarifying a Product Design Vision

This is an example of the impact which can be achieved when you're willing to reconsider the basics of a product - does it do the right things for the right people, in the right way? This was a mid-life refresh for an already successful code development and deployment product.

Because this project concerns a product which is currently available on the market, and these updates are commercially sensitive, details have been heavily simplified and anonymised.

The essentials

The project

Design the 'future perfect' state for a multi-module product, accounting for updated Ideal Customer Profiles, and dealing with significant UX debt.

My role

Leading the creation of the vision. Combining user data and insights with opinions from multiple stakeholders. Delivering a compelling outcome to the business.

The impact

The project created a north star for development squads to work towards, together, and a practical means of measuring how close we were to delivering against the vision.

Challenges

The business hadn't ever created a detailed vision for the product as a whole, but had been commercially successful, so there was a general lack of belief this was needed. I wanted to deliver this vision because of the impact it would have on usability (and therefore revenue), but it took delicate advocacy to move stakeholders past this inertia.

Starting out

A mid-life product refresh starts the same way as a ground-up design - with a canvas.

We used Roman Pichler's beautifully clean and simple product vision board.
It was an index to relate the vision to existing artefacts (ICPs, their main JTBD and the OKRs), and new material - hierarchies of detailed JTBD and an updated product design.
The product lacked a degree of structure, so this was a key issue we set out to address.

A guiding light

Throughout the project, we tied all our work back to this initial board - if it didn't help us to fill in what we didn't know, why were we doing it? The project was so extensive, we didn't have time to waste heading in the wrong direction.

Mapping JTBD using hierarchies

We didn't start from a blank slate

The UX team had already run a research project to deliver a set of Ideal Customer Profiles with highest-level JTBD for the business, so this didn't need tackling. However, in order to connect these to the product vision we needed to build a hierarchy of Jobs-to-be-Done down to the feature level, for which we used several iterations of the GitLab JTBD hierarchy.

Detailing JTBD using hierarchies

Our 3 ICPs each had 3 highest level JTBD, so we started with a matrix of 9
Each of these became a main job, with small jobs and micro-jobs beneath
Each small job then became a main job in its own hierarchy.

Validating with users and finalising scope

We identified research themes for quarters to dive into the lower levels of the JTBD hierarchies
- Focused on themes under-represented in the existing insights repository.
We ran sessions with customers to validate our initial drafts and add detail at lower levels, in areas such as observability and day-to-day operations.
Collaborating with the product leadership team, we identified areas within the JTBD hierarchies to exclude from the design
- For example, if we partnered with another organisation to provide certain capabilities, this was identified and recorded, but excluded from the design

Making connections and adding structure

We let user behaviour define the product structure, not just the features

Our prior research showed that there was a strong connection between the activities of our three ICPs. Detailed analysis of the JTBD hierarchies made it pretty obvious that one of our ICPs (platform engineering) would have tasks to perform in every module. The work of one other ICP might also frequently feed into the work of the third.

These insights give us a starting point to make decisions about the structure of the unified app. All this came from talking in-depth with users about their day-to-day work.

How did we use these insights?

We sketched out a simple structure of the application, before adding features suggested by the JTBD hierarchies (I'll show how below).
We made sure not to overlook a basic product layer for all those day-to-day things users expect - the ability to log in with socials, some sort of 'home' where they could find their stuff, profile settings and so forth.
- This allows the application to hang together coherently. Don't rely on navigation panels for this.

Making the vision a valuable living document

Getting to feature level for real impact

Knowing which features we wanted to create (and where) in the product would give us a practical way to measure how close to the ideal product we were. This gives the product vision intrinsic value, rather than just being another planning box ticked.

How to determine features from JTBD hierarchies

Create logical groups of JTBD from the lowest levels of the hierarchies created earlier
For example: there may be several places in your JTBD hierarchy where the job is a variant of "connect a third party system". Unless prevented by an overriding usability or technical hurdle, it makes sense to gather these into an integrations management feature.
Every JTBD must appear in at least one feature, and some JTBD will pop up in multiple places, for instance if there are two routes to the same goal, but for different audiences.

Job to be done hierarchies feeding feature level items into the overall product structure diagram

Creating user journeys, too

The role of the product vision is to deliver a high level 'north star' the product can develop towards, but a side-effect of using JTBD hierarchies is a head-start on creating use journeys.

The JTBD hierarchy of main job - small job - micro-job maps quite neatly to the journey map structure of journey - phase - activity.
This isn't a complete journey (because it ignores things like branches, loops, error paths, and so on) but it's a good starting point for the golden path.
The detail behind the JTBD title (the "When I am... I want to... So I can" content) is used to add detail to the journey map (e.g. ordering of activities, success criteria)

We started using the vision to tackle creation of ideal journeys, which could then be validated again with users, and used to establish the usability element of the product's maturity, using the model I laid out in this article.

Then, of course, they could be used to design the future.

Rounding off the project, and next steps

Getting buy-in from stakeholders

At this point the vision was functionally complete, because the next step was going beyond the planning phase and into implementation, where we would assess the fitness for purpose of the current application and start to build a plan for closing the gaps we found.

So we went out to key stakeholders to get approval for the vision. There was a gentle process of introducing the new vision to groups of people, starting with the senior members of the product team and fanning out across the business.

Because we'd been open and collaborative with this work, and not hidden what we were up to, the process of approval was simple, more of a next step than a big step.

The impact of the completed vision

A clear 'north star' for development, and a tool for roadmapping
A living document for assessing product maturity, and planning work to fill gaps
An accessible repository of JTBD
First steps to creating full set of ideal user journeys