Most teams can sketch the Venn diagram of Desirability, Viability, and Feasibility from memory.
Far fewer are structurally set up to live by it.
Over the past years leading UX and Product Design, I’ve worked inside large product organisations where this “holy trinity” was either a real operating model — or a decorative artefact.
In the healthier cases, user, business, and technology were treated as peer domains. Each had clear ownership, shared accountability, and real influence on decisions. The results were tangible: faster learning cycles, fewer late-stage surprises, and products that didn’t rely on heroic marketing to compensate for weak fundamentals.
In the less healthy ones, the same diagram existed as wall art.
Decisions were made in one circle, then quietly translated into “constraints” for the others. UX was asked to validate decisions already taken. Engineering was asked to “just make it work”. Business was surprised — again — by low adoption.
This article is about that gap between knowing the model and actually organising around it.This Framework Is Older Than Your Roadmap
This Framework Is Older Than Your Roadmap
The idea that successful products sit at the intersection of what people want, what is technically possible, and what makes business sense is not new. Design thinking popularised this triad in the early 2000s, framing it as desirability, feasibility, and viability, and visualising it as overlapping circles: a deceptively simple picture of a messy reality.[1][2]
Since then, it has been rebranded endlessly: product trios, product triads, three-in-a-box models, holy trinities with different job titles plugged in.[3][4] The names change. The tension doesn’t.
What I find interesting is not that organisations don’t know this model — but how often they assume they are already practicing it, simply because the vocabulary exists.
If this is so widely understood, why does the Venn diagram still need defending?
Why the trinity still gets ignored
Executives rarely wake up thinking, “Let’s ignore user needs today.”
Yet organisational gravity does the job for them.
Some recurring patterns I’ve seen up close:
Engineering-heavy and roadmap-driven
The backlog is full, delivery plans are locked months ahead, and discovery is treated as a luxury. Desirability is assumed, not examined. When outcomes disappoint, the instinct is to add more features, not question the premise.
Sales-driven
Revenue pressure dominates. Product teams become bespoke feature factories for the loudest clients. Short-term wins pile up, while long-term coherence quietly erodes sprint by sprint.
Design as paint
Designers are invited once the “what” is already decided. Their task is to make it usable, compliant, or visually appealing — without permission to challenge whether it should exist at all.
None of these setups is malicious.
They are simply what happens when the trinity is treated as a metaphor instead of a concrete model for collaboration and decision-making.
The three domains, without the buzzwords
For clarity, here is the version of the trinity that has proven the most practical in my work.
Domain | Focus | Core Question |
|---|---|---|
User | Desirability | Do people actually want this, and can they use it? |
Business | Viability | Can this sustain and grow the organisation? |
Technology | Feasibility | Can we build and operate this, reliably, at scale? |
Each domain carries a responsibility and a characteristic failure mode.
The goal is not to eliminate tension between them, but to make that tension productive and visible.
Let’s look at each circle through the lens of practice rather than theory.
User / Desirability: More than “making it pretty”
In many organisations, “design” is still shorthand for visuals and polish.
That’s the safest — and least valuable — interpretation of the role.
Desirability is about understanding what people actually need, how they behave today, and how your product fits into their real constraints — not the ones imagined in planning workshops.
The questions that matter here are uncomfortable by design:
What problem are we solving, in the user’s own words?
What workaround are they using right now?
Where will this realistically sit in their workflow?
How will we know early if we’re wrong?
This is where research, discovery interviews, and continuous feedback loops live — but more importantly, where inconvenient truths surface.
I’ve seen features celebrated internally that never stood a chance outside the building. Not because the execution was poor, but because the underlying problem was misunderstood — or never validated in the first place.
When UX is allowed to operate at this level, it stops being a screen-production function and becomes an insight engine for strategy. The output isn’t just wireframes. It’s evidence: decision logs, tested assumptions, and a clearer sense of where not to invest.
Business / Viability: Strategy, not just revenue
Viability is often reduced to “does this make money?”
In reality, it’s about whether a product makes sense within a broader strategic system.
This domain should own questions like:
What market are we actually competing in?
What alternatives do users have — including doing nothing?
How does this product reinforce (or dilute) our positioning?
What is the real cost of maintaining and evolving it?
When viability is weak, teams build things users like that the organisation can’t sustain.
When it dominates unchecked, teams optimise for near-term metrics while accumulating long-term damage: complexity, churn, and fragile trust.
I’ve watched organisations celebrate commercial wins that quietly poisoned the product experience — then act surprised when adoption plateaued or support costs exploded.
Balanced well, viability is what turns desirability into durable value instead of a one-off success story.
Technology / Feasibility: The difference between “can” and “should”
Feasibility is often framed as a binary question: Can we build it?
The more interesting question is: Can we build it well enough, fast enough, and sustainably enough to justify it?
This is where architecture, technical debt, scalability, security, and operational reality show up — usually later than anyone would like.
In strong teams, engineering isn’t the department of “no”. It’s the shaper of credible options. Designers bring user intent; engineers bring constraints, patterns, and trade-offs. Together, they search for solutions that won’t collapse under real-world usage.
When feasibility dominates without strong user and business counterweights, teams optimise for internal elegance and delivery speed. The result works beautifully for the system — and painfully for the humans interacting with it.
You ship fast. Users leave slowly.
What happens at the intersection (where products are actually made)
The real work rarely happens in a single circle. It happens in the overlaps.
User × Business: Value propositions, pricing, and positioning informed by actual behaviour, not assumptions.
User × Technology: Interaction patterns negotiated with empathy for both users and systems.
Business × Technology: Platform and investment decisions shaped by economic and technical reality — not wishful thinking.
In practice, this often takes the form of a product trio: product, design, and engineering acting as one decision-making unit.[2][3]
When it works:
Discovery is shared.
Strategy is grounded.
Delivery has fewer late-stage surprises.
When it doesn’t, you get familiar anti-patterns: designers handed requirements, engineers handed tickets, and leadership puzzled by flat adoption curves.
A Personal note: When one domain wins, everyone loses
Looking back at the projects that went sideways in my career, a pattern keeps repeating: one domain won too early.
When users were sidelined, we built what stakeholders wanted — not what people needed. Adoption never matched the optimism in the room.
When business pressure steamrolled everything, we chased short-term wins that degraded coherence and trust.
When technology went unchallenged, we optimised for internal efficiency and wondered why users struggled with flows that made perfect sense on paper.
The most rewarding work looked very different.
It involved disagreement, shared uncertainty, and teams that could test their way forward without needing a single “winner”.
You could hear the shift in leadership conversations — from “Can you commit to this?” to “What have we learned, and what’s next to test?”
That change is subtle. It’s also transformative.
Making the trinity real: A few practical moves
You don’t need another framework. You need to operationalise the one you already have.
A few moves that actually help:
Design teams around the trinity
Ensure clear ownership for user, business, and technology — and expect them to act as a unit.Make it visible in decision rituals
In roadmap and go/no-go discussions, explicitly ask what you know — and don’t know — about desirability, viability, and feasibility.Invest in joint discovery
Put PMs, designers, and engineers in front of users together. Shared evidence beats alignment workshops every time.Reward outcomes, not output
Measure behavioural change and business impact, not feature volume.
None of this is glamorous. It’s craft. And it’s surprisingly rare.
If one circle is missing, the decision isn’t ready
The holy trinity of product development isn’t new — and it isn’t mine.
But it remains one of the most honest mirrors an organisation can hold up to itself.
Before your next major product decision, ask:
Who is representing the user, with real evidence?
Who is representing the business, with strategic clarity?
Who is representing technology, with a realistic view of cost and consequence?
If one of those voices is missing — or symbolic — the decision isn’t ready.
The Venn diagram isn’t decorative.
It’s a warning sign.
Sources
[1] The Trinity of Success in Software Product Development for …https://www.linkedin.com/pulse/trinity-success-software-product-development-b2b-leaders-nguyen
[2] Desirable, Viable, and Feasible Goals | by Cory Mogkhttps://medium.productcoalition.com/viable-desirable-and-feasible-goals-381c4aa33195
[3] How engineering, design, and product form the ‘software …https://leaddev.com/communication/how-engineering-design-and-product-form-software-trinity
[4] The Product Triad: Great designers help their teammates …https://uxplanet.org/the-product-triad-great-designers-help-their-teammates-do-their-best-work-e155fa2edbe0
[5] Bootcamp – Devenez Product Designerhttps://www.thedesigncrew.co/bootcamp
[6] The Holy Trinity of Product Development
https://fresco.vc/holy-trinity-of-product-development/
[7] How we used the holy trinity of product management (frameworks) to build a feature that will help millions of people improve their credit scorehttps://www.linkedin.com/pulse/how-we-used-holy-trinity-product-management-build-feature-khanna
[8] Product Decisions: Desirability, Viability, Feasibility …https://www.linkedin.com/posts/konstantinrnd_productmanagement-strategy-ai-activity-7407710040318476289-8UxY
[9] How to Keep Design Consistent. A Year in Review …https://engineering.reviewtrackers.com/keeping-design-consistent-382364537c8a
[10] The Holy Trinity of Product managementhttps://www.linkedin.com/pulse/holy-trinity-product-management-denis-kiselev-bheqf
Go Back
