Main idea

A regulatory audit module can be delivered in two ways that look alike in a demo. The first carries out the task: the customer enters the data, the module checks it, the box is ticked. The second leaves them with something they didn't have — they understand what the standard requires of them, they produce evidence that stands up to an auditor, they draw on a knowledge base they would never have built alone. After using it, they can do one more thing.

This is a third direction for customer knowledge, alongside what a company knows about its customers — segments, constraints, obligations — and what it learns from them — stories, objections, workarounds. Knowledge can also travel back to them, in the form of a capability the product hands over.

Kathy Sierra gave the formula in Badass: Making Users Awesome: "Don't build better cameras — build better photographers." Quality is then observed in the user, not in the product.

Why it matters

This gives a basis for comparison where two products are at functional parity. When the feature lists overlap, what is left to separate them is what each one makes its customer capable of doing, and that doesn't line up in a comparison table.

It also opens a product outlet for knowledge capital that is usually justified by prioritization. The material accumulated about a trade — its obligations, its traps, its practices — can be handed back to the customer inside the product, and not only serve to decide what to build.

Nuances and limits

The criterion doesn't hold everywhere. Some building blocks are designed to ask nothing of anyone and teach nothing to anyone: an authentication service, a payment gateway, a backup. Their success is to stay invisible, and added capability there would be a nuisance.

Making someone capable also backfires at times: a customer who understands their own subject becomes capable of handling it differently, including without the product.

And added capability measures badly, where a task carried out can simply be observed — which makes it hard to defend before a leadership team comparing feature perimeters.

Open questions

• How can a request for proposals, which is expressed in expected features, carry a requirement for added capability without immediately retranslating it into a list of features?