Empowering product teams to shift from an output to outcome based model

In projects, we often start with high-level business requirements, which are then passed to teams responsible for creating design deliverables aligned with a business vision. However, these requirements often lack context or are relayed through executives, buried in vision documents, and then filtered down by product managers to designers.

Designing without the context behind objectives, KPIs or business visions, obscures problems and opportunities, confining creativity to predefined business goals. Many of these teams gauge success by feature releases, where performance is quantified by 'did you ship it.'

This approach tends to necessitate expansive scopes of work and deviates from agile or lean models which can introduce risk, especially when market/economic shifts or the discovery of new user needs demands a project to course correct.

Should we really be celebrating the realisation of features where as we begin to learn more about our users through discovery, we get to a place where we know their needs and specific outcomes that we can help them achieve? As a lean UX advocate, I’ve always been drawn to an outcome-focused model, driven by continuous customer discovery and data, which I find better defines success than feature launches.

When initiating projects, I like to reintroduce the context to our work and how instead of focusing on what we ‘need to deliver’, we work out what we should focus on first, what we can hypothesise to be true and how we can best use discovery to prove these hypothesis right of wrong.

I can usually get our team aligned to this idea within a series of workshopping activities, inspired by some common agile/lean UX methodologies.

Prep work

In anticipation of our upcoming workshop, I usually provide my team with a lead time of about a week. During this period, we focus on gathering material to ensure the workshop's success. The groundwork involves:

• Senior stakeholder interviews: Understanding their perspective in the wider context of the organisations roadmap and to obtain detail on previous attempts to address this problem and where this may have failed. I’ll usually conduct these interviews myself.
• Data insights & analytics report: Understand the current product so we can understand how it is performing down to a feature level
• Competitor analysis: to see how the market has gone about tackling a similar problem or issue
• Research & Usability Reports: We explore recent research and usability reports related to the product and the broader market.

Framed around hypotheses

I begin by sharing the template we'll use to generate our hypotheses. This gives the team a clear workshop focus. By setting this early context, I ensure everyone stays aligned with our goal of creating a number of testable hypotheses.

Prep work playback

I’ll usually begin by letting our team playback any of the items we marked as important to prepare for the workshop. Stakeholder interview playback, generally give the team an idea as to where our execs thoughts lie in relation to our proposition but give us a little bit more context as to why we are doing the work and what they think it will help the business achieve.

Data insights and analytics give the team an understanding as to how the product is performing and can often influence us later on down the line when we brainstorm metrics to measure our solutions.

After working at a number of ‘legacy’ financial institutions over time, I’ve found that competitor analysis usually identifies any noticeable gaps between what their product is doing compared to the ‘challengers’. This also is nicely supplemented by any recent market or primary research that has been conducted internally, giving the team a good holistic view of the sector or market we’re working in.

Business objectives/OKRs/KPI’s can come at the start or the end

What is so important with moving towards an outcome based approach is that we need to identify a way to objectively measure the success of our solutions so we can confidently say whether we’ve met a desired user outcomes instead of simply giving ourselves credit for releasing individual features. Depending on the client or project this initial exercise can take place at the start or at the end of the workshop. If I’m working with a team who is already well organised with metrics and measures that they really want to target then I’ll run this exercise at the start. If I’m working with a team that needs more guidance or will benefit from brainstorming features/user outcomes first of all, then I’ll leave this to the end.

If the team arrived armed with specific and high level business outcomes then I’ll ask the team to brainstorm ways in which we could break them down and how certain measures could help predict a realisation of the overriding ones. If teams are struggling with this exercise, I sometimes present the typical key stages within a product funnel (acquisition, activation, retention, referral and revenue) which usually inspires the team to generate some ideas which can relate to a stage of the funnel.

Dot voting on the identified business metrics is quite important to focus the team around objectives as we move through the workshop and providing a super vote to our overall decision maker, usually the senior product owner, can support this as well.

Who are the users?

Depending on the context, the client might or might not have existing personas. However, the main goal of this opening exercise is not to create complete personas, but to identify the user types we should be focusing on. We'll also use any additional insights about our users from the folks in the room or previous findings to highlight the needs and pain points of each user type.

I'll address concerns about crafting personas, which can sometimes require an entire research study to develop, by emphasizing that our work is part of a 'living document' (or a FigJam board). It's perfectly fine to make preliminary assumptions at this stage, as we'll refine and enhance our understanding of users over time.

In the workshop, we'll sketch out personas on paper or use sticky notes in FigJam, if applicable. Even at this early workshop phase, this exercise effectively establishes a shared understanding among the project team—an essential step moving forward.

What are the user outcomes

The persona exercise is a stepping stone toward the next phase of our hypothesis statement—where we pinpoint the necessary user outcomes to achieve our business objectives. Building on the insights gained from the previous exercise, we recognize that users typically have specific goals in mind when engaging with your product or service. With this foundation, I'll guide the team through some fundamental questions to delve into the core user outcomes we intend to focus on:

• What is the user striving to achieve?
• What drives and motivates the user?
• What emotions does the user seek to experience during and after using the product or service?

As is our approach, utilizing sticky notes, affinity mapping, and dot voting enables us to seamlessly progress into the next exercise armed with a range of user outcomes we aim to address.

Ideas

This is at the point where with an understanding of our users, their needs, and business objectives, we can think about the features that will support these outcomes .Typically teams enjoy this activity, (well, it generally generates the most stickies) stakeholders will have plenty of ideas and I like to encourage some blue-sky thinking here.

We’ll usually group ideas into themes but I’m not so focused on dot-voting here as in the next exercise, we’ll get the teams to choose which feature idea they think can help us achieve some of our business/user outcomes.

Putting the statements together

Finally, we’ll take a look at the outcomes we've gathered from our earlier work and shape them into testable hypothesis statements. A flexible approach tends to work well here, especially in face-to-face group sessions where people can freely combine and rearrange sticky notes. I'll set a time limit for this step, and we usually end up with around 5-10 hypothesis statements. Occasionally, we might lack the precise business metrics needed to measure certain features or outcomes, leaving some gaps to address in the activity.

In cases where a significant number of features generated in the previous exercise might align with the same outcome or metric, I sometimes guide the team to rank features based on their potential to achieve specific outcomes. This helps us either refine features within statements or create separate hypothesis statements as needed.