Case Study: User Centered Product Planning

TL;DR

1. I spotted an opportunity to drive a user-centered process
   1. My UX team and I identified that there was an under-organized roadmap for the product we were working on.
   2. There was a need for alignment between lots of stakeholders - including two different business units with different priorities.
   3. After a year of disorganization, the product team was craving a new way to look at things.
2. The UX team - led by myself - took action to take advantage of the opportunity by planning a F2F meeting
   1. We collaborated with our stakeholders to create a user-centered planning process for the upcoming face-to-face (F2F), which was going to define our strategy for the next year.
   2. Our product UX team facilitated the process through the F2F - guiding the process and keeping us focused on the users we aimed to serve.
3. This resulted in a user-centered product roadmap, an increase in trust within the team, and UX positioned as thought leadership within the product team.
   1. Achieved both short-term results - delivering the information needed to proceed with product work.
   2. Key stakeholders continuing to see the value of the work we did 1+ years later.
   3. User centered and data-driven processes continue to be used on this team.

My role on this project

Principal UX Designer; The team lead for Red Hat Enterprise Linux Management Services, leading a team of 6 designers and 1 researcher.

This case study takes place in April 2023.

I conducted a follow-up study with stakeholders in March 2024 to reflect and retro specifically about the planning process's affect on the entire year's work (after we had delivered the release we spent all this time planning!); and I have also included information from 2025 showing the long-term value of this work.

Why UX people should care about this case study

User experience (UX) designers are often engaged after some initial planning and scoping has been completed. However, user experience practices have the ability to impact product direction, through bringing a user-centered and data-driven view to early planning stages; and helping teams solve the right problems, the right way.

My team and I saw an opportunity to use UX insights & user-centered techniques to effectively guide the planning and prioritization of new features and experiences through collaboration with product management and engineering stakeholders. And we didn't let it slip through our fingers.

Let me tell you how I did it.

The Problem, and The Opportunity

Red Hat saw a market opportunity to provide hosted management services for Red Hat Enterprise Linux (RHEL), and had kicked off a project for this opportunity one year before our story takes place. In that year:

• The project hit problems with roadmap alignment between the 2 different stakeholder business units
• The target user, as originally defined, had proved difficult to find
• There were business issues - a delayed GA release, and significant pricing changes, leading to an air of uncertainty within the team
• There were trust issues between engineering & product
• The 2022 planning meeting had had more friction and inefficiency than preferred - everyone wanted to avoid that this year
• And there were so-many-stakeholders for this project (50+ just at the F2F!)

We had been working for a year, and even though we were constantly busy, nothing was seeming to move the needle forward on getting aligned and focused.

In April 2023, I had returned from a maternity leave with fresh eyes and energy. And noted that while lots of work had happened in those 4 months, all the exact same challenges were still in place.

The planning process for our next release had just started - there was a F2F meeting planned for 6 weeks away - but when I caught up on what was being planned, I saw that the drafted schedule and topics were not targeted at solving the team challenges and improving our process to be more aligned, but were likely to lead to the same problems we had during our last planning (rat-holes, distractions, and friction).

I reached out to the engineering manager who was the owner of the schedule and offered to help solve these problems – and he enthusiastically accepted the help.

Which is when I, and the rest of the UX team, really took this and ran with it - bringing engineering and product management along the way - to create alignment and vision through user-centered practices in planning.

Planning process

My team and I approached the planning process in a highly intentional and deliberate way, in order to meet our goals of team alignment and user-centricity:

• Understand and define the problem we're trying to solve
• Work with our users (our stakeholders!) to understand this problem and their points of view
• Determined goals for the planning and aligned with stakeholders for agreement
• Designed each activity of the F2F deliberately and intentionally, with each item working towards solving our problem and meeting the goals.
• Guided the overall team (engineers, product, UX) to get necessary prep-work completed
  • Aligned the team on target users
• Gathered all our research together (both UX and product!) and made it more consumable and accessible
• Went through proposed features and experiences with PM with a fine-tooth comb, aiming to have as many questions answered before we got to planning as possible.
• Did initial introductions to concepts such as User Outcomes - the user research technique our UX team had chosen to validate assumptions.

The UX team (with engineering and PM) did this work in 6 weeks, and re-prioritized our work to make the planning-of-the-planning our highest team priority.

Planning goals

Our product team established the following goals for the planning meeting:

• At the end of our meeting, we must have a plan for what experiences we were going to build for our product over the next year
• And in order to avoid and work around known challenges, each defined experience must:
  • Solve problems for the target persona; and solve it in a way that Red Hat can provide unique value
  • Be understood and accepted by the entire program - no more competing priorities and ideas - we needed everyone to understand what we were building and why
  • Have defined success metrics so that we could determine if and when we were successful in solving the problems.

Intentionally planning activities

We made sure that every activity we proposed or planned was treated with the same scrutiny that a UX team would give any artifact - intentional design, user-centricity, and critique to ensure we were solving the right problems.

• For each activity that we wanted to do, we defined out the goal of the activity and the required outputs
  • Each output must be used either to feed subsequent activities, or was used as a planning artifact after the meeting was over
• We identified any pre-requisite information that needed to be communicated to the larger team, and set specific dates and deadlines for these. Any prep work that was required also was identified during the planning process and due to the quick turn around, had to start being done immediately!
• For designing the activities, we utilized the knowledge we had between UX, the agile team we had at Red Hat, and good old-fashioned feedback-and-iteration.

The Agenda

Here is the agenda we implemented. Items in light blue were planned & run by UX. Items in dark blue were planned by UX, but run by another group (PM or Engineering). (There are no other colors.)

We designed this agenda so that we would keep the user at the center (starting with our users and an empathy workshop) and build subsequently on this foundation to end with common consensus on what we were aiming to build.

The F2F Meeting

When we gathered all 51 of the stakeholders, representing 5+ countries and all key roles (PM, Dev, UX, QE, Docs, Marketing) at Red Hat HQ in Raleigh, NC, we got to work.

In order to support all the activities that we had planned, and keep this large group focused, on-track, and user-centered, my UX team recruited & trained 5 dedicated facilitators from other parts of the UX organization to assist.

Working through the planned agenda, we collected outputs both in-person (post-its, of course) and in a hybrid setting (a dedicated Miro board template designed for the activities – all the in-person artifacts were moved to this same template for reference after the meeting, and these completed templates were used to populate our Jira artifacts).

The team left the F2F meeting with 5 planned features to deliver.

After the meeting

We had centered the team on our user, their outcomes, what success was, and a high-level view of how we wanted to achieve this.

My team and I continued to drive planning with the follow-up activities:

• User story mapping - Defining each “value slice” to deliver for user value
  • Conducted with PM & Engineering virtually
  • Refined our experiences into deliverable chunks (agile!)
• Metrics ownership - Keeping metrics part of the definition of our experiences
  • UX part of monthly data collection & analysis, which included business, engineering, and UX metrics
  • UX led the definition of "when we will stop" when user value is not being shown (agile!)
• Outcome refinement - Validating assumptions with research
  • UX conducted discovery interviews with target users on user outcomes
  • Generation of outcomes from features & research
  • Outcome survey was completed Sept 2023, which validated (and invalidated!) many of our assumptions and allowed the team to pivot

Immediate result of planning process

The immediate positive results of this planning process were clear:

• We had program-wide alignment of what we were building for our customers, why it was important, and how we wanted to approach
• The UX team gained trust and influence from this group due to the clear answers the team had at the end
• The product management and engineering teams also received positive feedback from their leadership & stakeholders on the smoothness and clarity of the planning (we wanted our whole team to look and be good - so this was a great result)
• All the artifacts we created during the planning cycle were used immediately, and nothing was wasted. (A testament to how intentionally we had planned out how and when all our outputs would be used).

Impact of this planning 1+ years later

After a year of acting on the results of this planning workshop, I reached out to stakeholders to reflect and retro upon how the work we did affected their entire year's work - and the work continued to be seen as valuable:

“I can't overstate the impact of the F2F to the success of the conversion work. The F2F set me up with my roadmap for Q2/Q3 '23.”

“Very valuable sessions! I believe Red Hat got a return on this investment and then some!”

“If I were to do anything differently it would be about follow-up activities to make sure this was more a part of our regular development, as opposed to a one-off”

The work my UX team and I did to define user-centered experiences and deliver usable artifacts was worth the effort.

(If you're looking to do this yourself – we did in find in retrospect that looking at 5 experiences was too many and we should have focused on less; and also our agenda should have worked in more time for technical and architectural discussion, perhaps as a breakaway for lead engineers while the rest of the group worked on other aspects).

The activities rated as most impactful & essential were (in this order):

• Initial customer journey maps
• Metrics definition 
• Persona definition and review
• User story mapping & value slicing

Impact of this planning 2+ years later

The work we did in 2023 continues to be highly relevant to 2025.

Earlier in this case study, I mention the User Outcomes work, which both validated - and invalidated - some of our assumptions.

One of these assumptions - that our customers needed a feature that allowed them to provision systems to public cloud providers directly from our management solution - led to an experience that was built and delivered very quickly by the product team.

But when our user outcomes research came back in the fall of 2023 - we noticed that this assumption appeared to be false. The user outcome associated with this feature was found to be "Overserved"

Because the feature was already implemented, the team decided to proceed with launching it, and seeing how it performed re: its defined success metrics.

Since the launch of this feature, it underperformed it's metrics, triggering the "stop" evaluation that UX worked with engineering & PM to define shortly after our planning process.

In short, the evaluation framework was:

• All features must have success metrics
• Success metrics will be checked in at different points:
  • 3 months in - If under-performing, try a different marketing tactic
  • 6 months in - If under-performing, cont. iterating on marketing, consider additional functionality needed
  • 12 months in - If under-performing, make decision to stop or significantly evolve.
• "Evolve" the feature if we believe we're solving the right problem in the wrong way; and "Stop" if we believe we're trying to solve the wrong problem (or we don't think its worth solving the problem another way).

The team has put multiple features through this framework (some being evolved, some being stopped; all things built before the 2023 planing).

But – we are now looking at the first under-performing feature from the 2023 planning and determining if we will "stop" or "evolve" based on its performance.

The UX research my team produced is a core part of this decision making, leading to stopping the feature.

Its never good to miss the mark, but the framework my UX team and I developed with stakeholders, plus the UX and user-centered research that proves its the wrong problem to solve, will save our product team time and energy in maintaining a product that doesn't work, and allows us to simplify our user experience to remove a feature that doesn't resonate with customers.

The impacts of centering the user, and centering the right problems 2 years ago is still being felt in our processes today!

Wrap it up

• An opportunity to influence product direction can emerge at any stage of the development process - and you should be prepared to take advantage of the opportunity as you spot it.
• By recognizing these opportunities and actively engaging with PM and engineering teams, UX designers can bring their unique insights and expertise to bear on the planning and prioritization of new features and experiences.
• The successful collaboration between UX, PM, and engineering teams showcased in this case study underscores the importance of empathy workshops and early involvement in the product development process for creating user-centered solutions that meet both business and user needs.

What does that badge mean?