Communicating Research with Pace Layer Mapping by Adrian Howard "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 15 September 2022 True #mtpcon, Customer Feedback, Premium Content, Product Roadmap, User Research, Video, Mind the Product Mind the Product Ltd 978 Communicating Research with Pace Layer Mapping by Adrian Howard Product Management 3.912

Communicating Research with Pace Layer Mapping by Adrian Howard

BY and ON

In this November 2020 #mtpcon Digital session, Product Coach Adrian Howard introduces Pace Layer Mapping, a practice to help product teams communicate and align around user research, sharing the messy story of how the practice evolved.

Watch the 20-minute session in full, or read on for the overview.

A Messy Journey Begins

Adrian Howard’s vocation is to help companies address problems where product work, UX work, and Agile delivery overlap. He spends time finding ways to better communicate user research work and user research practices within whole teams.

In this session, Adrian describes the use of Pace Layer Mapping to address the problem of alignment for one product team. On Adian’s own site Quietstars, he describes this practice as: Pace Layer Mapping builds a common artifact that shows (a) the confidence we have in research insights; (b) what we need to do to increase that confidence, and (c) how stable that research is over time. It allows the whole team — product managers, researchers, and engineers — to come together around research insights and methods.

First Stop, The Scale of Truthiness

‘The Scale of Truthiness’, formed the first stage of the process. Adrian describes this as a user research practice to understand users and what they need to validate product decisions. “The scale of Truthiness is really simple,” he says. “It’s just a line that goes from stuff we made up, to stuff that we think is true.”

Adrian started to apply ‘the scale of truthiness’ to understand what ideas were based on assumption or fact. Ideas that were new but had no research to back them up were put in the “guess” section of the framework, while ideas with strong research to justify the idea were put towards the stronger end of the line—product ideas moved back and forth depending on new user findings.

The Scale of Truthiness framework mapped ideas based on whether they were a guess, weak, strong or true

Based on the scale, Adrian explains, everyone in the team was confident about who the customer was and what they needed. “We all had one voice — The Scale of Truthiness helped the team make smarter product decisions. They knew what ideas were based on assumptions, and what would work based on knowing it was true,” he says.

In user research we spend a lot of effort building archetypes of whom we think our target market is, this is called Personas. However, what we sometimes forget is where the real value lies. Adrian refers to Jared Spool in his quote of personas: “Personas are to Personas Descriptions like vacations are to souvenir picture albums,” he says. “It’s the experience of building the persona that provides the real value,” Adrian explains how once the team began to use the Scale of Truthiness, it exceeded beyond a one-time activity and evolved over time as the team discovered new ideas and rules for the concept.

How To Re-Model a Framework Iteratively

The team introduced a concept to accommodate ideas that were important to consider but didn’t add anything to current product decisions. The labelled these under ‘Flair’. “Somebody who’d watched too much Office Space, started calling this ‘Flair’. Those who’ve watched it will understand it but it was kind of like little badges, meant to express someone’s personality, but don’t really,” says Adrian.

In this process, he continues, “the flair is at the bottom and it contains things that may be important to acknowledge they exist but don’t make any difference in our product.”

Further down the line the team encountered issues of stability and focus while using the framework. “Sometimes we were so focused on a current customer that we missed out on a completely new market elsewhere because we didn’t have specific research on the board,” he says. Additionally, the team noticed that the pace of change of research and market conditions heavily affected product decisions, “These different cadences of activity happen at different paces, but each relying on each other. Some ideas and research points never change while others are changing rapidly.”

The team started to visualise those different areas of change by placing them vertically on the board. Ideas changing rapidly were placed towards the top while those that were changing slowly were moved to the bottom. By doing this, the team spotted how pieces of research were fluctuating on the wall.

The Pace Layer Mapping evolved into a free-flowing framework where ideas were positioned on the board based on how confident the team was that they would succeed, and how that might change. Adrian says, “It helped us to talk about how confident we are about a product, while the pace level helped us to talk about the rate of change. The framework enables us to have this conversation about how ideas change over time while keeping in mind the long-term ideas that don’t change as fast.”

Focus on the Research Process

In sharing what’s described as a ‘messy journey’ toward the best possible solution, Adrian highlights how focusing on the research process rather than the mere output is much more useful for product teams and far more informative to the solution than adopting “yet another product canvas.”

In brief, he explains how the journey of using Pace Layer Mapping, rather than the framework itself, helps to:

  • Effectively communicate user research to a product team
  • Create connections between long- and the short-term bets
  • Balance research and focus on information that can rapidly change and things that may become more relevant with time

More on User Research: