Productise the Second Time, Not the First

Premise: The right moment to turn a piece of work into a reusable product is not when you imagine doing it again. It is the moment you have just done it once, well, and the proof is still warm.

There is a recurring temptation for anyone building systems: see a task, decide it will recur, and build the general tool before you have done the specific job even once. It feels efficient. It is usually waste. You generalise from an imagined instance, and the abstraction encodes your assumptions instead of the real shape of the work.

This week ran the correct sequence instead, and the contrast is instructive.

The two sessions

The first session was concrete and unglamorous. A client, a sole-practitioner professional, needed his small website updated and a training guide so he could maintain it himself. Real edits, a real handover document, a real deployment, a real scoped access token. Roughly two and a half hours of specific work for one named person. Nothing reusable was built. The point was to finish the job.

The second session, the next day, took forty minutes. It turned that proven instance into a reusable skill: a structured workflow that any future client of the same type can be run through. A micro-site factory for non-technical professionals.

The order matters. The product was extracted from a proven instance, not invented ahead of one.

Why the order is the whole point

When you build the general tool first, you are guessing at the variation you will encounter. You guess wrong, because you have not met the variation yet. The abstraction calcifies around your first imagined case, and every real case afterward has to be bent to fit it.

When you extract from a proven instance, the tool inherits the empirical shape of work that actually closed. You know which steps were load-bearing because you just did them. You know which decisions mattered because you just made them. The validation is free: the design is a one-to-one extraction of a session that already worked.

The first version of the skill made exactly the over-fitting mistake, and it was instructive that it did. It cloned the specific client too closely. It assumed every future client would be in the same profession as the first one. The structure was shaped to education because that was the only instance it had seen.

The correction that made it general

One line of feedback fixed it: research needs to be baked in, because the next client might be an IT professional, or a nutritionist, or a piano teacher, not another educator.

That feedback did two things. It added a mandatory research step at the front, so the tool profiles the actual client before producing anything. And it forced a taxonomy: a small set of profession categories, each with its own design palette, its own page structure, its own tool ideas and content archetypes.

The durable asset is rarely the tool. It is the structured knowledge the tool stands on.

The taxonomy file does more work than the skill that uses it. It encodes years of pattern recognition across professional website types into reusable recipes. Any future build, not just this one skill, can draw on it. The skill is the delivery mechanism. The taxonomy is the compounding asset.

This is the part worth internalising. When you productise, the visible deliverable is the tool. The valuable deliverable is the reference knowledge you were forced to make explicit in order to build it. The tool will be rewritten. The taxonomy will outlive three versions of the tool. I have made a related argument about people: your role is becoming a skill, and the knowledge you externalise is the part that compounds.

The research-first default

The redesign enforced one more principle worth stating on its own: the tool profiles the audience before it produces a single line of output.

This sounds obvious and is routinely skipped. The fast path is to start from the practitioner's own framing of what they do. The better path is to start from the audience's pain points, which requires a research step the practitioner cannot give you because they are too close to it.

Content and builds that start from researched audience need outperform content that starts from the maker's self-description. Baking the research step in as mandatory, rather than optional, is what separates a tool that produces generic output from one that produces fitted output.

The honest limit

The skill is designed, not yet exercised. The real quality gate is the first live run with a client who is not the original one. If the next client is an IT professional, the research step will classify them, propose a fitting design, and recommend tools appropriate to their field, all before any output exists. That first unlike-the-original run will reveal what the design missed.

This is the correct state to ship in, and worth naming as a principle: a productised workflow is validated by its first divergent use, not by its construction. You do not know the abstraction holds until something that is not the original instance flows through it cleanly.

What to take from this

1. Do the specific job first, completely, before you generalise. The proof of what is reusable is a closed instance, not an imagined one.
2. Extract, do not invent. A tool built one-to-one from a session that worked carries that session's validation for free.
3. The reference knowledge is the asset, not the tool. Whatever you are forced to make explicit to build the tool is the part that compounds. Treat it as a living document.
4. Validate on the first divergent use. The abstraction is unproven until something unlike the original passes through it.

Build the second one as a product. Build the first one as a job. Confusing the two is how you end up maintaining an abstraction that never met a real case.

Part of the Product Pipeline series from KG Consultancy.