Projects vs products: the most expensive confusion in legal tech

The most expensive sentence in legal innovation is “we’ve built a product.” Most of the time, it isn’t true - and the gap between what the firm built and what it thinks it built is where a lot of budget quietly dies.

Firms are very good at projects. A project has a sponsor, a scope, a deadline, a go-live, and a celebration. The entire culture of a law firm - matter-based, deadline-driven, billable - is optimised for projects. So when a firm decides to “do innovation,” it reaches for the tool it knows, runs a project, ships something, and calls the something a product.

It usually isn’t. And knowing the difference is the single most useful distinction I can give anyone trying to build inside a firm.

The actual difference

A project ends. A product is maintained. That’s the whole thing, and almost everything else follows from it.

A project is defined by its completion. You scope it, build it, ship it, and you’re done - the value is in having finished. A product is defined by its continuation. Shipping it is the start of the work, not the end. It has users who change, edge cases that surface, a model underneath that drifts, regulations that move, and a second and third client who need it to be slightly different without breaking it for the first.

When a firm builds an internal tool as a project, it does everything right up to go-live and then nothing afterwards - because in project culture, after go-live there’s nothing left to do. There’s no owner, no roadmap, no budget for the boring second year. Six months later the tool is subtly wrong, nobody is fixing it, and it joins the graveyard of things the firm “built” and no longer uses.

The four questions that tell you which one you have

You can diagnose any legal-tech initiative with four questions. If you can’t answer them, you have a project wearing a product’s clothes.

1. Who owns this in two years? Not who built it - who owns it once the original team has moved on, the enthusiasm has faded, and it just needs to keep working. If the answer is “nobody” or “we’ll figure that out,” it’s a project.
2. What happens when it’s wrong? Every product is wrong sometimes. A real product has a feedback loop - a way for a user to flag the bad output and a process that turns that flag into a fix. A project has a complaints inbox nobody reads.
3. Can the second client use it without rebuilding it? A project solves one situation. A product solves a class of situations. If onboarding the second user means most of the work again, you built a bespoke thing, not a product, however nice the interface is.
4. Does it get better, or just older? Products improve with use - more data, more feedback, more edge cases handled. Projects only age. If there’s no mechanism by which usage makes the thing better, it will only get worse from here.

Why firms keep making this mistake

It isn’t stupidity. It’s incentives. Project work is legible to a law firm: it has a defined cost, a defined end, and a partner who can take credit at the go-live. Product work is illegible: it’s an open-ended commitment to maintain something, owned by someone whose success is measured in a way the firm’s systems don’t recognise, generating costs in years two and three with no celebration attached.

So firms systematically over-invest in the launch and under-invest in everything after it - which is exactly backwards, because for a product everything after the launch is the product. The demo is cheap. The decade is expensive. Firms keep budgeting for the demo.

There’s also a quieter reason: products require admitting you don’t know the answer yet. A project pretends the requirements are knowable up front - scope it, sign it off, build to spec. A product assumes you’ll learn what it needs to be by watching people use it, which means committing before you have certainty. That’s a genuinely uncomfortable posture for a profession trained to nail everything down in advance.

The honest default

Most firms should run fewer projects pretending to be products, and be much clearer about which they’re actually doing.

If the goal is to solve one situation, once - run a project, call it a project, don’t pretend it’ll scale, and don’t be surprised when it doesn’t. That’s a perfectly good thing to do, and naming it correctly stops you from over-investing in a launch that doesn’t need one.

If the goal is something that serves a class of work for years, then commit to the thing project culture hates: a named owner whose job is the second year, a feedback loop, a maintenance budget, and the acceptance that go-live is the beginning. Do that and you might build a product. Skip it and you’ll build a very expensive project, hold a launch party, and quietly retire it before its second birthday - which is, more or less, the story of most legal innovation budgets to date.