A TRIZ Session: How to Guarantee Your Launch Destroys the Company

TRIZ is the Liberating Structure where you stop asking “how do we succeed?” — a question that invites platitudes — and instead ask “how could we reliably guarantee the worst possible outcome?” People are funnier, faster, and far more honest designing a disaster than defending their current process. Then comes the trap you set for yourself: you compare the disaster recipe to what your organization actually does today, and the resemblances stop being funny.

The Sonos May 2024 launch is ideal fuel for this exercise because the disaster is real, recent, and fully documented — and because nobody at Sonos was stupid or malicious. Every ingredient of the failure was a reasonable-sounding decision made under a date. This post is the complete session: case brief, three-step activity, facilitator’s answer key, and debrief.

Time: 45–50 minutes · Group size: 4 to 40+ (tables of 4) · Materials: flip charts or a shared doc per table, sticky notes, the case brief below.

The case brief (read aloud, 5 minutes)

In May 2024, Sonos replaced the app controlling every Sonos speaker in the world with a ground-up rewrite. It shipped missing alarms, sleep timers, local music library playback, and accessibility features blind users depended on. No opt-out, no rollback — every customer was force-migrated overnight. The app was reportedly required infrastructure for the Ace headphones launch, and that window was not moving.

The bill arrived on a schedule: a public CEO apology in July 2024; roughly 100 layoffs and a $20–30 million remediation estimate in August; a 16% year-over-year revenue drop in the SEC-filed fiscal fourth quarter; and the CEO’s exit on January 13, 2025. Eight months from update to the top of the org chart.

The question the case leaves open — and this session answers — is: what would you have to do, systematically, to make this outcome inevitable?

The activity

Step 1 — Design the disaster (12 minutes)

Invitation: “You are the leadership team of a beloved hardware company. Your goal is to guarantee — reliably, repeatably — that your next major software launch destroys customer trust, cuts revenue, and costs the CEO their job. List everything you could do to achieve this unwanted result.”

Run it as 1-2-4-All: one minute of silent solo listing, two minutes in pairs, four minutes in tables of four consolidating, then collect the best items on the main flip chart. Push for concrete, operational items — “communicate badly” is weak; “make the CEO sign the apology only after the revenue drop is filed” is a keeper. Encourage dark humor; it’s doing diagnostic work.

Step 2 — The uncomfortable comparison (12 minutes)

Invitation: “Go down your list, item by item, and ask: is there anything we are currently doing that in any way, shape, or form resembles this?”

Same 1-2-4-All rhythm. Enforce the rule: this list may only contain things you actually do, with real examples — no hypotheticals, no “we might.” The facilitator’s job here is to protect honesty: no defending, no explaining why the resemblance is justified. Just capture it.

Step 3 — First stops (10 minutes)

Invitation: “For each real behavior you identified, what is the first step to stop it?”

Note the verb: stop, not fix, not improve, not add a process. TRIZ creates space by removing counterproductive activity, not by layering new activity on top. Each table commits to one stop-doing item with an owner and a date.

Debrief (8 minutes)

• Which disaster ingredient was easiest to invent? (It’s usually the one closest to home.)
• What landed on the Step 2 list that surprised the table?
• Who in our org has the authority to move a date once something commercial is attached to it — and when did they last use it?

The answer key (facilitator’s reference)

You don’t hand this out. It exists so the facilitator can seed a stalled table, and so that at the end you can show the room they independently reinvented the actual Sonos playbook.

Step 1 — a strong disaster list maps almost one-to-one to what happened:

Invented sabotage	What Sonos actually did
Weld the release to an immovable commercial date, so the software must conform to the calendar	The app was reportedly required for the Ace headphones launch window
Replace everything at once — big-bang rewrite, no incremental rollout	Ground-up rewrite shipped to the entire install base in one motion
Remove the escape hatches: no opt-out, no rollback, no old version	Forced migration; customers could not get the old app back
Redefine “done” downward as the date approaches, cutting features customers depend on daily	Shipped without alarms, sleep timers, local library, accessibility
File engineers’ warnings under “risks to the date” instead of “information about the product”	The gaps were known; the window won
Test on paying customers instead of beta users	Customers became beta testers of hardware they already owned
Keep accountability diffuse until it suddenly isn’t	Apology in July, layoffs in August, CEO out in January

Step 2 — resemblances that reliably surface in real teams: dates announced externally before scope is known; “MVP” scoping decided by the calendar rather than the customer; release trains with no rollback story; QA and accessibility treated as post-launch backlog; risk registers where every entry is a risk to the date and none is a risk to the customer; retros that produce action items but never remove a practice.

Step 3 — stops with teeth: stop announcing dates before a rollback plan exists; stop letting scope cuts happen without the customer-facing impact written down and signed; stop holding launch reviews that only rehearse the success case; stop treating “we need more time” as a performance problem instead of as data.

What the session actually teaches

The punchline is that no table ever struggles with Step 1. Given ten minutes, any group of practitioners can design the Sonos disaster from scratch — which proves the failure mode is not exotic knowledge but a default trajectory. Organizations drift into it whenever a date acquires commercial machinery and stops being what it really is: a hypothesis that the product will be ready.

Sonos held the date and moved the definition of done. What it shipped on May 7, 2024 was therefore not a product but a gap — the distance between the announcement and the software — delivered directly into customers’ living rooms. The invoice arrived over eight documented months, and it was ultimately paid by the person who had the authority to move the date and didn’t.

TRIZ works on this case because it inverts the question organizations refuse to answer directly. Nobody in a launch review will say “we’re shipping a broken product to protect a marketing window.” But everyone in a TRIZ session will cheerfully write that on a disaster list — and then go quiet when asked what, in any way, shape, or form, resembles it at home. The space this structure makes is the space between those two moments. What your team stops doing in that space is the session’s actual deliverable — because as Sonos demonstrated at SEC-filing scale, the date never was.

Further reading

• Making Space with TRIZ (Liberating Structures) — the canonical description of the structure, its steps, and its facilitation tips.
• Sonos Shipped the Date, Not the App — the full case study behind this session, with the sourced timeline and the SEC filing.
• The Surprising Power of Liberating Structures by Henri Lipmanowicz and Keith McCandless — the book behind all 33 structures, including TRIZ.