Why strong teams can still struggle
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?
Illustrative Example
Streamlining insurance prior-authorization
Consider a healthcare provider using software to manage medical insurance prior-authorization requests.
The direct user may be a billing specialist trying to understand an insurance company’s requirements and submit a request correctly.
The patient wants a clear, timely answer about whether their care can move forward.
These are two related but distinct Customer Outcomes within the Value Exchange.
Making the process understandable for the billing specialist can improve efficiency and reduce errors. That helps support the core Customer Outcome for the patient: getting an accurate and timely answer.
If those outcomes are achieved, they can contribute to positive Business Impact for the insurance company, such as improved customer satisfaction, stronger brand loyalty, fewer support calls, and lower operational costs.
So the problem needs to be framed as more than a single interaction or screen redesign, because the outcome depends on much more:
Payer requirements need to be current and data integrations reliable.
Staff need onboarding and a way to handle exceptions.
Patients need understandable updates.
Support teams need enough context to resolve problems when something goes wrong.
That’s a lot to define, align, and deliver. Trying to deliver it all at once increases complexity, coordination needs, project duration, and the risk and cost of getting it wrong.
A better approach is to use an incremental delivery strategy: proactively identifying how the capability can be designed, built, and delivered in meaningful increments. Each release can create value while helping the product team learn, validate assumptions, and make adjustments as needed.
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.
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.