For the past several years, I’ve been exploring questions about the way organizations understand what they are trying to accomplish. It led me to ponder how that understanding gets shared across functions, and how it shapes the product decisions that follow.

As I look back now, I see a progression in my thinking beginning with the foundational framework I established with Whole Product Thinking, my Advancing Research 2025 presentation centered on Collective Understanding, and now to the ideas I’ll be presenting next week at Shift UX 2026.

It started with the Whole Product Thinking framework

My work on Whole Product Thinking began with an observation that teams often move too quickly into problem and solution spaces without developing a broader understanding of what they are actually trying to accomplish.

Customer needs are critical, but they are only part of the picture. Business goals, market realities, technical capabilities, operational constraints, resources, risk, and the ability to deliver and realize value all shape whether a product will ultimately succeed.

That led to the core questions in Whole Product Thinking:

• What do we need to accomplish, and why?

• What is needed to successfully deliver and realize value?

• Where do we have gaps or potential blind spots?

• What trade-offs do we need to consider given our resources?

The intent was never to prescribe another product development process. The Whole Product Thinking map is intended to help teams see the larger product system together—what is understood, what is assumed, what is working, what is disconnected, where dependencies exist, and where gaps or trade-offs need attention.

From User Research to Collective Understanding

At Rosenfeld Media’s Advancing Research 2025, I explored Customer Understanding and the challenges and opportunities we face as more “non-researchers” are involved.

Research and customer learning have become increasingly distributed. Researchers, product managers, designers, support teams, engineers, analytics teams, and others are all contributing different pieces of customer understanding.

Rather than focusing only on who should or shouldn’t be conducting research, I became more interested in what all of that knowledge was ultimately for.

One line from the presentation captured the shift:

Research isn’t about collecting insights. It’s about shaping how teams think.

That led to the idea of Collective Understanding: a shared and continuously evolving understanding built by connecting knowledge across people, functions, evidence, and systems so teams can reason about decisions from a more complete picture.

Collective Understanding was increasingly about how the organization creates, connects, and maintains the knowledge needed to make better product decisions over time.

AI raises the stakes

AI is making many parts of knowledge work dramatically easier. We can retrieve information, synthesize evidence, connect sources, and generate answers faster than ever.

But that doesn’t mean the underlying understanding is complete.

If the evidence is fragmented, stale, inaccessible, contradictory, or missing important context, AI can amplify that fragmentation just as easily as it can help resolve it. As the how becomes easier, the quality of the what and why becomes even more important.

That is the question behind the work I’m exploring now.

Toward Architecting Organizational Understanding

Next week at Shift UX 2026, I’ll be presenting:

Architecting Organizational Understanding: The New Frontier for Human-Centered Practitioners

The talk asks what happens if we treat organizational understanding as something that can be intentionally shaped.

How do we bring together the right people, evidence, operational context, and systems around important decisions? How do we create the conditions for Collective Understanding, independent of any particular technology?

Because technology will continue to change rapidly, the focus needs to stay on a more fundamental question:

How do we help organizations understand what they are trying to accomplish—and why—well enough to make better decisions about what comes next?

I hope you join me as I continue to explore these topics at Shift UX 2026. I’m looking forward to the in-person and virtual conversations around the future of UX. You can use my discount code: MCKAY-SHIFT26

Also, if you want to catch up, my previous presentations are available in Rosenfeld Media’s Rosenverse and can be accessed after creating a free account:

Advancing Research 2025 • March 11, 2025
Watch Now: “Coexisting with non-researchers: Practical strategies for a democratized research future” →

Rosenfeld Community Event • March 14, 2024
Watch Now: “Whole Product Thinking: Expanding Beyond Problem and Solution Space Thinking” →

Most organizations are not short on expertise.

They are short on the shared context needed to connect it.

Product managers may see markets, opportunities, and priorities from one angle. Researchers and designers bring deep understanding of what customers need and how they think. Engineers understand the systems and constraints that shape what is possible. Customer Success often sees recurring struggles that only become visible after launch. Operations, strategy, analytics, Marketing, and leadership bring still other perspectives on investment, adoption, timing, priorities, and organizational realities.

That specialization is necessary because complex products require deep expertise.

But specialization also creates a problem: the knowledge required to make a product successful is distributed across the organization, while the context needed to connect that knowledge often is not.

None of those specialized perspectives are necessarily “wrong”. The difficulty is that no single one reveals the whole system.

And the product depends on how well those perspectives connect.

This is why strong work in individual disciplines can still lead to weak or ineffective results:

• A product may solve a real customer problem but be difficult to adopt.

• The experience may be thoughtfully designed but depend on capabilities that were neglected or never funded.

• The solution may work technically while implementation, support, integration, pricing, or operational needs remain unresolved.

• A launch may appear successful while the organization remains vague about whether customers actually received meaningful value—or whether that value produced meaningful impact for the business.

A deliverable may work. The Whole Product may not.

That tension is at the heart of Whole Product Thinking.

Start with the what and why

Whole Product Thinking grew out of a question I kept encountering throughout my career in design and product development:

How can we create a shared understanding of what needs to be true for a product to create meaningful customer value and business impact—without prescribing one methodology for how every organization should work?

I have always been interested in the methods, models, and frameworks developed across product, design, research, technology, strategy, business, and operations. There is a tremendous amount of useful thinking in these disciplines, often created by people trying to solve very real and difficult problems.

Most frameworks, however, are intentionally focused. They were created to address a particular kind of problem from a particular point of view. That focus is often exactly what makes them useful.

The difficulty comes when we mistake the method for the underlying problem it was designed to solve.

Rather than creating another prescribed methodology, I wanted to bring together useful concepts and relationships from across these disciplines into a shared thinking framework.

The starting point is not a sequence of activities. It is a set of more fundamental questions:

• What do we need to accomplish, and why?

• What is needed to successfully deliver and realize value?

• Where do we have gaps or potential blind spots?

• What trade-offs do we need to consider given our resources?

Once there is enough clarity around those questions, teams are in a much better position to decide how the work should happen and who should be involved.

And those answers should vary based on context—company stage, scale, culture, maturity, technical environment, capabilities, constraints, investment capacity, and risk tolerance all matter.

The framework is intended to preserve that flexibility.

Whole Product Thinking is a shared thinking and diagnostic framework that helps cross-functional teams understand, assess, and align around what is needed to create and deliver products that are meaningful for customers and effective for the business. It focuses on the what and why, allowing organizations to choose the how and who based on their unique context.

That distinction between the what and why and the how and who feels increasingly important because the how and who are changing rapidly.

AI is already reshaping how research is conducted, ideas are explored, software is designed and built, teams collaborate, and responsibilities are distributed across roles — and the ways we organize and do that work will continue to evolve.

That makes a shared understanding of the underlying what and why even more important, because it gives organizations a more durable foundation from which to adapt.

Value Exchange is at the center

At the center of Whole Product Thinking is the relationship between two forms of value:

Customer Outcome ↔ Business Impact

I first encountered the concept and term Value Exchange through Melissa Perri’s Escaping the Build Trap and Jeff Patton’s writing and workshops. It gave language to an idea that had been important to me for a long time as a UX practitioner: products should be meaningful for users and effective for the business.

The basic relationship is straightforward. If we help customers achieve outcomes that genuinely matter to them, the value we create should contribute to some form of positive impact for the business.

But that relationship is not automatic.

A team may solve an important customer problem without having a credible connection to what the business is trying to achieve.

Conversely, an organization may focus heavily on improving a business metric without being explicit about what meaningful Customer Outcome would contribute to that metric.

Making the relationship explicit gives teams something important to reason about together.

The Value Exchange helps connect the value customers are intended to receive with the value the business expects in return.

What outcome are we trying to enable for customers? If customers achieve that outcome, what do we expect them to do differently? How should those behaviors contribute to meaningful Business Impact?

Those questions force us to articulate assumptions that often remain implicit.

And there is another important distinction: what we intend to happen is not necessarily what will be realized.

Product development is full of hypotheses. We believe a problem matters. We believe a solution will help. We believe customers will behave differently. We believe those behaviors will contribute to a business result.

Those beliefs may be well researched and carefully reasoned. They are still assumptions until the Whole Product encounters Reality.

That is why the Value Exchange is more than a way to state an aspiration. It also provides a basis for learning whether the relationship we expected to create is actually occurring.

The product is not the Whole Product

To understand why this matters, it helps to distinguish between the product we build and the Whole Product customers actually depend on.

The idea has an important lineage. Geoffrey Moore’s Whole Product concept makes explicit that the core product alone is rarely enough for customers to receive the complete value of an offering. Successful adoption may depend on services, support, implementation, integrations, partners, education, and other elements surrounding the core product.

Whole Product Thinking brings that question further upstream:

What broader system needs to be intentionally understood, aligned, enabled, and sustained for the intended Value Exchange to work?

A Whole Product is more than the core product or solution an organization designs, builds, and delivers. It is the system of orchestrated solutions, capabilities, services, and conditions required for customers to realize meaningful value and for the business to realize the intended impact.

This matters because customers do not experience our organizational boundaries.

They experience the software and the support process. The physical product and the installation. The service and the policies surrounding it. The marketing promise and what happens after purchase. The integration with the systems they already use. The handoff from one channel, team, or experience to another.

Inside an organization, those things may belong to entirely different functions, budgets, systems, or leaders.

From the customer’s perspective, they are part of one experience.

That leads to a useful distinction:

The Value Exchange defines the value relationship being pursued. The Whole Product is the system required to enable and sustain it.

Whole Product Thinking is intended to make more of that system visible.

Four Spaces to visualize the system

The Whole Product Thinking Map organizes the broader product system into four interconnected Spaces:

Business, Problem, Solution, and Reality.

These Spaces are not stages in a prescribed process, and they are not intended to suggest that teams should move through them in order.

In practice, they interact through continuous, iterative loops of learning, decision-making, delivery, and adaptation:

• A new customer learning may challenge the Product Strategy. A technical constraint may reshape the opportunity a team is pursuing.

• Something learned after launch may expose a problem with the solution—or reveal that the original understanding of the problem itself was incomplete.

• A shift in business priorities may change which opportunities deserve investment.

The purpose of the Map is to help everyone involved develop a shared view of the conditions and perspectives that need to remain connected as the work evolves.

Business Space — Right Time

The Business Space asks a fundamental question: Why this, and why now?

It represents the organizational context surrounding product decisions—the Business Goals & Objectives, strategy, priorities, capabilities, constraints, capacity, competing commitments, and investment considerations that shape what an organization is able and willing to pursue.

A valuable opportunity is not automatically the right opportunity to pursue now.

A company may understand a meaningful customer need and have a plausible solution while still deciding that other opportunities deserve investment first. It may lack a necessary capability. The timing may be wrong. The risk may be too high. Or the opportunity may support a longer-term ambition rather than the organization’s immediate priorities.

The Business Space makes that context part of the product conversation rather than treating it as information that exists somewhere above or outside the teams doing the work.

The people creating and delivering the Whole Product need enough business context to make good decisions and meaningful trade-offs.

Problem Space — Right Problem

The Problem Space asks: What is worth addressing?

This is where understanding customers connects with the context of the business.

Teams develop a shared view of customers—their needs, behaviors, motivations, mental models, constraints, goals, and desired outcomes—and use that understanding to identify potential Value Opportunities.

But identifying a real customer problem does not automatically make it the right product opportunity.

There are always more problems worth solving than an organization has the capacity to pursue.

Product Strategy helps make that choice explicit by connecting Value Opportunities to intended Customer Outcomes and Business Goals & Objectives.

The relationship is continuous rather than linear. Customer Understanding changes the opportunities we see, while the opportunities we consider create new questions we need to explore.

The goal is not simply to “complete discovery.” It is to maintain enough understanding to make deliberate choices about which problems and opportunities are worth pursuing—and why.

Solution Space — Built Right

The Solution Space asks: What will enable the intended Value Exchange?

Once an opportunity has been chosen, the job is not simply to convert it into a feature.

The solution has to become part of a coherent Whole Product capable of creating the intended value.

That may require decisions about the experience, technology, services, capabilities, operations, implementation, and delivery—not simply the interface or technical functionality itself.

This is an important distinction because a feature can be beautifully designed and technically excellent while the broader system required for it to succeed remains incomplete.

The Built Right lens therefore means more than building the thing correctly. It asks whether the different parts of the Whole Product are working together in a way that gives the intended Value Exchange a credible chance of succeeding.

It also recognizes that teams rarely create the complete Whole Product at once. Products evolve through increments, learning, experimentation, and change.

The challenge is not simply to make work smaller. It is to create meaningful increments that provide real value, produce useful learning, and preserve the ability to adapt as understanding changes.

Reality Space — Delivered Right

The Reality Space asks: What actually happens when the Whole Product enters the real world?

Customers already have habits, expectations, existing tools, alternatives, relationships, constraints, and mental models. Markets have competitors and partners. Organizations have operational environments. Technologies change. Regulations shift. New behaviors emerge.

Products do not enter empty space.

They enter an existing reality that can enable, constrain, distort, or completely change what we expected to happen.

This is why releasing a product is not the same thing as realizing its value.

Customers still have to discover it, understand it, adopt it, integrate it into their lives or workflows, receive support when needed, and continue receiving value from it over time.

Reality is also where intent becomes evidence.

Expected Customer Behavior becomes observed Customer Behavior. Intended Customer Outcomes become realized—or unrealized—outcomes. Expected Business Impact becomes something the organization can begin to evaluate.

In that sense, Reality is both context and consequence. It shapes what can work, and it reveals what actually happened.

And because Reality never stops changing, the learning it produces continuously feeds back into the other Spaces.

Launch is not the end of the work. It is where a different kind of learning begins.

The connections matter as much as the Spaces

There is another risk in drawing four Spaces: turning them into four new silos.

Many of the conditions required for a Whole Product do not fit neatly inside one Space. They connect and influence work across the broader product system.

Whole Product Thinking calls these Connecting Concepts.

At a high level, they help connect direction, investment, understanding, operations, outcomes, and alignment across the four Spaces.

An Experience Vision helps set direction by describing how customers’ and users’ lives could be better in the future through the value we create.

Collective Understanding helps the organization connect that direction with customer needs, business priorities, capabilities, constraints, and what is being learned in Reality.

That shared understanding is critical to making the right Strategic Investments—the deliberate commitments of resources needed to pursue meaningful customer value and Business Goals & Objectives.

Connected Operations then help ensure the operational capabilities required across the Whole Product can work together to enable those investments in practice.

Business Impact provides evidence of what was ultimately realized through the Value Exchange, creating new learning that can strengthen Collective Understanding and inform future direction and investment.

Together, these concepts form a reinforcing loop: Experience Vision sets direction, Collective Understanding informs Strategic Investments, Connected Operations enable execution, and Business Impact provides evidence that feeds back into Collective Understanding and future Strategic Investments.

Organizational Alignment both enables and emerges from that loop—creating and maintaining the shared direction, understanding, priorities, commitments, and intended outcomes that allow people and teams across organizational boundaries to act coherently and adapt as they learn.

I’ll explore each of these Connecting Concepts more deeply in future articles. For now, the broader point is simple:

The problem is not that expertise is distributed.

The problem is when the context is not.

From mapping to alignment

Ultimately, Whole Product Thinking is intended to help teams see the larger product system together—what is understood, what is assumed, what is working, what is disconnected, where dependencies exist, and where gaps or trade-offs need attention.

Because one thing I’ve learned over and over is that visibility is the foundation for alignment.

Once more of the system is visible, teams can evaluate where they are today and develop a more shared view of where they need to go.

That may reveal different kinds of gaps:

• Unknown gaps — areas the organization did not realize it was overlooking.

• Known gaps — areas the organization recognizes but has not yet adequately addressed.

• Intentionally deferred gaps — areas the organization has consciously chosen not to address because of priorities, resources, timing, stage, or acceptable risk.

An intentionally deferred gap may be entirely reasonable.

Organizations operate with limited resources, different levels of maturity, changing priorities, and varying tolerance for risk. The important thing is that the trade-off becomes visible and understood rather than remaining accidental.

That changes the quality of the conversation.

Instead of asking only, “What should we build?” teams can ask:

• What are we actually trying to make true for customers?

• Why does that matter to the business?

• What else has to work for that value to be realized?

• Which assumptions are we making?

• Where are the important dependencies?

• What are we intentionally choosing not to address yet?

• What will Reality tell us about whether any of this worked?

Whole Product Thinking does not prescribe the answers to those questions.

That is intentional.

Its purpose is to help teams develop enough shared understanding of the what and why that they can align on what matters and make more informed choices about the how and who.

Make it visible. Make it explicit.

Products rarely succeed on features alone.

Value depends on a broader system of decisions, expertise, investment, technology, services, operations, capabilities, organizational conditions, and people.

Much of that system already exists inside our organizations.

We simply do not always see it clearly enough as a whole.

Whole Product Thinking is intended to make more of that system visible and to make its important relationships, assumptions, dependencies, gaps, and trade-offs explicit.

The goal is not to create another process for everyone to follow. It is to create a shared way of thinking about what needs to be true for a Whole Product to succeed.

Once we can see the system more clearly, we can have better conversations about what matters, make more deliberate trade-offs, and choose how to work based on what the situation actually requires.

And we can keep returning to the question that matters most:

What needs to be true for this Whole Product to create value for customers and impact for the business?

That is the starting point for Whole Product Thinking.

Download the Whole Product Thinking Map

The Whole Product Thinking Map brings the framework together in a single view, showing the four Spaces, related capabilities, and the relationships that connect them.

Whole Product Thinking Map v1.1

1.44MB ∙ PDF file

Download

A visual framework to help teams understand, align around, and explore what is needed to create and deliver products that are meaningful for users and effective for the business.

Download

This article introduces the overall model. In the articles that follow, I’ll go deeper into the individual Spaces, Connecting Concepts, Value Exchange, measurement, and practical ways teams can use Whole Product Thinking.

In my journey through design and product development, I've consistently observed teams facing the same challenge: navigating the overwhelming sea of expert advice. 

Industry leaders who passionately evangelize prescriptive methods that use unique terminologies often create more team confusion and conflict than clarity. The irony? We're all tackling the same fundamental issues but from different perspectives or vantage points. 

This sparked an idea: what if a framework could transcend these debates, offering a shared understanding of what needs to be done? Helping align teams and structuring conversations about how to create truly human-centered products that are effective for business.

Inspired by my life philosophy, 'There's good kung fu in everything,' I embarked on distilling these diverse approaches into core concepts and elements, visually mapping their interconnections into a cohesive framework.

My approach centers on the 'what' and 'why,' deliberately separating the 'how' to allow organizations the freedom to choose approaches and methods that align with their unique contexts, development philosophies, and company culture.

Over the past six months, I’ve been developing and evolving the framework through a series of insightful conversations (and debates) with colleagues and thought leaders. Those conversations helped both expand, challenge, and refine my thinking. More to come….

UPDATE — Recorded presentation now available:

Whole Product Thinking: Expanding beyond problem and solution space thinking
Thursday, March 14, 2024 • Rosenfeld Community

Subscribe now to be notified about the upcoming release of this framework and resources.

Subscribe now