Case study
One survey per client, or one framework for all of them.
A request for a customer satisfaction survey, redirected into a product the organisation could run for every tenant without rebuilding it each time.
The situation
The ask was a customer satisfaction survey for one client. Straightforward, and the third time that year the same thing had been built. Each version worked, none of them were the same, and none could be handed to the next client without rework.
The cost was not in any single build. It was that the organisation was accumulating survey implementations rather than a survey capability.
What happened
I redirected the request from a per-tenant build into a reusable framework, and the work went into the parts that are boring to specify and expensive to retrofit:
Scoring that handles both NPS and CSAT logic, because different clients ask for different models and neither should require a new build. Multilingual from the start, since retrofitting language into a survey already in the field means reissuing it. Recipient rules, so the right people are asked at the right point rather than everyone after every ticket. Opt-out and privacy handled once, correctly, rather than per tenant — the part that is cheapest to build early and most expensive to get wrong. Reporting consistent enough that results from different tenants can actually be compared.
The redirect cost more up front than the survey that was asked for. It stopped the fourth and fifth versions being built at all.
The result
A survey product the organisation could deploy per tenant through configuration rather than development, with the privacy and opt-out behaviour identical everywhere because it was written once.
The moment to turn a request into a product is when you notice you are building the same thing again with different names. That is rarely the moment it gets noticed, because each individual request is small and refusing to just build it looks obstructive.
The test is whether the next one is cheaper. If every version costs the same, you are running a service, not building a product — which is a legitimate choice, but it should be a choice.
Refusing to just build the survey looks obstructive, and every individual request is small enough that the refusal is hard to justify. Nobody asks for a framework. They ask for the thing in front of them, and the thing in front of them is reasonable.
The redirect also cost more up front than the survey that was asked for, which is the whole difficulty: the saving is in builds that then never happen, and you cannot point at work that did not occur. The only honest case is the pattern — three versions already existed and none could be handed to the next client.
Common questions
When should a request become a product?
When you notice you are building the same thing again with different names. That is rarely when it gets noticed, because each request is small and refusing to just build it looks obstructive.
What goes into a reusable survey framework?
The parts that are boring to specify and expensive to retrofit: scoring that handles both NPS and CSAT, multilingual support from the start, recipient rules, opt-out and privacy handled once, and reporting consistent enough to compare tenants.
How do you tell a product from a service?
Whether the next one is cheaper. If every version costs the same, you are running a service — a legitimate choice, but it should be a choice.
Your turn
Bring me the list nobody's willing to question.
Twenty minutes, no pitch. If I'm not the right person, I'll say so and point you somewhere better.