The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the Sanity

Why this book exists

Alan Cooper had an unusual career trajectory. He started as a programmer in the 1970s and 1980s, building the visual programming environment that Microsoft eventually acquired and renamed Visual Basic. He was deeply embedded in the software engineering world; he knew programmers, knew how they thought, knew why they made the design choices they did. He was also frustrated with the results. The software his programmer colleagues produced was often hostile to its users — confusing interfaces, baffling error messages, workflows that made sense to the engineers who built them but nobody else.

By the late 1990s, Cooper had transitioned from programming to design consulting. He founded Cooper, one of the first interaction design consultancies, and spent the next decade working with companies trying to figure out why their software was failing its users. The pattern he saw was consistent: programmers were making design decisions they were not equipped to make, design considerations were being subordinated to engineering convenience, and the cost was being absorbed by users who blamed themselves for being unable to use software that was, in fact, badly designed for them.

He wrote The Inmates Are Running the Asylum in 1999 (revised 2004) as a direct argument to executives, founders, and product leaders. The thesis was provocative: take software design out of the hands of programmers. Give it to interaction designers — a discipline Cooper was helping to define — who would think about users first and engineering second. Use personas as the methodology for keeping the team grounded in real users.

The book was controversial when it was published and remains controversial today. Some of the controversy is deserved. Cooper's framing of programmers as "inmates" is uncharitable; many engineers care deeply about users and contribute substantively to design quality. The book reads in places like a designer's complaint about engineering culture rather than a rigorous analysis of design failures.

Some of the controversy is not deserved. The persona methodology Cooper helped invent has become standard practice across the field. The argument for interaction design as a distinct discipline has largely been won — every modern serious product organization has dedicated design functions, design leadership at the executive level, and design representation in product trios. The book's prescriptions have largely been adopted; the book itself is now read more as a historical artifact than as current guidance.

For PMs in 2026, the book serves two purposes. First, it provides a foundational text on the persona methodology that every PM should understand. Second, it provides historical context for why modern product organizations are structured the way they are — with designers as peers to PMs and engineers, with personas as a standard artifact, with interaction design as a distinct discipline.

The book in one sentence

Software designed by programmers is hostile to users because programmers optimize for what is easy to build rather than what is good for the user; the fix is to make interaction design a distinct discipline, give it real authority in product organizations, and use personas to keep the team focused on specific real users rather than abstract assumed users.

That sentence captures the entire argument. Everything else is examples, methodology, and political tactics for getting design authority within engineering-dominated organizations.

The structure of the book

The 2004 revised edition is organized in 14 chapters across three sections:

Section I: Computer Obliteration. Why high-tech products fail their users and what the cost is — to users, to companies, to society.

Section II: It Costs You Big Time. The specific costs of bad design, with examples from real software and real organizational failures.

Section III: Eating Soup with a Fork. The proposed solution — interaction design as a distinct discipline, goal-directed design methodology, personas as the anchoring artifact.

The book is medium-length, about 280 pages, and reads in 6-10 hours. The pacing is uneven — some chapters are tight and operational, others meander into broader cultural critique that has aged less well.

The central argument, in detail

Cooper's argument has three connected parts.

First, programmers should not be designing software. Not because programmers are bad people, but because the cognitive habits that make someone a good programmer are the opposite of the habits that make someone a good interaction designer. Programmers optimize for elegant code, efficient algorithms, scalable architectures. They are trained to think in terms of system behavior, edge cases, exception handling. None of these are the same as thinking about what it feels like to be a user encountering the product for the first time.

When programmers design interfaces, they default to interfaces that make sense given the underlying system architecture. The interface mirrors the database schema. The flow mirrors the function call sequence. The error messages reflect the system's understanding of what went wrong, not the user's. The result is software that is internally consistent but externally hostile.

Cooper's prescription: take interface design out of programmers' hands and give it to specialists trained in interaction design. The specialists should report up through a design leadership structure that has authority equivalent to engineering and product leadership, not as a service function subordinated to engineering.

Second, the cost of bad design is real and largely invisible to engineering-focused organizations. Bad design produces user frustration, abandonment, support tickets, brand damage, lost sales, regulatory exposure, and competitive vulnerability. None of these show up in engineering metrics. Engineering velocity, code quality, system uptime — these can all be high while the product is, from the user's perspective, terrible.

The chapter on cost is the most-quoted in the book. Cooper walks through specific examples of products that failed because of design — not because of any engineering inadequacy but because the user experience was so hostile that customers stopped using the product. The examples are dated now but the principle is permanent.

Third, the solution is goal-directed design driven by personas. Goal-directed design starts from what the user is trying to accomplish — their goals, their motivations, their context — and works backward to the interface that would best serve those goals. The interface is the output of understanding the user, not an input that the user has to adapt to.

Personas are the methodology for representing users in the design process. A persona is a specific, named, detailed model of a user — not a real user, but a composite that distills the patterns observed across many real users. The persona has a name, a job, a context, specific goals, specific frustrations, specific behaviors. The persona becomes the user the team designs for. Debates about the product are framed in terms of the persona: would Sarah understand this? Would Daniel use this feature? What does Carlos need from this flow?

The persona methodology is now standard practice. Cooper's invention has been adopted, refined, and extended across the field. Almost every modern product organization uses personas in some form.

The persona methodology in detail

The book devotes its longest chapters to the persona methodology. The methodology has several key components.

Personas are specific, not aggregate. A persona is not "the average user" or "the typical customer." It is a specific person with a specific name, job, age, location, and history. The specificity is what makes the persona useful in design conversations — the team can ask concrete questions about a specific person, whereas abstract aggregate users produce abstract answers.

Personas are based on real research. A good persona is built from interviews with real users, behavioral data, and observed patterns. A persona that is invented from the team's imagination is worse than no persona because it gives false confidence in user-centered design while actually being team-centered.

Personas have goals, not just demographics. The most important content in a persona is the user's goals — what they are trying to accomplish in their life or work that the product might help with. Goals are stable across contexts; behaviors and demographics change. Designing for goals produces software that serves the user well across the range of contexts the user actually operates in.

Personas come in primary, secondary, and supplemental flavors. Most products have multiple persona types. The primary persona is the one whose needs the product is most centrally designed for. Secondary personas have needs the product serves but does not optimize for. Supplemental personas are edge cases that the product accommodates but does not center. Being explicit about the persona hierarchy prevents the trap of trying to design for everyone equally, which usually produces software that serves no one well.

Personas are used continuously, not once. A persona is not a document that gets produced once and shelved. It is a tool that gets referenced in every design review, every prioritization conversation, every roadmap debate. Teams that produce personas but do not use them are doing theater.

Goal-directed design

The second major methodology in the book is goal-directed design. The methodology has a specific structure:

1. Research users. Interview real users, observe them in context, build behavioral models.
2. Synthesize personas. Create the specific, named, detailed user models based on the research.
3. Identify goals. For each primary persona, list their specific goals related to the product domain.
4. Design scenarios. Walk through specific scenarios of how each persona would accomplish each goal with the product.
5. Design the interface. Build the interface to optimize for the scenarios — making the goal-directed paths easy and the off-path actions safe.

The methodology is the inverse of feature-directed design. Feature-directed design starts with a list of features ("we need search, profile editing, settings, notifications") and builds an interface that accommodates the features. Goal-directed design starts with the user's goal ("I want to find the document I worked on yesterday") and builds an interface that makes that goal easy to accomplish.

The two approaches often produce different products. Feature-directed design tends to produce interfaces that are technically complete but harder to use because the user has to figure out which feature serves their current goal. Goal-directed design tends to produce interfaces where the user's most likely next action is always obvious, even at the cost of hiding features the user does not currently need.

For PMs, the methodology is a useful corrective. The instinct to optimize a backlog of features against the engineering capacity should be checked against the more important question: are the features what the personas actually need to accomplish their goals?

Where the book has aged well

The persona methodology has aged extraordinarily well. Every modern serious product organization uses some form of personas. The specific format Cooper proposed has been refined and varied but the foundational principle — specific named user models, based on research, used continuously in design conversations — is now the industry default.

The argument for interaction design as a distinct discipline has been won. Every major tech company has dedicated design functions, design leadership at executive level, and design representation in product decision-making. The structure Cooper argued for is now standard.

The goal-directed design methodology has been incorporated into the broader design canon. Specific methodologies like Jobs-to-be-Done (Clayton Christensen, Bob Moesta) and outcome-driven innovation (Anthony Ulwick) extend the goal-directed framing in different directions, but the foundational shift Cooper articulated — from features to goals — is now the default mental model for serious product designers.

The chapter on the invisible cost of bad design is still worth reading. Many organizations still under-invest in design because the cost of bad design is hard to measure in engineering metrics. Cooper's articulation of the cost is one of the few pieces of writing that quantifies it well.

Where the book has aged less well

The anti-programmer rhetoric is the worst part of the book and the part most worth setting aside. Cooper consistently characterizes programmers as anti-social, design-hostile, user-blind — characterizations that are unfair to the many programmers who care deeply about users and contribute substantively to design quality. Modern engineering culture in serious product organizations has incorporated significant design sensitivity; the binary opposition Cooper draws between programmers and designers no longer matches the reality.

The framing of design as something programmers cannot do is also too binary. Many of the best modern designers started as programmers. Many of the best modern programmers contribute meaningfully to interaction design. The discipline boundaries Cooper draws are real but more porous than the book suggests.

The book pre-dates modern collaborative product team models. Cooper's framing assumes a hierarchical structure where designers are given authority over engineers. Modern product trios operate as peer collaborations rather than hierarchies. The shift to peer collaboration has produced better outcomes than the designer-supremacy model Cooper proposes, but the book's argument predates and does not address it.

The book is centered on enterprise desktop software, which was the dominant context in 1999. Mobile, consumer web, AI-driven interfaces, voice — all are absent or treated only briefly. The principles transfer but the specific examples often feel foreign to modern readers.

The persona methodology, while foundational, has been extended and refined since the book was published. Modern persona practice includes JTBD-style framings, behavioral cohort definitions, and outcome-driven personas that the book does not address. Pair the book with current persona writings for completeness.

How to actually apply this

The single most-leveraged thing to do after reading is to audit your team's persona practice. Do you have personas? Are they specific, named, based on research, focused on goals? Are they referenced in design reviews and prioritization conversations? Or are they decorative artifacts produced once and shelved?

If the personas are decorative, fix them. Interview 10-15 real users in your primary segment. Identify patterns. Build 2-3 detailed personas with names, contexts, goals, frustrations, and behaviors. Bring them to your next prioritization conversation. Reference them explicitly: "Would Sarah use this feature?" The discipline of explicit persona reference forces the team to defend product decisions on behalf of specific users rather than against abstract assumptions.

A second application: audit your goal-directed design practice. For your next major feature, before discussing implementation, list the specific goals the relevant persona is trying to accomplish that the feature would serve. Design backward from the goals. The shift from feature-thinking to goal-thinking often reveals that the feature as scoped is not actually the right solution to the user's goal.

A third application: examine your team's structure. Does design have real authority on interaction decisions, or is design subordinated to engineering convenience? Does the design leader sit at the same table as the engineering leader? If the structural authority is not there, the design quality will not be either, regardless of how talented the designers are.

How this book fits with the broader design canon

The Inmates Are Running the Asylum is a foundational text but no longer the right first read for design education. The right reading order:

1. The Design of Everyday Things by Don Norman — foundational vocabulary.
2. Don't Make Me Think by Steve Krug — practical web usability.
3. About Face by Alan Cooper — Cooper's more comprehensive design methodology textbook.
4. The Inmates Are Running the Asylum by Alan Cooper — the polemical argument for design authority.
5. Continuous Discovery Habits by Teresa Torres — modern customer research integrated with design.
6. Lean UX by Gothelf and Seiden — modern team collaboration on UX.

The combination produces a comprehensive design education. Cooper's book is best read after About Face (his actual textbook), because the polemical argument lands harder when you understand the methodology it is defending.

For PMs specifically working in engineering-dominated cultures, the book has additional value as a vocabulary for advocating design investment. The arguments Cooper makes are arguments PMs can adapt in their own organizations.

Annotated passages worth underlining

On the cost of bad design. Cooper writes that the cost of bad design is paid by users, who blame themselves; by companies, which lose customers without understanding why; and by society, which absorbs the externalized cost of products that fail their users. The framing of design cost as externalized is sharp and worth carrying. PMs who internalize it argue more effectively for design investment because they can quantify the externalities engineering metrics miss.

On personas. Cooper writes that without specific personas, product debates default to abstract users that anyone can claim to represent. The vagueness is what makes design-by-committee fail — every committee member has a different imagined user. Personas force the conversation onto specific users that can be discussed concretely. The shift from "users want X" to "Sarah needs X" is the discipline that makes user-centered design real.

On goal-directed design. Cooper writes that goal-directed design produces software that feels obvious because it is built backward from what the user is trying to do. Software built forward from features tends to feel arbitrary because the user has to figure out which feature serves their current need. The reframe from features to goals is one of the most leveraged moves in product design.

Common critiques

Critique: the anti-programmer rhetoric is unfair and dated. True. Modern serious product organizations include programmers who contribute substantively to design. The binary opposition Cooper draws is too sharp. Read past the rhetoric for the methodology.

Critique: the book is centered on enterprise desktop software and feels foreign to modern contexts. Partially fair. The examples are dated. The principles transfer but the application requires extrapolation.

Critique: the prescription for designer authority over engineering is incompatible with modern peer-collaboration trio models. True. The modern trio model is generally accepted as better than designer-supremacy. Read Cooper's prescription as a historical argument for design investment, not as a current organizational model.

Critique: personas are sometimes used as theater rather than as decision-making tools. Fair, but the failure mode is not Cooper's fault. The book is clear that personas only work if used continuously in real product debates. Teams that produce decorative personas have abandoned the methodology, not implemented it badly.

A closing thought

The Inmates Are Running the Asylum is a book whose arguments have largely been won. The prescriptions Cooper made in 1999 — design as a distinct discipline, designer authority in product decisions, personas as standard practice, goal-directed design methodology — are now the default in serious product organizations.

The fact that the arguments have been won is the book's success. Read it now as historical context for why modern product organizations are structured the way they are, and as a foundational text on the persona methodology that every PM should understand.

The book's limitations — the anti-programmer rhetoric, the dated examples, the designer-supremacy framing — are real and worth reading past. The core methodology is sound, the persona discipline is foundational, and the argument for design investment is one PMs in engineering-dominated organizations can adapt for their own contexts.

For most PMs in 2026, the book is not in the top five PM reads, but it is worth knowing. The persona methodology specifically is foundational; reading Cooper's original articulation of it deepens understanding in ways that secondary sources cannot. Borrow the book from a library, read the persona chapters carefully, skim the polemical chapters, and pull out the lessons that apply to your context. The investment is modest; the methodology compounds for years.

A final note on Cooper's broader work

Alan Cooper wrote multiple books on design that are worth knowing about even if you do not read them all. About Face (now in its fourth edition, co-authored with multiple collaborators) is his comprehensive textbook on interaction design and is the definitive reference for the methodology. The Inmates Are Running the Asylum is the polemical companion that argues for the structural changes needed to make the methodology possible. Together they constitute the most complete articulation of the Cooper school of design.

For PMs who want to go deeper on interaction design specifically, About Face is the more useful book. The Inmates Are Running the Asylum is the more entertaining read and the better foundational text on personas specifically. Most PMs benefit from reading the persona chapters of About Face and the broader argument of The Inmates Are Running the Asylum, without committing to either book in full.

The field owes Cooper a substantial debt. The methodology he helped invent has shaped how serious product organizations design software. The arguments he made for design investment have shaped how those organizations are structured. The persona methodology specifically has become so widespread that its origins are often forgotten. Worth remembering, worth reading at least once.

A deeper look at the persona methodology

Because personas are the book's most lasting contribution, they deserve a closer treatment. Cooper's framing of personas has been refined and extended over the past two decades; the modern best practice combines his foundational structure with additions from JTBD, behavioral cohorts, and outcome-driven innovation.

The structure of a useful persona. A modern persona typically contains: a name and photo (so the team can refer to a specific person), a one-line summary, a context paragraph (who they are, where they work, what their world looks like), goals (what they are trying to accomplish in the product domain), pain points (what is currently frustrating or expensive), behaviors (what they actually do today), and quotes (verbatim language from real interviews). The optional fields — demographics, tech savviness, channels — should be included only when they shape product decisions. Many personas include too much; the discipline is to keep only what is referenced in actual product debates.

How many personas. Most products serve 2-4 personas well. More than that and the team cannot keep them straight; product decisions devolve into "well, persona 7 needs X, but persona 12 needs Y" and nothing gets done. The discipline is to identify the 2-4 personas that represent the largest, most strategic, or most underserved segments and accept that other users will be served less well. The non-target personas are still real users; they are simply not the ones the product is optimizing for.

Primary, secondary, supplemental. Cooper's hierarchy matters. Primary personas are the ones the product is most centrally designed for; decisions optimize for them when in conflict. Secondary personas have needs the product accommodates without optimizing. Supplemental personas are edge cases that get accommodated where possible without compromising the primary experience. Being explicit about the hierarchy prevents the all-too-common pattern of trying to please every persona equally, which produces a product that serves none of them well.

Updating personas. Personas should be revisited annually. Customer bases shift. New segments emerge. Old segments mature. Personas built in year one of a product are often wrong by year three. The discipline of annual persona refresh — re-interview, re-synthesize, re-rank — keeps the methodology grounded in reality rather than calcified in outdated assumptions.

Using personas in real conversations. The most common failure mode is the decorative persona — produced once, hung on the wall, never referenced. The fix is explicit citation. In every prioritization conversation, every design review, every strategy debate, someone should be asking "what would persona X think of this?" The discipline of citing personas in real debates is what makes the methodology pay off.

How personas have evolved since Cooper

Several refinements have emerged since the book was published.

JTBD-style personas. Bob Moesta's Jobs-to-be-Done framework reframes personas around the "job" the user is hiring the product to do. A JTBD persona is less about demographics and more about the situation that triggers the user to seek a solution. The framing is complementary to Cooper's — many modern personas combine both, with the persona representing who and the JTBD representing what they are trying to accomplish.

Behavioral cohort personas. Modern data infrastructure lets teams build personas from actual behavioral patterns rather than from interview synthesis alone. Power users vs casual users, weekly actives vs monthly actives, multi-feature users vs single-feature users — each behavioral cohort can be a persona, with the persona's characteristics derived from data rather than imagined. The data-driven personas are typically combined with qualitative interview data to add the human context numbers cannot provide.

Outcome-driven personas. Anthony Ulwick's outcome-driven innovation framework adds explicit outcome metrics to personas — the specific results a persona is trying to achieve, measurable in dimensions the persona cares about. The framing makes personas more actionable for prioritization because outcomes can be sized and tracked.

Anti-personas. A useful modern addition. An anti-persona is a specific user the product is explicitly NOT designed for. Being explicit about who you are not building for is as important as being explicit about who you are. Anti-personas prevent feature requests from sympathy-driven extensions of the persona base — "but what about the users who do Y?" "Y is the anti-persona. We are explicitly not building for them."

Living personas. Personas as living documents updated based on new research, behavioral data, and product evolution. The annual refresh discipline mentioned above is one expression of this. Some teams maintain personas in shared docs or in tools like Dovetail that integrate them with research repositories.

The political economy of design authority

A theme that runs through Cooper's book, mostly implicit, is the political economy of design. Design authority in an organization is fought for, not granted. Cooper's argument for designer authority over engineering decisions is in part a political argument — design needs structural power to do its job.

The political reality has shifted since 1999. Most modern serious product organizations have given design substantial structural authority — design leaders sit at executive level, designers are peers to PMs and engineers in trios, design has veto power on many UX decisions. The shift was not automatic; it was won through the kind of arguments Cooper was making, plus decades of demonstrated impact from companies that took design seriously (Apple being the most-cited example).

For PMs in organizations where design does not yet have this structural authority, Cooper's book remains useful as an argument they can adapt. The specific tactics Cooper proposes — explicit interaction design as a discipline, personas as a methodology, goal-directed design as a process — give the PM and the design partner specific things to advocate for. The advocacy is hard but the path is well-trodden.

A final reflection on Cooper's legacy

Alan Cooper has been less culturally prominent in recent years than some of his peers — Don Norman, Steve Krug, Jakob Nielsen — partly because his work was more polemical and partly because his consultancy was more focused on enterprise software than the consumer products that dominate modern tech discourse. But his influence on the field is comparable.

The persona methodology is his most lasting contribution. The argument for interaction design as a discipline is his second. The goal-directed design framework is his third. Each has shaped how thousands of product organizations actually operate.

The book is not the best first design read for a modern PM. The Design of Everyday Things and Don't Make Me Think serve that role better. But The Inmates Are Running the Asylum is worth reading at some point in your career, both for the methodology it teaches and for the historical context it provides. Most modern PM design vocabulary traces back, directly or indirectly, to the arguments Cooper made in this book and his broader body of work.

For PMs in 2026, read it after the foundational design books, treat the methodology as foundational, set aside the polemical rhetoric, and apply the persona discipline. Your product judgment will compound for the rest of your career.

A walkthrough of building your first persona set

For PMs who have never built personas from scratch, the methodology can feel abstract. A concrete walkthrough helps.

Step 1: Identify the segments worth studying. Pull behavioral data on your active users. Slice by signup source, by usage intensity, by plan tier, by company size, by role. Look for clusters that have different behavior patterns and different outcomes. The clusters are your candidate segments for persona research. Typically 4-6 candidate segments emerge from a careful data slice; you will probably narrow to 2-3 for actual persona work.

Step 2: Recruit interviews per segment. For each candidate segment, recruit 8-12 users for 30-45 minute interviews. The user research chapter of Continuous Discovery Habits is the right methodology guide. Pay the interviewees ($75-150 typical). Aim to complete the interviews within 3-4 weeks; longer than that and the freshness of comparison fades.

Step 3: Conduct interviews with the trio. PM, designer, and one engineer in each interview. Take notes individually; debrief jointly after. The trio's combined observation produces a richer picture than any one of them could alone.

Step 4: Synthesize patterns. After all interviews are complete, gather the trio for a 2-3 hour synthesis session. Cluster observations by theme. Identify the common goals, common pain points, common behaviors per segment. The patterns should emerge clearly; if they do not, more interviews may be needed.

Step 5: Draft personas. For each segment that shows clear patterns, draft a persona. Give them a name, a context, goals, pain points, behaviors, a quote from a real interview. Keep them to one page each. Resist the urge to include every detail; the persona is useful in proportion to how memorable and citable it is.

Step 6: Pressure-test with stakeholders. Show the personas to sales, customer success, support. The patterns should match what they see in their daily customer contact. If sales says "I don't recognize this customer type," the persona is probably wrong or the segment is unusual. Iterate.

Step 7: Publish and use. Put the personas in a shared space the team can reference daily. Reference them in every prioritization conversation, every design review, every roadmap debate. Within 30 days, the team should be citing them by name in conversation without prompting.

The whole process takes 6-8 weeks the first time. Subsequent refreshes take 3-4 weeks because the methodology is internalized. The investment pays back across hundreds of product decisions over the years that follow.

The persona anti-patterns to avoid

A few specific failure modes show up when teams adopt the persona methodology.

The marketing persona disguised as a product persona. Marketing teams sometimes produce personas focused on demographics, channels, and messaging triggers. These are useful for marketing but not for product decisions, which need behavioral and goal information. Product personas must focus on goals, behaviors, and frustrations — not on the demographics that marketing personas emphasize.

The aggregated persona. A persona that is "the average user" is useless because no real user is average. Personas must be specific representations of identifiable segments, not statistical averages.

The aspirational persona. A persona that describes who the team wishes their users were rather than who they actually are. Aspirational personas produce products designed for users who do not exist while ignoring users who do. The discipline is to base personas on actual research, not on the team's hopes.

The static persona. A persona created once and never updated. Customer bases shift; persona accuracy decays. Annual refresh is the minimum cadence.

The too-many-personas problem. Teams that produce 10+ personas dilute the focus that the methodology is supposed to create. Aim for 2-4 personas with clear primary/secondary/supplemental hierarchy.

The decorative persona. A persona that exists but is never cited in real decisions. Decorative personas are theater. Either use them or kill them.

Recognizing these anti-patterns and avoiding them is what makes the difference between a persona practice that pays off and one that becomes wallpaper.

The argument for design as a P&L investment

A subtle but important framing in Cooper's book is that design should be treated as a P&L investment, not as a cost center. Most engineering-dominated organizations treat design as a service function — designers are headcount that supports engineering, and design investment is justified only by its contribution to engineering efficiency. Cooper argues that this framing is wrong; design is a primary driver of business outcomes (conversion, retention, brand equity, customer satisfaction) and should be invested in accordingly.

The framing has real implications. A design organization with 1 designer per 10 engineers is structurally undersized for any product that depends on user experience. A design organization with 1 designer per 3-4 engineers is closer to the right ratio. Companies that have shifted to the higher ratio (Apple, Stripe, Figma, Linear, Airbnb) consistently outperform on product quality and on the business metrics that follow.

For PMs at organizations where the design ratio is unhealthily low, the conversation about design investment is a strategic one. Cooper's argument provides vocabulary and framing. The business case — bad design produces externalities the organization is paying without measuring — is the right way to frame it. The conversation is hard but the path is well-trodden by companies that have made the shift before.

A note on the Cooper consultancy and the broader Cooper school

Alan Cooper's consultancy, Cooper, was acquired by Designit in 2017 and has continued to influence the design field through its alumni network. Many of the modern design leaders in tech started at Cooper or were trained by Cooper alumni. The persona methodology, the goal-directed design framework, the broader Cooper school of interaction design — these continue to shape how serious product organizations think about design today.

For PMs interested in the broader Cooper school, Cooper's other book About Face (now in its fourth edition, co-authored with multiple Cooper alumni) is the comprehensive textbook. It is much longer and more detailed than The Inmates Are Running the Asylum and is the right reference for anyone who wants to go deep on interaction design methodology. The Inmates is the polemical companion; About Face is the working manual.

Together they constitute the most complete articulation of one of the most influential schools of design thinking in modern tech. The school's influence is now so pervasive that its origins are often forgotten. Worth remembering, worth at least one Cooper book in your design education, worth the persona discipline applied to your team's practice this quarter.