Cause of death: the small stuff got waved off as cosmetic, and cosmetic was never what it was actually signaling.

Partway through the demo, something small is visibly off. A field labeled “Custmer Grp” with the typo still in it. A report total that’s correct but formatted with the wrong currency symbol. An old menu item labeled “Legacy Approval, do not use” still sitting in the navigation where everyone can see it. Someone in the room notices, points at the screen, and the presenter waves it off without breaking stride. “That’s cosmetic, we’ll clean that up before go live, doesn’t affect the numbers.” The room nods and moves on, because the thing being demonstrated, the actual functional capability, did in fact work correctly.

Nobody asks the question that actually matters here, which isn’t “does this affect the numbers.” It’s “what does leaving this visible tell the two hundred people who are about to start using this system every day.” That’s the autopsy. The defect itself was never the problem. What it signals is.

What actually happened

Broken windows theory, originally a criminology idea from the early nineteen eighties, argues that visible, unaddressed signs of disorder, a broken window left unrepaired, graffiti left up, don’t just reflect neglect, they actively invite more of it, because their presence signals that nobody is watching and nothing gets enforced. The mechanism isn’t about the broken window causing damage on its own. It’s about what an unrepaired window communicates to everyone who sees it about whether this place has an owner who cares.

The same mechanism runs through a go live environment with unusual precision. A typo in a field label, a leftover legacy menu item, a report that’s functionally correct but visually sloppy, none of these break anything on their own. What they do is tell the first cohort of real users, on day one, before anyone has formed a habit yet, that quality here is negotiable. A user who sees an obviously wrong field label on their first day draws a reasonable, entirely rational inference: if that got through, my own sloppy data entry probably will too. Nobody enforces the small stuff here. The inference isn’t about that one field. It’s about the whole system’s apparent tolerance for error, and it gets formed in the first few days, before the system has any track record to override it.

Small defects waved off in a demo compound specifically because they arrive stacked. One typo alone probably wouldn’t shift anyone’s behavior. A demo that’s waved off three or four small things in a row, cosmetic each time, individually defensible each time, has quietly established a pattern before go live even happens.

Why it works on smart people

Triage is a genuinely good practice, and drawing a line between functional bugs and cosmetic ones is a reasonable way to prioritize limited time before a deadline. The instinct to wave off a typo isn’t wrong on its own terms. Where it goes wrong is in applying an engineering severity framework, does this affect the calculation, to a question that was never actually about calculation. Users don’t experience a system the way an engineer categorizes a bug ticket. They experience it as a single continuous impression of whether the place is cared for, and that impression doesn’t sort itself into functional and cosmetic buckets the way a backlog does.

There’s also a time pressure effect specific to go live weekends. By the time anyone’s looking at a stray legacy menu item or a mislabeled field, the team is usually exhausted, focused on the handful of things that could actually cause a financial misstatement or a blocked transaction, and a cosmetic issue genuinely does rank lower by every reasonable prioritization framework available in that moment. The framework is correct. It’s just answering a different question than the one that actually determines early adoption behavior.

The actual damage

This is the one that shows up as a slow erosion in data quality that nobody can point to a single cause for. Three months after go live, free text fields that were supposed to use standardized values are full of inconsistent entries. A workaround process has formed around the one screen that still has a visibly awkward layout, because early users concluded, correctly, that nobody was watching that screen closely. None of this traces back cleanly to the typo in the field label from the go live demo, but the typo, and the two or three cosmetic issues that sat alongside it, unaddressed, in the very first days anyone used the system, set the tone that made the rest of it feel acceptable.

The remediation cost here is unusually high relative to how small the original defects were, because by the time the erosion is visible enough to act on, it’s a data quality and behavior problem spread across the user base, not a five minute fix to a field label. Fixing the typo now costs the same five minutes it always would have. Fixing six months of inconsistent data entry that grew out of the signal the typo sent does not.

The fix, if you’re the one presenting, or the one buying

Fix the visible small stuff before go live specifically because of what it signals, not because of whether it moves a number. If a genuine deadline forces a trade off, say so honestly and specifically to the people who’ll be using the system, “we know this field label is wrong, it’ll be fixed by Friday, here’s how to report anything else you notice,” rather than letting it sit silently and be discovered on its own. The difference between an acknowledged, tracked flaw and a silent, ignored one is exactly the difference between an owner who’s watching and one who isn’t, and users read that difference correctly, every time.

The typo was never going to break a journal entry. What it broke, quietly, was the first impression of whether anyone was going to notice if they didn’t get their own entries right either.

Standardization is exactly the governance broken windows theory argues for, and it’s worth asking what happens when it erodes at scale, not just in one field label. In Is Vibe Coding the End of Standardized ERP?, I look at what happens when every business starts generating its own bespoke operating logic with no shared standard to enforce consistency. A thousand small ungoverned deviations, each individually reasonable, is the broken windows problem running at the scale of an entire industry instead of one field label.

Cause of death: the competitor being demoed against would not have recognized itself.

Midway through the pitch, the slide changes to a comparison. Two columns, sometimes three. Your product on one side, the competitor on the other, a row of checkmarks and X marks running down the middle. The competitor’s column is thinner than it should be. A feature they shipped eighteen months ago is marked absent. A limitation they fixed two releases back is presented as current. The pricing comparison uses the competitor’s list price against your negotiated discount. By the end of the slide, the choice looks obvious, because one column was built by a team with every incentive to make it look that way, and the other was built by nobody in the room.

Nobody in the room raises a hand and asks when this comparison was last verified. That’s the autopsy. A competitive comparison built entirely by one side, unchecked by the other, isn’t a comparison. It’s a résumé written by an opponent’s rival, and it gets read with the same scrutiny either way, which is to say, functionally none.

What actually happened

Every competitor’s product roadmap moves faster than any comparison sheet does. A gap that was accurate when a sales engineer built the deck eighteen months ago has, more often than the room assumes, already been closed, sometimes through a native feature, sometimes through a partner integration or a marketplace add-on that isn’t visible from the outside but is entirely visible to the competitor’s actual customers. The comparison sheet is a snapshot with no expiration date printed on it, presented as though it were current.

The pricing rows compound the distortion in a specific, predictable direction. List price for the competitor, negotiated or promotional price for the vendor doing the presenting, is close to the default comparison method, and it isn’t dishonest in the narrow sense, both numbers are real, but it compares two different stages of the same negotiation, one that hasn’t happened yet against one that has. A prospect who hasn’t negotiated with either vendor is looking at the least favorable version of one price and the most favorable version of the other.

Feature checkmarks suffer the same collapse the Security Theater Demo’s checklist suffered. “Supports multi-currency” or “has a mobile app” is either true or false on the slide, with no room to indicate that one vendor’s version is a fully native capability and the other’s is a third-party add-on with a separate contract, a separate support line, and a separate bill.

Why it works on smart people

A side-by-side comparison has the visual grammar of objectivity. Two columns, symmetric formatting, a neutral-looking checkmark or X, all of it borrows the credibility of a spec sheet or a lab test, something that feels like it was measured rather than argued. The room’s guard is lower here than almost anywhere else in the demo, precisely because the format looks like data rather than persuasion, even though the party assembling the data has an obvious and undisclosed conflict of interest in every cell.

There’s also a research-avoidance effect. Verifying even a handful of rows against the competitor’s actual current documentation, or a call with their team, takes real time that a sales cycle often doesn’t budget for, and the comparison slide offers a shortcut that feels like due diligence without requiring any. Accepting the slide as accurate is the path of least resistance, and it’s a path built specifically to be the easiest one to take.

The actual damage

This is the one that produces a decision built on a comparison that was already stale, sometimes badly, by the time the contract was signed. A capability marked absent for the competitor that had actually shipped means the losing vendor was disqualified on a false premise, and the winning vendor’s genuine advantages, whatever they actually were, never had to be defended on their own merits because the comparison did the work for them.

Once implementation starts, the gap between the comparison sheet and reality becomes the buyer’s problem, not the vendor’s. If the deciding factor was a feature gap that didn’t actually exist, the buyer is now living with a vendor selected on the wrong basis, discovering the real trade-offs only after the switching costs have become substantial.

The fix, if you’re the one presenting, or the one buying

If you’re presenting, date every comparison row and be specific about the source, and if there’s a real chance a competitor has closed a gap since, say so rather than let a stale advantage stand unchallenged. If you’re buying, treat any vendor-supplied comparison as a hypothesis to verify, not a finding to accept. Take the three or four rows that would actually change your decision and check them directly against the competitor’s current documentation or a live conversation with their team, rather than checking all thirty rows equally or none of them at all.

A comparison chart built by one side and verified by neither side is not a comparison. It’s an argument wearing a spreadsheet’s clothes, and it deserves exactly the scrutiny an argument gets, not the trust a measurement earns.

The Waterdeep Trading Company runs on the same principle at its literal gates. In Receiving Controls That Stop Bad Goods, nothing becomes sellable stock on the strength of a seal or a claimed count alone. It gets checked at the gate, every time, regardless of who’s vouching for it. A competitive comparison deserves the same standing policy: verify before it enters the decision, not after.

Cause of death: confidence borrowed from someone who was never actually going to be there.

Ten minutes into the meeting, or sometimes ten minutes before the end of it, a calendar notification pulls someone senior into the call. A VP, sometimes higher. They say a few warm, general things about strategic partnership and long-term vision, take one or two softball questions, and leave for their next meeting. The room’s posture changes almost immediately. If someone at that level is personally invested enough to show up, even briefly, this must really matter to the vendor. The deal, whatever doubts existed five minutes earlier, now feels more serious.

Nobody asks what “personally invested” is actually going to mean six months from now, when the invoices are contested, the timeline slips, or the implementation team needs an escalation path that goes higher than the account manager. That’s the autopsy. The executive’s presence proved that a calendar invite got accepted. It proved nothing about what happens after the meeting ends.

What actually happened

An executive sponsor cameo is a highly efficient transfer of credibility from a person to a deal, and the transfer costs the vendor almost nothing to make. Ten minutes of a VP’s time is genuinely cheap relative to the deal size being discussed, and the effect on the room is entirely disproportionate to that cost, because the audience reads presence as commitment. It rarely is. In most organizations selling anything of this size, senior leaders make these appearances routinely, across many simultaneous deals, as a normal part of their job, not as a signal that this particular account has been elevated to a special tier of personal attention.

The deeper issue is that the thing actually being evaluated, whether the vendor will show up when the implementation gets hard, is not a property of any one person’s goodwill. It’s a property of organizational structures: escalation paths, contractual service levels, account team continuity, whether the people doing the actual implementation work have the authority and resources to fix problems without waiting on approval from someone three levels up. None of that gets tested by a cameo. A cameo tests whether an executive’s assistant could find a ten-minute gap in a calendar.

There’s also a durability problem the cameo doesn’t address. The VP who dropped in with warm words about the partnership may be gone, reorganized, or reassigned to a different portfolio before the implementation is even a third of the way done, which happens routinely in any organization above a certain size. The relationship the room felt reassured by was never actually contracted. It was a mood, generated in a room, that has no mechanism for surviving contact with an org chart six months later.

Why it works on smart people

Status carries information in most human interactions, and that heuristic is usually reasonable: when someone senior spends scarce time on something, it often does signal real priority. The problem is that the heuristic breaks down specifically in situations, like enterprise sales, where the cost of the senior person’s time has been deliberately minimized to make the signal cheap to send. A genuine ten-minute cameo and a fully commissioned, resourced executive sponsorship look identical for the ten minutes you can observe them. They diverge entirely in the six months you can’t.

There’s also a reciprocity dynamic at play. A senior person taking time to personally reassure you creates a mild social obligation to receive that reassurance graciously, not to interrogate it. Asking a VP who just delivered warm remarks about partnership to specify exactly what escalation authority they’re personally committing to feels confrontational in a way that asking the account manager the same question doesn’t, so the question quietly goes unasked at exactly the moment it would have been most useful to ask it.

The actual damage

This is the one that surfaces the first time something actually goes wrong during implementation and the buyer tries to use the relationship they thought they’d built. The champion emails the VP directly, the way the cameo implicitly invited them to, and gets a response from an assistant, or a redirect back to the account team, or silence, because the VP’s actual involvement was never structured to include personal escalation on operational issues. The confidence the room felt in that meeting has no contractual or organizational form. It was real in the room and evaporated the moment it needed to be load-bearing.

The buyer is left in a worse position than if the executive had never appeared at all, because the cameo specifically substituted for asking the harder, more useful questions about actual escalation paths and account team continuity, the answers to which would have held up regardless of who was in what job six months later.

The fix, if you’re the one presenting, or the one buying

If you’re presenting, don’t let the cameo stand in for structure. If an executive is genuinely sponsoring the account, say specifically what that means: a defined escalation path with their name attached, a commitment to a quarterly check-in that’s on a calendar rather than implied, actual authority to authorize resources if the implementation hits trouble. If none of that exists, the honest version of the cameo is shorter and less dramatic, a courtesy visit rather than a commitment, and it should be presented as exactly that.

If you’re buying, ask the question the warm remarks were designed to make feel unnecessary: what happens, specifically, and who do we call, when this goes wrong. The answer that matters is a name and a process that survives a reorg. The ten minutes in the room, however sincere, was never that.

Genuine organizational attention rarely looks like a scheduled cameo. In The Penguins Knew Before Your Steering Committee Did, the character who actually notices the iceberg melting and does something about it is an unremarkable penguin, not the colony’s formal leadership showing up to reassure everyone for ten minutes. The steering committee structure is the cameo. The attention that actually matters usually comes from somewhere quieter.

Cause of death: the entire session proved the system worked, and none of it proved anyone would use it.

Ninety minutes of demo. Every module clicked through, every workflow shown, every objection about functionality answered on the spot. Then, in the last five minutes, someone asks about training and adoption, and the presenter says something reassuring and short: “the interface is intuitive, users pick it up quickly,” maybe gestures at a slide with a generic icon of people around a laptop, and the meeting ends on schedule.

Nothing in those ninety minutes tested the only variable that determines whether an ERP implementation actually pays off: whether the several hundred people who currently do their jobs a certain way will actually do them a different way starting on a specific Monday morning. That variable got five minutes and a slide. Everything else got ninety.

What actually happened

A demo is, by construction, a test of the system in isolation. It shows what the software can do when operated by someone who already knows exactly which buttons to press, in exactly the right order, with no muscle memory pulling them back toward the old way of doing things. That’s a test of the product. It says almost nothing about the much harder problem sitting underneath every ERP rollout, which is that the system doesn’t fail because it can’t do the work. It fails, when it fails, because the people who were supposed to start using it on day one didn’t, or did so inconsistently, or found a workaround that quietly recreated the old process inside the new tool.

The demo cannot show this risk because the risk doesn’t live in the software. It lives in a warehouse supervisor who has run the same process for eleven years and has a system that works well enough for them, a controller who doesn’t trust the new close process until they’ve watched it succeed three months running, a data entry team that will, absent enforcement, keep using the spreadsheet they built in 2019 because it’s faster for them personally even if it creates downstream problems for everyone else. None of that shows up in a screen share. All of it shows up in the first ninety days of production.

Why it works on smart people

Functionality is legible in a way that adoption risk isn’t. You can watch a screen and evaluate, with reasonable confidence, whether a feature does what it claims to do. You cannot watch a screen and evaluate whether the accounts payable team, specifically, at your company, specifically, will actually change how they process an invoice exception, because that isn’t a property of the software being demonstrated. It’s a property of an organization that isn’t in the room.

Because functionality is the thing that’s easy to evaluate in real time, it naturally consumes the meeting. Evaluators default to spending their scrutiny where scrutiny is possible to apply, and adoption risk, being diffuse, organizational, and only observable months later, gets the leftover attention at the end of the agenda, not because anyone decided it mattered less, but because there was no way to spend ninety minutes evaluating it the way there was for the features.

There’s also a comforting assumption doing a lot of quiet work: that a system good enough to buy will be a system people are willing to use. That assumption is often wrong in a specific, predictable direction. The features that make a system good for the business, tighter controls, more required fields, more visible audit trails, are frequently the exact features that make individual users’ jobs feel harder in the short term, which is precisely the friction that produces workarounds and shadow processes.

The actual damage

This is the failure mode that shows up as an implementation that technically went live and never actually delivered its business case. The system works. The training happened, in the generic sense that sessions were held and attendance was tracked. And six months later, half the intended users are still keeping a parallel spreadsheet, a workaround team has formed around one specific process nobody bothered to redesign for the new tool, and the data quality problems the new system was supposed to fix are still there, because garbage still goes in whenever someone routes around the system instead of through it.

Nobody can point to a single moment this failed. It failed gradually, in a thousand small individual decisions to keep doing things the old way, none of which showed up as a defect, an error, or a support ticket, because from the system’s point of view nothing went wrong. The people just didn’t come.

The fix, if you’re the one presenting, or the one buying

Treat adoption as a first-class item in the evaluation, not a closing slide. Ask the vendor, specifically, what happens to the specific roles in your organization who will feel the most friction from the new process, not the roles who benefit most. Ask what the actual training plan looks like beyond a generic session count, and who owns reinforcement after go-live, when the temptation to slide back into the old process is highest. If you’re the one presenting, bring a real adoption story, with a real friction point that was anticipated and addressed, instead of a slide with a stock photo and the word “intuitive.”

A system that works and a system that gets used are not the same claim, and only one of them was tested in that room.

This is exactly the gap I dug into in Gamification of ERP: Turning Drudgery into Dopamine. Points and badges won’t fix a bad rollout, but the underlying problem, that a system’s success depends on individual motivation, not just individual capability, is precisely the variable this autopsy argues nobody tests before go-live.

Cause of death: the box got checked without anyone asking what checking it actually meant.

Security comes up in most enterprise demos as a single slide, usually near the end, usually delivered fast. Role-based access control. Single sign-on. Field-level security. Audit logging. SOC 2. Encryption at rest and in transit. Each term gets a checkmark, a confident nod from the presenter, and about four seconds of screen time before the deck moves on to something more visually interesting.

Nobody in the room stops the slide. That’s the autopsy. Every term on that slide is real, in the sense that the feature genuinely exists somewhere in the product. What’s missing is any demonstration that it does what the room assumes it does, configured the way your company would actually need it configured, at the depth your actual risk profile requires.

What actually happened

“Role-based access control” is not one feature. It’s a spectrum that runs from a handful of fixed roles with no customization, through role-based permissions you can tailor at the menu-item level, through field-level and record-level security that can restrict a single sensitive column or a single customer’s data from a specific user, through fully dynamic, condition-based access rules that change what someone can see based on context. A vendor can put “role-based access control” on a slide truthfully at any point on that spectrum, and the room has no way of knowing, from the slide alone, which end they’re getting.

The same collapse happens to every other term on the list. “Audit logging” might mean every field change on every table is captured with before and after values and an immutable timestamp, or it might mean a handful of high-level events get logged with no field-level detail. “SOC 2” tells you an audit happened and a report exists. It doesn’t tell you which trust service criteria were in scope, what the exceptions were, or whether the report is even current. “Encryption at rest” is true of nearly every modern cloud platform and tells you almost nothing about key management, who holds the keys, or what happens in a subpoena scenario.

None of this is the vendor lying. Every term is technically accurate. The compression happens in the translation from a nuanced, configurable capability into a single reassuring word on a slide, and the room does the rest of the work by filling in the most generous plausible interpretation of what that word means.

Why it works on smart people

Security and compliance are exactly the kind of topic where nobody in a sales meeting wants to be the person who asks a question that reveals they don’t fully understand the acronym. SOC 2 Type I versus Type II, the difference between authentication and authorization, what “field-level security” actually restricts versus what it merely hides in the UI while leaving accessible through an API, these are legitimate technical distinctions that most people in the room, including some people whose job title suggests they should know them, have only a fuzzy grasp of.

The slide exploits that fuzziness efficiently, not through malice but through pace. There’s no room in a four-second checkmark to unpack what a term actually covers, and stopping to ask “which SOC 2 trust service criteria were in scope” in the middle of a fast-moving demo carries a social cost that quietly discourages the question from being asked, the same social cost that lets the AI Magic Demo’s chat window go unexamined.

The actual damage

This is the one that surfaces during an actual security review, an actual audit, or worse, an actual incident, months or years after the contract was signed. Someone in security or compliance, doing real diligence for the first time, discovers that “field-level security” in this product means the field is hidden in the standard UI but fully readable through the API with the right permission, which is a meaningfully different security posture than what was assumed at signing. Or the SOC 2 report, once actually read line by line, turns out to have scoped out exactly the subsystem your data lives in.

At that point the conversation isn’t a demo follow-up. It’s a risk finding, sometimes one that has to be reported up to a board or disclosed to a regulator, and remediating it after the fact, whether that means additional configuration, a compensating control, or a vendor conversation about contractual commitments, is far more expensive and far more visible than it would have been to ask the specific question up front.

The fix, if you’re the one presenting

Don’t let the slide stand alone. For each term, say what it actually covers and, just as importantly, what it doesn’t. “Field-level security restricts visibility in the standard interface. It does not currently restrict API access to the same field, here’s how customers typically compensate for that.” “Our SOC 2 report covers these three trust service criteria, and here’s the exception list from the most recent period.” That level of specificity costs a few extra minutes and makes the product sound less flawless. It also means the prospect’s actual security review, whenever it happens, confirms what they were told instead of contradicting it.

A checkmark is not a control. It’s a promise that a control exists, and promises deserve exactly as much scrutiny as anything else on the slide.

The same collapse happens to job titles, not just checklist items. In AI Makers Don’t Build Models. They Build Value., a single contested word, “maker,” was doing more work than it could support, and the gap got filled by whoever was listening. A security slide runs on the exact same mechanism, one word standing in for a spectrum, and the room filling in whichever end feels most reassuring.