The Framework That Changed Product Management
Sometime in the late 1990s, two ideas began to converge. Tim Brown and his colleagues at IDEO had been popularising a way of thinking about innovation that asked three simultaneous questions: is this desirable to people, is this feasible to build, and is this viable as a business? Around the same time, Marty Cagan, who would go on to write Inspired, was articulating a definition of product management built on the same triangle. The two streams of thought eventually merged, and today the three-pillar model is the closest thing the field has to a unifying theory.
Despite being repeated thousands of times in books, blog posts, and onboarding decks, the framework is still misunderstood by most PMs. They treat it as a slogan rather than a discipline. They nod along with the diagram and then go back to making decisions that neglect two of the three. The point of this article is to take the framework seriously enough that you can actually use it.
Defining Each Pillar Precisely
Pillar One: Desirability (User Experience)
Desirability asks: do users want this, will they actually use it, and will they prefer it over their current alternative? It is tempting to reduce desirability to does it look good , but that is a small part of it. A product can be visually beautiful and deeply undesirable, because it solves a problem nobody has, or it solves a real problem in a way that creates more friction than the workaround the user already has.
Desirability is composed of several layers. There is the question of whether the underlying problem matters enough to the user that they will change their behaviour to use a solution. There is the question of whether the proposed solution actually addresses that problem. There is the question of whether the experience of using the solution is pleasant enough that they will keep coming back. And there is the question of whether they will tell other people, which is how most products grow without burning money on advertising.
When PMs say a feature is desirable , the question to interrogate is which layer they are talking about. A feature can be desirable at the problem layer and undesirable at the experience layer, which is common. A feature can be desirable to one segment and irrelevant to another. Desirability is rarely a single bit. It is a multi-dimensional judgment that requires evidence, not assumption.
Pillar Two: Feasibility (Technology)
Feasibility asks: can we actually build this, given our current technology, our team's capabilities, and our timeline? Junior PMs often imagine feasibility is a yes-or-no question that engineering answers. It is not. Feasibility is a continuous spectrum that depends on how much time, how many people, and how much complexity you are willing to accept.
Most things are technically feasible if you are willing to spend enough time and money. The real feasibility question is: at what cost, with what risk, and with what compounding effect on the system's future maintainability? Senior PMs ask not just can we build this , but what will we have to give up to build this, and what will we be unable to do later because of decisions we make now?
There is also the question of buildability with this team in this company . A feature that is feasible at Google may not be feasible at a fifteen-person startup, not because the underlying technology is impossible but because the team does not have the depth to do it safely. Honest feasibility analysis includes the people doing the work, not just the abstract technical possibility.
Pillar Three: Viability (Business)
Viability asks: does it make business sense for us, this company, to build this? It is the pillar most often ignored by PMs from design or engineering backgrounds, and the one most often over-weighted by PMs from finance or strategy backgrounds. Healthy viability thinking lives somewhere between these extremes.
Viability is not just will we make money on this feature , though that is often part of it. It includes: does this feature fit our strategic position, does it support or undermine our business model, does it fit our distribution channels, does it create legal or regulatory risk, does it strengthen our defensibility against competitors, does it justify the opportunity cost of not building the next-best alternative? A feature can be desirable to users and feasible for engineers and still be a strategic mistake to build, because it is in the wrong direction for the company.
How PMs From Different Backgrounds Bias the Triangle
Almost every PM enters the field from one corner of the triangle and has to consciously develop in the other two. Knowing which corner is your home corner is the first step to compensating for it.
The Designer-Turned-PM
Designers turned PMs tend to do desirability brilliantly. They have user empathy in their bones, they think in flows and edge cases, they can spot a confusing experience from a distance. They tend to underweight viability and sometimes feasibility. They are quick to champion features that users would love, slow to ask whether the company can profitably support those features at scale, and often frustrated when engineering says the elegant solution would take three quarters longer than the inelegant one.
If this is your background, the deliberate work is to build a feel for unit economics, customer acquisition cost, lifetime value, and the difference between a feature that delights one user and a feature that scales to a hundred thousand. Spend time with finance. Read your company's investor materials. Sit in pricing discussions.
The Engineer-Turned-PM
Engineers turned PMs tend to do feasibility brilliantly. They know what is hard, they know what is risky, they know what builds well and what builds badly. They tend to underweight desirability, often in subtle ways. They will design solutions that are technically elegant and emotionally cold. They will assume users care about the things engineers care about, like configurability, transparency, and control, when many users actually want decisions made for them. They will sometimes confuse this is buildable with this is wanted .
If this is your background, the deliberate work is to spend more time watching real users, especially novice ones, and to build a tolerance for solutions that are not technically optimal but are emotionally right. Sit with customer support. Watch new users try your product without help. Resist the urge to explain why the design you chose is the better one. The user's confusion is the data.
The Business-Turned-PM
PMs who come from consulting, finance, or business strategy backgrounds tend to do viability brilliantly. They can model markets, frame trade-offs in dollars, and articulate competitive positioning. They tend to underweight desirability and feasibility together. They will pitch features that have a beautiful business case and no clear user value, or features that would generate revenue if engineering could just deliver them in two weeks, which engineering cannot.
If this is your background, the deliberate work is to develop humility about the gap between a slide and a shipped product. Spend real time with engineers, not just at sprint reviews. Walk through code with them. Ask what they hate about the codebase. Spend time with users who do not match your idealised customer persona, especially the ones who are confused by the product. Build the muscle of designing solutions, not just specifying outcomes.
Your Background Strong Pillar Pillar to Develop Design / UX Research Desirability Viability and feasibility
Engineering Feasibility Desirability and emotional design
Business / Strategy Viability Desirability and feasibility reality
Customer Success / Desirability Viability and technical depth Support
Marketing Viability Feasibility and depth of user research
The Tensions Between the Pillars
The pillars are not always in harmony. In fact, the most interesting PM work happens when they pull against each other. A great PM recognises these tensions, names them honestly, and helps the team navigate them with eyes open.
Desirability vs. Viability
The classic tension. Users want everything for free. The business needs to make money. Users want every feature personalised. The business needs to scale. Users want to talk to a human. The business needs to deflect support contacts. Every consumer product navigates some version of this tension daily.
The wrong response is to pretend the tension does not exist. The right response is to find the design that satisfies enough of what users want to keep them happy, while preserving enough of what the business needs to keep the lights on. Sometimes the answer is transparent trade-off, like a free tier and a paid tier. Sometimes it is a cleverer alignment, where solving the user's problem also solves the business's, but those are rarer than we pretend.
Desirability vs. Feasibility
Users want magic. Engineers know magic does not exist within the current quarter. The PM's job is to translate between the two. Sometimes the translation is to pick a smaller, less magical version that still solves the core problem. Sometimes it is to invest in engineering capability so that, two quarters out, the magical version becomes feasible. Almost always it involves saying not yet to something both you and the user wish was already real.
Viability vs. Feasibility
The business sees a window of opportunity that requires shipping in six weeks. Engineering says responsible delivery requires twelve. What do you do? This is one of the hardest situations a PM faces, and the wrong answers are easy. Caving to the business and shipping broken software burns user trust and creates technical debt that compounds. Caving to engineering and missing the window may cost the business a year of competitive advantage.
The right answer is almost always to scope the work down honestly: identify the smallest version that captures the strategic value, ship that, and use the remaining time for the rest. This requires real product thinking, not just project negotiation. It requires you to ask what is actually essential to the business outcome and what feels essential but is actually not . The latter is almost always more than the team initially admits.
“The PM's job is not to choose which pillar wins. It is to find the choice that lets all three breathe, and to be honest with the team about which trade-offs are real.”
Three Real Examples
Example One: A Product That Got All Three Right
Consider a successful expense management app for small businesses. On the desirability side, it removed the need for users to carry physical receipts and to manually enter expenses, which was the actual pain point. On the feasibility side, it leveraged existing OCR technology that, while imperfect, was good enough for the domain. On the viability side, it charged a per-user monthly fee that was small enough not to be a buying objection but large enough to cover acquisition cost within months. Each pillar was satisfied and they reinforced each other: the desirability of the experience drove word-of-mouth adoption, which lowered acquisition cost, which allowed the company to reinvest in feasibility improvements.
Example Two: A Product That Failed on Viability
A consumer photo-sharing app from the early 2010s built a beloved experience and grew rapidly. Users adored it. Engineering had elegantly solved the technical problems. But the business model depended on advertising at scale, and the user base, while enthusiastic, was not large enough to make the advertising model work, and not willing to pay subscription fees. Desirability and feasibility were both strong. Viability was a quiet hole the company never closed, and eventually the company shut down despite users actively mourning its end. This is a common pattern: a product can be loved and buildable and still not make economic sense for its company.
Example Three: A Product That Failed on Desirability
A widely-marketed enterprise software suite was built by engineers with deep domain expertise and was technically very impressive. The business model was clear: high-priced contracts to large enterprises. But the product assumed users would invest weeks learning a complex configuration model, and most actual users in customer companies did not. Viability was strong on paper, feasibility was excellent, but desirability collapsed at the user level even though buying executives signed contracts. Renewal rates plummeted within two years and the company was eventually acquired at a fraction of its early valuation. The lesson: in enterprise products especially, buyers and users are different people, and desirability must be evaluated for both.
How to Practically Use the Framework
Apply It Before You Commit, Not After
The framework's value is preventive, not retrospective. Before any meaningful initiative, write three short paragraphs: one on the desirability case, one on the feasibility case, one on the viability case. If any of them feels thin, you have not done enough work yet. Going into a build phase with one weak pillar is not impossible, but you should know which pillar is weak and what you would learn early to test it.
Use It as a Diagnostic When Things Go Wrong
When a product is underperforming, the three-pillar framework is a useful diagnostic. Ask, of each pillar: is the problem here? Often you will find that the problem is not the one the team has been blaming. A feature that users do not adopt may have a desirability problem in the experience layer, but the team has been blaming feasibility because performance is slightly slow. Solving the wrong pillar wastes a quarter.
Use It in Reviews and One-on-Ones
When reviewing your team's work or coaching a more junior PM, ask the three-pillar question for each major decision. Where is the desirability case stronger or weaker than you assumed? Where might feasibility be hiding risk? What's the viability picture beyond the first quarter of revenue? This trains the habit of integrated thinking, which is much more valuable than any specific decision.
A Common Failure Pattern: The Two-Pillar Trap
Many products that look healthy in any one quarter are quietly only satisfying two of three pillars. They survive because the gap on the third is invisible until something stresses it. A feature with strong desirability and feasibility but weak viability looks great until you try to scale it economically. A feature with strong desirability and viability but weak feasibility ships, but creates technical debt that slowly chokes future development. A feature with strong feasibility and viability but weak desirability gets revenue today and churn tomorrow.
The discipline is to spot the two-pillar trap before it becomes obvious. The pillar you are weakest on is usually the pillar you are talking about least in your team's standups and reviews. If you have not heard the words customer , user , or research in the last two weeks of meetings, your weak pillar is desirability. If you have not heard scaling , maintainability , or technical debt , your weak pillar is feasibility. If you have not heard margin , strategy , or defensibility , your weak pillar is viability.
How to Develop in All Three Pillars Over a Career
Nobody comes in equally strong on all three. Career progression in product management is largely the story of deliberately developing the pillars you started weak on.
Years One to Three
Identify your home pillar. Spend most of your time deepening competence in the other two through proximity. Sit with the people who own each pillar. If desirability is your weak spot, shadow researchers and designers. If feasibility is weak, pair with engineers on architecture conversations. If viability is weak, ask finance to explain unit economics until you understand the model your product depends on.
Years Three to Six
Lead initiatives that force you into your weak pillars. If you are a designer-turned-PM, volunteer for a pricing project. If you are an engineer-turned-PM, volunteer for a major UX redesign. The discomfort is the development. The mistakes you make in your weak pillar this period are the foundation of competence in it later.
Years Six and Beyond
By now you should be functional in all three. The next stage is to develop the integrative judgment that lets you weigh the pillars against each other in real time, often without explicit deliberation. This is the level at which PMs become genuinely valuable to their companies, and it is the level at which the framework dissolves from a checklist into intuition. You will know you are there when you no longer have to consciously remember to consider each pillar; your evaluations naturally include them.
Key Takeaways
- Every product decision lives at the intersection of desirability, feasibility, and viability. Missing any one of the three creates predictable failure modes.
- Desirability is not just visual appeal. It includes problem importance, solution fit, experience quality, and word-of-mouth momentum.
- Feasibility is not yes-or-no. It is a continuous question of cost, risk, team capability, and compounding effects on future work.
- Viability is not just revenue. It is strategic fit, distribution, unit economics, defensibility, and opportunity cost.
- Most PMs come from one corner of the triangle. Career progress is the deliberate work of developing the other two until integrated judgment becomes natural.