---
title: "Most of what I know cannot be productised, and finding the line took building the product"
url: "https://consultantmagazine.co/insight/most-of-what-i-know-cannot-be-productised-and-finding-the-line-took-building-the-product/"
author: "Daria Turanska"
published: "2026-10-01"
updated: "2026-10-01"
---

# Most of what I know cannot be productised, and finding the line took building the product

Productising expertise is usually described as writing down what you know. That framing is why so many attempts produce an expensive library nobody uses. What you are actually looking for is the subset of your judgment that survives being separated from the client in front of you, and that subset is smaller and stranger than it looks from the inside.

I spent fifteen years drafting contracts before I built a product out of it. At FasterDraft (https://fasterdraft.com) the product generates legal documents from a set of questions the user answers, with logic in the document that switches passages on and off depending on those answers. That architecture turned out to be an unusually precise instrument for finding the boundary, because a condition either can be written or it cannot. There is no partial credit.

Here is what that revealed. The advice itself was never the hard part. Any competent practitioner can state the rule. What resists productisation is the step before the rule, where you decide which of several defensible positions fits this client, given facts they have not told you yet and priorities they have not articulated. I could write the clause. I could not write the condition that selects it, because the selection depended on things that are not questions with answers.

That distinction is the whole game, and it has a practical test attached. Take any piece of your work and try to express the decision as a question a client could answer about themselves without your help. If you can, it is a candidate for productisation. If every attempt produces a question that really means "tell me what I would conclude if I looked at your situation", you have found the edge, and no amount of workflow tooling will move it.

The common failure is to productise the artifact rather than the decision. The deliverable is the visible part, so it is what gets templated: the report, the deck, the agreement, the checklist. But the deliverable was never the scarce thing. Your client could obtain a structurally correct version of it almost anywhere. What they were paying for was the judgment that determined which structurally correct version they should have, and that judgment usually lives in a conversation nobody wrote down.

So the templated artifact goes out, and it is fine, and it is also worth a fraction of what the engagement was worth, and the firm concludes that productising does not work for this kind of work. What actually happened is that they packaged the cheap half.

The more useful move is to split the engagement rather than replicate it. Some genuinely mechanical portion can be pushed to the client or to software, which is where the efficiency comes from, and the remaining part is smaller, denser and more clearly worth what you charge for it. That is uncomfortable, because the mechanical portion is often what justified the hours. Efficiency here is not a cost saving applied to the same service. It is a change in what the service is.

Something else I did not expect: the boundary is a strategic answer, not just an operational one. Once you know precisely which decisions can be encoded, you know what kind of business you are able to build. If almost everything encodes, you have a software company and should price accordingly. If almost nothing does, you have a practice, and efficiency will come from better selection of clients rather than better tooling. Most firms sit somewhere in between and have never established where, which is why their productisation projects tend to wander between the two models and satisfy neither.

The other thing worth flagging is where the real work lands once you commit. Building the decision logic took far longer than writing the content, and that ratio surprised me every single time. Structuring the questions, working out their order, deciding what happens when a user gives an unusual combination of answers, all of that is a design discipline in its own right and it is not the expertise you are famous for. Firms that budget for the content and treat the logic as configuration consistently run out of money at the point where the thing would have started working.

Finally, a caution about the direction all of this is moving. Generative tools have made the production of a plausible deliverable close to free, which strips out whatever remained of the artifact's value and pushes the entire proposition onto the judgment layer. That is good news for anyone who has already located their boundary and bad news for anyone whose offering was mostly a well-organised document.

Work out which half of your work a machine can select, not just produce. That is your product, and the rest is your job.

---

Daria Turanska is the Legal Manager at [FasterDraft](https://fasterdraft.com).
