Summary
Successful product leadership starts long before the backlog, roadmap, or sprint plan.
In this article, I explore the three pillars every Product Owner, Program Manager, and UX Architect understands when joining a new organization: the challenge being solved, the customers being served, and the team bringing the solution to life. Together, these three pillars create the clarity, alignment, and impact that successful products require, but it’s only a start.
Over the course of my career, I’ve held many different titles: from Information Architect to Product Designer, from UX Architect to Product Owner, from Product Manager to Technical Program Manager, and more. While the title has changed from company to company, the fundamental questions I ask when joining a new organization have remained remarkably consistent.
Whenever I join a new team, I don’t start with the backlog. I don’t start with Jira. I don’t start by reviewing user stories or sprint reports. Before I can effectively prioritize work, define requirements, facilitate discussions, or support delivery, I take time to understand three things:
- the challenge being solved
- the customers experiencing that challenge
- the team responsible for building the solution
Over the years, I’ve found that these three areas create the foundation for everything that follows. When a Product Owner, Program Manager, or UX Architect understands all three, decisions become easier, priorities become clearer, and teams become more aligned around a common purpose.
Pillar One: Understand the Challenge
The first question I ask is surprisingly simple:
Why does this company exist?
Every organization exists because a problem exists. Somewhere, someone is experiencing friction, frustration, inefficiency, risk, uncertainty, or unmet needs. Companies are created because they believe they can solve that problem better, faster, or differently than other available options.
Before I can contribute to a product, I need to understand that problem deeply. What challenge is the organization solving? Why does the problem matter? What happens when the problem goes unsolved? What value is created when it is solved successfully?
Throughout my career, I’ve discovered that many conversations become significantly easier when teams reconnect with the original pain point. Discussions about features, priorities, and requirements often become clearer when everyone understands the reason those things exist in the first place.
Understanding the problem creates context. Context creates better decisions.
Pillar Two: Understand the Customer
Once I understand the challenge that the company is solving, I want to understand the people experiencing it.
Who are they?
Why do they choose this product?
What alternatives do they have?
What are they trying to accomplish?
Most importantly, why are they choosing this organization instead of a competitor?
Customers rarely purchase software, services, or products simply because they exist. They choose them because they believe those products will help them achieve something important. Understanding those motivations is critical for anyone responsible for shaping experiences, defining requirements, or prioritizing work.
My background in UX has repeatedly reinforced this lesson. Whether I was working on healthcare platforms, financial systems, educational products, or digital experiences, the most successful solutions came from understanding the people using them.
Features become more meaningful when they are connected to real customer needs. Priorities become easier to defend when they are tied directly to customer outcomes.
The customer provides the “why” behind much of the work we do.
Pillar Three: Understand the Team
After I understand the problem and the customer, I turn my attention to the people building the solution.
Who are they?
How do they work?
How do they communicate?
What strengths do they bring to the team?
What support helps them do their best work?
This is an area that I believe deserves far more attention than it often receives. Product development is ultimately a human endeavor. Engineers, designers, researchers, analysts, architects, stakeholders, and leaders all bring different experiences, perspectives, and working styles to the table.
As someone on the autism spectrum, I’ve experienced firsthand how differently people process information and communicate. Some people want detailed documentation. Some prefer diagrams. Some want collaborative workshops. Others prefer time to think independently before responding. None of these approaches are inherently better than the others. They are simply different ways of working.
Understanding those differences has become an important part of my leadership approach.
The goal is not to create a different process for every individual. Teams still need structure, consistency, shared tools, and common expectations. The goal is to understand how people learn, communicate, and contribute so that the team can work together more effectively.
People are not interchangeable resources. They are individuals bringing unique strengths to a shared mission.
How the Three Work Together
The reason I focus on these three pillars is because they are deeply connected.
- The challenge explains why the organization exists.
- The customer explains who the organization serves.
- The team explains how the solution comes to life.
When one of those areas is missing, challenges often follow. Teams can build impressive features that don’t solve meaningful problems. Organizations can lose sight of customer needs. Leaders can create processes that overlook the people responsible for delivery.
When all three are understood, however, something powerful happens. Teams gain clarity. Decisions become easier. Conversations become more productive. People understand not only what they are building, but why it matters and who it serves.
A Foundation for Product Leadership
Every Product Owner, Program Manager, and UX Architect will develop their own style over time. Different industries, organizations, and teams require different approaches. There is no single framework that works perfectly in every environment.
For me, however, these three pillars have remained constant throughout my career. Whenever I join a new organization, I want to understand the problem being solved, the customers being served, and the people building the solution.
Everything else is built on that foundation.
Because before we can improve a product, prioritize a roadmap, facilitate a sprint, or define a requirement, we need to understand why the work exists, who it serves, and who is bringing it to life.
Next in the series: Understanding the Team Behind Great Products (coming soon)
Over the next few articles, I’ll be exploring communication styles, collaboration preferences, and how Product Leaders can better support the people responsible for turning ideas into reality.
Work With Me
If your product depends on complex systems, content workflows, or structured data, I help teams define how those systems should work before development begins.
My focus is on reducing ambiguity, aligning teams, and ensuring what gets built behaves as intended in real use, without constant rework.