Product strategy for accounting firms, before the build

Start with the process, not the product

The idea almost never arrives as a problem. It arrives as a solution. Somebody says the firm needs a client portal, and the portal is the shape of the conversation before anyone has said which task it removes, from whom, and what that task currently costs.

Translating it back is where most of the scope disappears. A partner meeting will produce four candidate processes and a shared sense that all of them hurt. One is usually worth building against, and it's rarely the one with the loudest advocate. It's the one that costs the most and can't be fixed by deciding something.

The order matters more than the analysis. Process first, then what it costs, then whether anything you already own closes the gap, and a build only if it survives all three. Run it the other way round and you'll spend the discovery budget specifying a portal rather than finding out whether the firm needs one.

Buy, configure, or build

This is a three-way decision and it almost never gets held open as one. By the time somebody is asking what a build would cost, the firm has usually ruled out configuring what it already owns without checking, and skipped past buying because a demo went badly two years ago.

Practice management and client portal software is a mature category, and that cuts both ways. It means something close to what you want probably exists. It also means the only thing worth measuring is the gap between your process and the one the category assumes, because that gap is what you'd be paying to build.

This question is also a fast way to judge anyone you might hire. Ask what they'd tell you not to build, and listen for whether the answer is ready or improvised. A firm that has never talked a client out of anything has never had the conversation.

What discovery actually runs through, in order

Discovery gets sold as a vague thinking phase, which is why firms resent paying for it separately. Run properly it's a sequence with an output at every stage, and you can check it as it goes rather than waiting for a document at the end.

The order carries most of the value. Each stage exists to kill a version of the idea cheaply, and the stages that get skipped for time are reliably the ones that would have killed it.

1. 1. Sit with the person who runs the process

   Not the partner who owns it, the person who performs it. Walk one real client through the whole thing in the actual system, and write down every exception mentioned in passing. Those exceptions are what no process diagram has ever contained and what breaks a build in month four. An afternoon here changes more scopes than a week of workshops does.

2. 2. Put a number on what it costs

   Hours per client per cycle, multiplied by your client count, then checked against the season rather than an average month. Do the same for the client's side of it if they're involved. Most firms find one step dominates and two they were worried about barely register. Every decision after this gets weighed against that number, so get it honestly.

3. 3. Rule out the cheap fixes

   Two of them, in this order. A process change, where a step survives only because nobody has revisited a decision. Then configuration, where the thing you want already exists in software you're paying for. Both resolve in weeks rather than quarters. If either closes most of the gap, discovery has paid for itself and the build stops right here.

4. 4. Name the assumption the whole idea rests on

   In a firm the assumption is nearly always about behaviour rather than technology. Will clients use this instead of emailing you, and will your own staff use it instead of working around it. Write it as a sentence someone could later be proved wrong about. If the first release doesn't test that sentence, the release is aimed at the wrong thing.

5. 5. Draw the first release and its edges

   Draw the paths first, then write the edges. The drawing is the easy half. The list of what this release deliberately leaves out, and why each thing is out, is the half that gets skipped and the half that matters. Every exclusion is a small argument with somebody, which is why it's harder. It's also what stops a first version from quietly becoming the whole system.

6. 6. Define done, and define change

   Both get written before any work starts, which is the only time either one is genuinely negotiable. Acceptance criteria settle what done means while nobody yet has an interest in the answer. A change process settles the route for a request nobody has made yet. Every firm asks for changes. The ones that go badly are the ones where the route got invented under pressure.

7. 7. Make the decision explicitly

   Discovery ends with a recommendation, and it has to be said out loud. Build this, build a smaller version of it, or don't build. A plan that arrives without a recommendation hands the judgment back to the people who went looking for a partner precisely because they didn't have it. Ours names which of the three, and why.

Productising a service is a delivery change first

Turning an advisory service into a product means fixing its scope, its inputs, its outputs, and what's explicitly excluded. That's a delivery decision and it's the hard part. Software makes a standardised process faster. It cannot standardise one for you, and trying to make it do so is how firms end up with a tool nobody uses.

Fixing the scope means four specific things: naming the inputs you require before you'll start, naming the outputs a client gets and the form they arrive in, setting how many rounds of back and forth are included, and writing down what pushes a client out of the standard version into a custom one. Most firms hold all four opinions already. They're just held in different partners' heads and have never been reconciled.

A useful test: could you run the productised version manually, for three clients, next month, with a spreadsheet and a checklist? If not, you don't have a product yet, you have an intention. Run it by hand for one cycle first. Everything that breaks becomes the specification, and it's a much cheaper place to find out.

What the first release has to prove

A first release is an argument, not a version. It should be small enough to ship inside one quiet quarter and pointed squarely at the assumption that would sink the whole idea if it turned out to be wrong. Everything that isn't testing that assumption is a candidate for the second release instead.

Whatever it's pointed at, the result has to be something you'd notice without commissioning a study. A number of clients using it without being chased. A step that stopped producing internal email. A partner who no longer reviews something by hand. Conditions like better efficiency are unfalsifiable, which is comfortable at the time and useless a year later when nobody can say whether it worked.

It runs alongside, not instead

The version of this that fails is the switch-over. A new process replaces the old one on a chosen date, inside a firm that cannot afford a bad week, and the first unexpected thing sends everyone back to the old way permanently.

Run both for a cycle instead. It costs more in the short term and it's the only version that leaves anyone a way back on a bad day, which is what makes the change stick.

Running both properly means naming the exit in advance. Pick the cycle, pick the handful of clients, and decide what result ends the pilot rather than extending it. Pilots without an exit condition don't fail. They carry on until everybody stops mentioning them, and the old process becomes the permanent answer by default.

What you end up with, and what each part prevents

A scoped plan, and the word plan undersells it. Every item in it exists because of a specific way a build goes wrong, and the ones that look most like paperwork are doing the most work.

It's also the mechanism that makes a fixed number possible. A team can only commit to one when the scope is written to the level where both sides would agree on whether a given thing was inside it. An underspecified scope is where fixed-price work actually goes wrong, and that's a different failure from the one people usually blame fixed pricing for.