Ask your product teams about the business context to design better solutions
I never really “got” the Product team until I spent a week workshopping with them.
In Continuous Discovery Habits, Teresa Torres talks about a trifecta of decision-makers at the core of every team:
- UX, who are making decisions about usability and the user experience
- Engineers, who are making decisions based on technical workload and feasibility, and
- Product Owners/Managers, who make decisions based on the business needs
Yet most of my detailed interactions as a Senior UX Designer tended to be with the Engineers. After all, there’s a design handoff, documentation, and built-in interactions within our design process to talk with them.
My interactions around Product, until recently, were those of getting ideas rejected, timelines adjusted and working on the Agile Backlog. In addition, many of my Product Managers were new to the job, meaning they often didn’t clearly understand what they needed to do.
However, sitting down with them over the week taught me the one thing UX could reliably ask them about: business needs.
They’re often the fastest way to understand the business needs, wants, and problems that aren’t entirely clear.
Good product teams focus on business outcomes, not outputs
According to Teresa Torres, an international consultant focused on product discovery, there’s one fundamental mistake that many teams make around discovery: they focus on outputs, not outcomes.
Perhaps you’ve been a part of these frustrating teams (I know I have). For example, these teams might say, “At the end of this sprint, design pages X, Y, and Z.”
The “Why,” according to user research, might not matter that much. What matters is that UX creates this output on time so that Engineers can create that next sprint. On those teams, I often thought of Products very similar to Marketing:
- Product chooses Feature X and Y to focus on (which are business needs)
- UX learns about and designs Features X and Y
- Engineering later builds Feature X and Y
That’s the Waterfall product approach disguised as Agile. It only takes a single thing to throw things off (like User Research suggesting that the Business goal might not be what users want).
However, what the best Product Managers do aligns with UX processes perfectly. These Product Managers focus on long-term outcomes: what sort of change do they want to see in the business in six months or a year?
If UX is rooted in understanding what users want and need, Product is centered around the overall business needs and goals after the project is complete. Understanding this fact led me to my first realization.
Product defines the problem, UX/Engineering creates the solution
There’s a simple quote I heard from my VP of Product that helped me understand Product better:
“Product is about defining the business problem (and outcomes) as best that they can, so UX/Engineering can work out the solution.”
Product might not have all the answers, but what they know is about the business need, goals, and context you might be missing. If you need business clarification or competitors to look into, UX can ask Product about that and probably get an answer.
This viewpoint is also something to keep in mind if you find that Product is staunchly against a potential design solution. While they might be stubborn, it also could be that the design solution won’t work for the business problem.
Sample questions Product might be able to answer:
- Who are our competitors?
- What is the overall competitive market like?
- Are we breaking new ground, or are we playing catch up?
- What were users doing before this process/re-design?
- What metrics are impacted by this?
- Etc.
This mindset also helped me re-interpret the Agile backlog and how I write user stories.
What value are we delivering in sprints?
When you work closely with Engineering, you tend to develop similar work patterns. For example, this happened when I wrote user stories and managed my work in the Agile backlog.
Last week, I talked about the importance of keeping a user-centric mindset regarding user stories, but that was one-half of the picture. The other part was understanding what Product wants from the backlog.
Product Owners don’t always care about the Features and checkboxes: what they’re trying to learn is what value we are delivering.
They want to know this: after spending a sprint working on something, how much closer are we to solving that big business problem they’re aware of?
For UX, this involves answering several questions:
I’ve worked with enough new Product Owners to know that even if they’re not fully aware of how UX works, they are okay with our processes as long as they can see the value we deliver.
This matters a lot because, in the end, Product has to think about the big picture.
Product usually measures outcomes through metrics
Product teams need a way to measure outcomes at the end of the project, to show that they’ve reached their business goal. This is why they’re often concerned with metrics or Key Performance Indicators (KPIs).
This is where things don’t always align between UX and Product, but keeping that fact in mind can help you find ways to work with them.
For example, a Product Owner might be given the business problem of “Customers have rated our store badly according to the Net Promoter Score (NPS), and the majority of our Customer Support tickets are about store complaints.”
They’re therefore concerned about two Quantitative metrics:
- Improving the NPS (and other KPIs) of the store
- Reducing the number of Customer Support tickets about the store
It’s up to UX to research users and design a solution, but our research tends to be qualitative, where there might be a little friction. Product might have a little trouble understanding how insights from 5 users can lead to significant changes in the metrics they care about.
This is why UX needs to help fill in the gaps. For example, talking about the common usability problems and their impact might help Product understand that “if 5 people always encountered this issue, it’s likely that 100,000 people might as well.”
Product helps you understand the business aspects of the problem
I haven’t always had the best relationship with Product. Many of my Product teams have always been new to the role, which unfortunately led to arguments and disagreements.
However, learning more about them by sitting down with them and talking it through has shown me that I needed to understand some core concepts about what they care about and how they think.
So if you find yourself constantly getting into disagreements with Product, take a moment and figure out the business needs or viewpoint you might not be getting.
Understanding business and user viewpoints can help you design solutions that fit user and business needs.
Kai Wong is a Senior UX Designer, Design Writer, and author of the Data and Design newsletter. His new book, Data-informed UX Design, explains small changes you can make regarding data to improve your UX Design process.
