Building a Behavioral Growth Playbook for QuickBooks Online

A pattern library, a governance layer, and a set of behavioral directives — designed to be a corrective system, not a catalog.

In brief. Following a behavioral audit of QuickBooks Online, Intuit commissioned a behavioral growth playbook to translate the diagnosis into something the product organization could ship against. The work produced three connected artifacts — behavioral design principles, a governance layer, and a pattern library — delivered as a single codified reference site the organization can use day to day. The playbook is the corrective system the audit pointed at.

The starting point

The audit produced the diagnosis. The playbook had to produce the response.

A diagnosis on its own is not a deliverable. A leadership audience can absorb a finding like "the product is consuming the trust its expansion revenue depends on" — but a product organization can't ship against it. The work between "here's what's wrong" and "here's what to build" is where most behavioral engagements either earn their fee or fail to land. A pattern library is the bridge, but only if it's built as a system — a connected set of principles, governance, and patterns that depend on each other to work.

The risk of building it any other way is specific and worth naming. A pattern library shipped as a catalog — a collection of independent recipes teams can pick from — inherits the same incentive structure that produced the original failures. Without a layer above the patterns enforcing which pattern is appropriate when, teams will reach for whichever pattern fits their KPI in the quarter they're shipping. The catalog becomes a menu of justifications rather than a corrective system. That outcome was the thing the playbook had to prevent.

So the work was scoped to produce three layers, each one constraining the next:

• Behavioral directives — the principles every pattern has to satisfy
• A governance layer — the routing logic that tells teams which pattern applies in a given moment
• The pattern library itself — the specific design patterns, organized as a causal chain

The order matters. Principles before governance, governance before patterns. Each layer is the audit's load-bearing argument expressed at a different altitude.

Behavioral directives

The directives are the principles that govern every pattern in the library. They translate the audit's findings into the design rules the patterns have to satisfy, expressed in language a designer or PM can use in a critique.

They're organized into three tiers, each with a different weight in the review process. Laws are non-negotiable — a pattern that violates a Law doesn't ship until it's resolved, regardless of other merits. Rules are evaluated at lifecycle-critical moments — onboarding, plan changes, offboarding, renewal. Principles are evaluated across time and tracked in aggregate.

The tiered structure was deliberate. A flat list of "guidelines" gets ignored under deadline pressure because nothing in the structure tells reviewers what's worth blocking a ship over. The tier system gives reviewers explicit escalation language: a Law violation is not a design preference, it's a documented behavioral risk with a traceable audit lineage. That distinction makes governance work in a way that "best practices" documentation never does.

Every pattern in the library traces to one or more directives. A pattern that can't be traced to a directive should not be in the library. A pattern that violates a Law should not exist in the product. The directives are what make the library defensible — they're the reason any individual pattern can't be argued out by a stakeholder who'd rather ship something easier.

The governance layer

The governance layer sits above the pattern library and answers one question for any team about to ship: given what you know about the user's context and intent, which pattern applies?

It's a decision framework. A team plans to surface a feature, communicate a plan tier, or prompt an upgrade. They follow the tree. The tree terminates at a named pattern. That pattern's specification tells them what to build. The work upstream of selection is structured; the work downstream of selection is constrained.

The governance layer also makes one structural distinction that turned out to do most of the work: it separates triggered discovery from voluntary discovery. A user who clicked into a feature and hit a gate is in a fundamentally different behavioral state than a user who navigated to an exploration surface by choice. Conflating the two — applying interruptive patterns to surfaces users chose to visit — is the error that recreates the original interruption problem with better copy. The governance layer makes that distinction structural rather than judgment-dependent.

A second piece of the governance work was naming an explicit dependency chain across the patterns themselves. Several patterns can only function if other patterns are already in place. Implementing a well-timed upgrade prompt on top of an undifferentiated communication channel produces an offer users still can't decode. The dependency chain documents which patterns are foundational and which depend on them — and it does so in a way that makes piecemeal implementation visible as a risk rather than a convenience.

The governance layer is the part of the playbook teams encounter every day. The pattern specs are the reference material; the governance layer is the day-to-day workflow.

The pattern library

The pattern library itself contains 18 behavioral design patterns, organized into four themes. The themes are the audit's diagnosis expressed as a corrective sequence.

• Make value visible — Patterns that surface the product's automated work in the user's perception, so renewal isn't a pure cost decision.
• Earn the right to ask — Patterns that tie expansion offers to behavioral signals of readiness rather than calendar timing.
• Protect signal quality — Patterns that structurally differentiate educational, transactional, and promotional communications so users can decode intent before reading content.
• Design for reversibility — Patterns that make exits symmetric with entries, on the principle that friction designed to prevent departure produces resentment rather than loyalty.

You can't earn the right to ask if the signal channel is already corroded. You can't make value visible if the communication channel has already been written off. The themes are sequenced because the underlying behavioral failures are sequenced, and the corrective patterns have to be implemented in roughly the same order to work.

Each pattern in the library is documented to the same specification: the behavioral failure it addresses, the hypothesis behind it, the directives it satisfies, the buyer psychology mechanism underlying it, the conditions that trigger it, the constraints on what it must never do, and the success metrics for knowing whether it's working. The specifications are deliberately not wireframes. They are the spec a wireframe is derived from — which means the library can be implemented by any competent product team without being held hostage to a specific visual interpretation.

The constraints section in each pattern spec turned out to be unusually important. Patterns fail more often by drift — being reused for the wrong purpose — than by initial misdesign. Naming the failure modes explicitly inside the spec is what keeps a pattern in its lane after the original engagement is over.

A coded deliverable

The decision worth flagging is the form the deliverable took.

Behavioral and growth work is usually shipped as a deck, a Figma file, or a long-form document. Each of those is fine for the moment it's presented and progressively less useful from the moment the meeting ends. Decks live in shared drives no one revisits. Figma files become artifacts of a specific moment in time. Docs get skimmed once and bookmarked, then drift out of currency as the product changes around them.

A pattern library asked to do real work over a multi-quarter horizon needs to live somewhere teams will actually return to. So the playbook was delivered as an internal reference site — a self-contained, navigable, searchable web artifact containing the directives, the governance layer, and the full pattern library in a single codified system.

That format does several things a deck can't:

• It's the same artifact for everyone. A designer, a PM, a researcher, and a growth manager all consult the same source. There's no "the version in someone's deck" problem — the reference site is the canonical version.
• It's navigable by intent. A team about to ship a feature surface can start at the governance layer, follow the decision tree, and land on the specific pattern spec they need. A team auditing existing work can start at the directives. A new hire onboarding into growth can read the themes. Each entry point is supported by the structure.
• It's maintainable. The reference is structured so that updates — to a pattern, a directive, or a routing decision — propagate through the system rather than requiring a new deck. The artifact ages with the product instead of against it.
• It signals what the work is. A deck signals "presentation." A reference site signals "infrastructure." The format communicates that the playbook is meant to be used, not approved-and-archived.

The codification choice isn't decorative. A pattern library exists or doesn't exist based on whether teams reach for it under pressure. A reference site sitting at a known URL is reachable from a critique, a sprint planning meeting, or a design review in a way that a slide deck never is. The format is part of what makes the system durable.

What the three layers do together

Each layer is incomplete without the other two.

The directives without the governance layer are aspirational — designers and PMs agree with them in principle and route around them under deadline pressure. The governance layer without directives is bureaucratic — it routes teams to patterns without any underlying argument for why those patterns are the right ones. The patterns without governance are a catalog — a menu of options teams pick from based on what's most convenient.

Together, the three layers form a connected system: the directives say what's true, the governance layer says which pattern applies here, and the patterns say what to build. That structure is what makes the playbook a corrective system rather than a reference library.

It's also what makes it portable. The specific patterns are tuned to QuickBooks, but the three-layer architecture — directives, governance, patterns — works for any product organization with a similar diagnosis. The playbook is a worked example of a structure I'd build for any client facing the same underlying conditions.

What I learned building it

The biggest lesson was about sequencing. The temptation, when delivering a pattern library, is to lead with the patterns — they're the most concrete, the most visually satisfying, and the easiest for stakeholders to react to. Leading with patterns produces faster stakeholder engagement and worse outcomes. Stakeholders evaluate the patterns on visual merit, debate them as preferences, and the underlying argument never lands.

Leading with directives — getting agreement on the principles before showing any pattern — is slower in week one and dramatically faster from week two onward. Once the directives are agreed, every pattern review becomes a check against the principles rather than a debate over taste. The work converges faster because the criteria converge first.

The second lesson was that governance work expanded as the engagement progressed, and I now scope it that way from the start. Pattern libraries without a routing layer become catalogs — and catalogs do not change products.

The third lesson was about constraint specifications. Every pattern in the library has an explicit list of what it must never do. That section was the most useful one for teams who picked up the library after the engagement ended — it's the part that survives the loss of the consultant. A pattern is only as durable as the constraints written into its spec. The library will be edited and adapted long after I'm gone; the constraints are what keep it from drifting back into the failure modes it was built to correct.

Why the audit is the right place to start

The audit and the playbook are two engagements, but they are one continuous piece of work. The audit produces the diagnosis. The playbook is the response. Neither makes complete sense without the other.

Which is why I think the most important thing the audit does isn't deliver findings. It clarifies what the right follow-up actually is — and how that follow-up should be structured to address the underlying conditions rather than the surface symptoms.

In this engagement, the audit made it unambiguous that the next move had to be a three-layer playbook delivered as a codified system. A catalog of recommendations wouldn't have worked. A set of redesigned screens wouldn't have worked. A roadmap of feature investments wouldn't have worked. The diagnosis pointed at a governance and signal-quality problem, which meant the response had to be a governance and signal-quality system. Any other response would have been treating the symptoms.

That's the real value of an audit done well: it doesn't just tell you what's wrong. It tells you what kind of intervention the problem actually requires — and protects you from spending the next quarter solving the wrong problem with the wrong shape of solution. The playbook is what this audit pointed at. A different audit, in a different organization, would point at something different. The discipline is the same.

If you're considering a behavioral audit, the most useful question to ask isn't "what will the audit find" — it's "what kind of follow-up will the audit make obvious." A good audit gives you a clear answer to that question, and a defensible plan for what the next engagement should look like.

This case study is published with the cooperation of the Intuit / QuickBooks team. All evidence cited is drawn from public sources, published behavioral research, and the engagement's public-data methodology.

- Jonathan Pierce, Pierce & Co.