Main idea

SSO probably isn't what differentiates a payroll product from its competitors. Neither is pushing events into the customer's SIEM, nor data residency, nor delegating permissions to the customer's IAM.

None of these blocks solves the business problem the product is bought for. And the absence of any one of them can be enough to stop a deal.

They do not create the value. They let the value enter the enterprise — which is another function, and not a minor one.

The same reversal happens inside the product, where you expect it even less. An application that slows down under load can call for a month of work on a queueing technology: the developers train up, rework part of the architecture, and ship no visible business value for the end user. That effort can nonetheless remove a bottleneck, make it possible to absorb ten to thirty times the load simply by adding servers, and free up sales, who will sell new customer access without fearing the application will freeze. A building block is therefore not judged on what it brings to the product, in either direction: what counts is the deal it makes possible or prevents.

Layer added by "Product Decision Record: tracing the product choices that shape the company" (2026-06-03).

Why it matters

This invalidates the most common piece of reasoning in roadmap arbitration: "it brings nothing to the product, so it can wait." An access block is not assessed on what it adds, but on what it unblocks.

And the measure is binary, not gradual: a customer who cannot deploy doesn't buy a little less, they don't buy.

Nuances and limits

The argument can justify anything if you don't bound it: every customer request then becomes blocking. It holds only for blocks whose absence genuinely prevents deployment at the customers being targeted.

And those blocks carry a permanent maintenance cost that no business value will later offset.

Open questions

• How do you check that a block is genuinely blocking, rather than demanded by a well-placed contact?