Frictionless SaaS, Chapter 24: Anti-Patterns and Failure Modes

This is the final chapter teaser in the series on Frictionless SaaS: Designing Products Users Discover, Adopt, and Never Leave. The previous post was Chapter 23: Pattern Libraries and Proven Approaches, where we walked through the Fast Activation Pattern Library and the Frictionless Onboarding Catalog.

Chapter 24 is the one I debated the most when I was writing the book. I could have ended on a high note — the experience moat, the pattern library, the optimistic stuff. Instead I chose to end on anti-patterns, because in my experience, product teams learn faster from knowing what to avoid than from knowing what to build. You can study a hundred examples of good onboarding and still ship a bad one if you do not recognize the specific traps you are about to fall into.

Why anti-patterns matter

Here is something I've observed across almost every SaaS team I've worked with: the people shipping anti-patterns know better. They've read the blog posts. They've studied the Stripes and Slacks of the world. And yet the anti-patterns ship anyway, because they sneak in through perfectly reasonable-sounding decisions. "We need onboarding completion to look good for the board." "Power users told us they wanted this option." "Marketing needs the checkbox defaulted to on."

Each decision feels rational in isolation. Together, they turn into the product you never meant to build.

The Anti-Pattern Registry

The first half of Chapter 24 catalogs what I call the Anti-Pattern Registry: seven specific mistakes that show up over and over again in SaaS products, with concrete examples of how to spot them and how to fix them without breaking anything else. The registry covers:

1. Mandatory Onboarding — forcing users through a tour before they can see the product they signed up for. Reasonable-sounding. Almost always wrong.
2. Jargon Dump — making users feel stupid with terminology they don't know yet. The reason Stripe's documentation is legendary is that they refused to do this.
3. Orphaned Feature — building a feature and never integrating it into the user journey, so users only find it by accident (or never).
4. Inconsistent Interaction Model — different parts of the same product working three different ways, destroying the intuition users would otherwise develop.
5. False Defaults — choosing default values based on your business metrics instead of what users actually want. Short-term win. Long-term trust erosion.
6. Dark Pattern — UI designed to trick users. The one I'm most willing to be preachy about, because it's not just unethical, it's bad business.
7. Overwhelming Choices — presenting every option to every user, every time, on the theory that "more choice is always better." It isn't.

The Feature Trap: when more is less

The second half of the chapter introduces what I think is the most important and most dangerous anti-pattern of all — the Feature Trap.

The Feature Trap is the tendency for SaaS products to quietly accumulate features over time in ways that slowly make the product worse. Each feature individually seems reasonable. Each feature serves some subset of users. But collectively, they create UI bloat, cognitive overload, and support complexity that erodes the experience for everyone. And the most insidious part is that it sneaks up gradually — there is no single moment where someone says "let's make this product worse." There is just a hundred small moments of saying yes to the next feature.

The chapter breaks down exactly how the Feature Trap manifests, why it creates a vicious cycle of bad prioritization, and — most importantly — the only escape: ruthless prioritization and occasional subtraction. Subtraction is harder than addition. When you add a feature some users get happy; when you remove one some users get upset. But there are moments in a product's life where subtraction is the only move that keeps it alive, and the chapter uses Basecamp's famous feature subtraction as a case study for how to do it right.

I won't spoil the section on how to build the cultural discipline required to say no to features — that's probably the single most useful two pages in the book for any product leader trying to escape the trap — but I will say that it requires leadership buy-in, product vision clarity, measurement discipline, and the courage to occasionally remove things. Most teams have maybe two of those four. The chapter explains how to get the other two.

Additional failure modes

The chapter closes with a handful of failure modes that are less about design patterns and more about strategic blind spots:

• The Ignore-Local-Context Failure — a global product that assumes American defaults and ignores how work actually happens in other regions.
• The Neglected-Integration Failure — designing a product as if it lives in isolation, when in reality your users live inside a dozen other tools all day.
• The Poor Error Recovery Failure — treating errors as endpoints instead of as opportunities to help users recover.
• The Accessibility Failure — building the product without considering users with disabilities, which is not just a compliance issue but a friction issue for everyone.

Each of these is a quiet killer of experience, and each is easier to prevent than to fix after the fact. The book covers the early warning signs for each one and the specific questions you should be asking in design reviews to catch them before they ship.

The rest of the book: appendices as a working toolkit

If you make it to the end of Chapter 24, you're actually not at the end of the book — there's a substantial appendix section that I think is the most practically useful part for any team that wants to put this stuff into practice. The appendices include:

• Appendix A: Activation & Retention KPI Templates — the metrics that actually matter (TTFV, Activation Rate, NRR, Onboarding Completion, Feature Adoption, Days to Feature Adoption, Churn Rate), with definitions, calculations, benchmarks, and interpretation notes for each.
• Appendix B: Event Tracking Schema — a concrete event schema you can adapt directly, covering activation events, feature usage events, friction events, and monetization events.
• Appendix C: Lifecycle Messaging Templates — copy-and-adapt templates for Welcome, Onboarding Check-in, First Success Celebration, Expansion Opportunity, and Churn Prevention messages, with timing and channel guidance.
• Appendix D: Friction Audit Checklist — a systematic walk-through across Signup, Onboarding, Core Workflows, Feature Discovery, Help & Support, Settings, Performance, and Accessibility.
• Appendix E: Framework Reference Guide — a quick-lookup index of every framework introduced in the book, with one-line descriptions and chapter references.

The appendices are designed to be used, not just read. If you've been following along with this blog series and want to go from reading about frictionless design to actually auditing your own product, that's where I'd start.

Closing the series

This is the last chapter teaser in the series. Twenty-four chapters, twenty-four frameworks and patterns and anti-patterns, all pointing at one idea: In a world where features are commoditized overnight and AI can replicate your capabilities in days, the only lasting advantage is the experience you design around everything else. That experience is not built in a single sprint. It is built decision by decision, anti-pattern avoided by anti-pattern avoided, feature subtracted by feature subtracted.

If you've been reading along, thank you. And if you want the full treatment — every framework, every pattern, every case study, and all five appendices in one place — the book is where the whole system fits together.

— Sho Shimoda