Contents

Overview

The funding covers platform work, partner work and a regulatory path at once. Each has different customers, different clocks and different ways of failing, and they draw on the same scientists and engineers. This paper sets out how the product function would be built, in the order the work happens.

0.1Core principles

0.2Two ways a product develops

Linear development means the path is knowable at the start. Each step follows from the last, dates can be attached, and the result can be forecast.

Non-linear development means the destination isn't knowable at the start. A capability throws up something odd, the odd thing gets followed, and the end point is somewhere nobody was aiming. It's managed on cost per learning cycle rather than progress against a plan, and most of the time it ends without a product.

Everything that follows is the linear path. The appendix covers how a non-linear one would be spotted and governed, and the one rule that stops it eating the capacity the plan depends on.

0.3Where the business is heading

0.4The order the function gets set up in

The rest of this paper follows the order the work would actually happen in. Each step needs the one before it.

Part 1 — Product development

1.1Understand the business

The first job is a shared picture of how a study actually gets delivered. Not a process document — a blueprint drawn with Operations, Science and Technology in the room, showing who does what at each phase and where the handovers are. It takes a few sessions in the first month and it becomes the source everyone argues from afterwards.

The value of drawing it is that three separate things become visible at once: where expert time goes, where the work fails, and what the work leaves behind.

Three readings of the same map

Every candidate on the roadmap should come from one of those three readings, or from a customer asking. Anything else is someone's preference.

The questions each function asks of the same capability

1.2Find the opportunities

Candidates arrive all the time, informally. Each route knows one thing well and is blind to another, so the route points at the missing evidence rather than whether the idea is any good.

Two mechanisms turn this into something workable. One intake record: what was raised, by whom, when, and what was said back. One short review every fortnight, where a few items get twenty minutes each, presented by whoever raised them. The output is a test to run with an owner and a date, not a decision to build.

Repetition matters more than enthusiasm. The same ask from unrelated accounts, or the same failure across unconnected studies, points at a problem that exists whether or not the person describing it is persuasive.

1.3Frame one

One page, written by whoever raised it, with Product filling the gaps their route is weak on. It replaces the business case, which takes longer, gets read by fewer people, and asks about investment before the problem is settled.

Business impact is a required field. Without it, an item that frees expert hours can't be weighed against one that wins a customer, and the argument defaults to whichever is easier to count.

The hypothesis in one sentence

Written before the test, not after. Fixing the threshold in advance ends the conversation about whether something sort of worked, and it makes a negative result respectable.

1.4Shape it with Technology and Science

The gap that matters sits before a feature becomes a roadmap item: what exactly is being built, and whether Product, Technology and Science are shaping the same thing. Bring Technology in after the decision and architecture follows the roadmap instead of informing it, which is where the reuse and cost trade-offs get lost.

The canvas

Six questions asked together

1. What outcome is being changed — the customer or business outcome, not the feature.
2. What has to be scientifically true, and what evidence proves it.
3. What the workflow becomes, and for whom.
4. The simplest technical shape that could deliver it.
5. Where the human stays, resolved through the boundary test in 1.7.
6. What would make it reusable. If it only works once, it's a service project.

The shaping loop

Six stages. The point isn't passing a committee, it's reducing uncertainty in the right order. Every stage ends in the same four words.

Who decides what

Science and Technology don't need to win every debate. They need a way to stop something that crosses their boundary. Product needs a way to make the trade-off when no boundary has been crossed. Consensus does neither: the loudest function gets an informal veto, or a generalist rules on questions they aren't qualified to rule on.

1.5Prioritise

Two different questions get confused here. Where capacity goes is a portfolio question, answered by the three bands in Part 2. Which item inside a band goes first is a product question, answered here.

First, is it admissible

Six inputs have to be present before an item competes at all. If they can't be answered it goes back for evidence. That alone removes most of the volume without anyone having to say no.

Then, five lenses

A single number that ranks everything looks decisive and isn't. The estimates underneath don't carry that precision, people learn to move the weights, and the argument shifts from the decision to the arithmetic.

Where business impact comes from

Not every item needs a revenue forecast. Early ones can carry option value instead, as long as that's said out loud and the evidence that would make the option worth taking is written down.

Then, which one first

The unblocking axis does most of the work. Something that frees ten expert days a month is worth less than something that makes four other things possible. Ordering by value delivered builds a pile of good things that don't compound. Ordering by constraint removed builds a platform.

How much evidence to ask for

A discovery experiment shouldn't have to prove what a mature product proves. Asking for the whole case at the start kills work before it's had the chance to produce anything.

The decision card

One card per item, carried into the review and updated as evidence arrives. It's also the artefact the assessment step in 1.13 reads.

1.6Build it

Inside a single product the work runs in five phases. Each one has a question and an exit condition, and skipping one usually shows up later as a number nobody trusts or a workflow nobody can hand over.

Writing a feature

A brief describes outcomes and constraints. Technical solutions stay out of it, because writing them in takes away the decision the technical owner is accountable for. Four things get stated before build.

• The behaviour that changes, for whom, and where in their workflow.
• The acceptance criteria, written as results anyone can observe.
• The exception path: what happens when it can't complete, who hears about it, what gets recorded.
• The stop condition, and when the item is checked against it.

Four kinds of feature

Only two of them carry a price. Classifying at entry decides whether the item is expected to earn or to be budgeted as cost.

Enablers get traced, not priced. Charging for the piece that makes the sellable thing possible raises the price of the thing being sold and blocks the channel it was built for. The revenue it unlocks gets counted against it instead.

The balance across the four is a health check. Mostly protect means the business is holding position. Mostly create with no enable underneath means shipping things that can't be delivered at a sensible cost.

1.7Decide what stays human

This usually gets argued on whether the technology can do it. In a regulated science business that's the wrong test. If a wrong answer comes out quietly, automating it moves risk rather than cost, however good the method. The question worth asking is where automation increases the leverage of scarce expertise without giving up quality or safety.

The mode isn't fixed for the life of a capability. As the exception rate falls it moves down the list and margin improves without a price change. That gives the leverage band something concrete to aim at instead of a general instruction to automate. It also gives Science a way to say no that isn't about protecting territory, and Commercial a way to explain why one analysis costs more than another.

Classify the work before deciding what to do with it

Break each step of the delivery workflow into sub-tasks, then classify the behaviour each one demands. The classification picks the move; nobody has to argue about it.

Asking whether a whole capability can be automated usually gets the answer no, and the conversation stops. Split the task into four stages and the answer becomes specific.

Where expertise stays, and why

What a designed loop produces

A loop that's designed gives four things back: the exception record that sequences the next piece of automation, the evidence behind the claim, the audit trail the regulated setting needs, and the data that lets the mode move. A loop that exists as a fallback gives none of them, because nothing gets recorded in a usable form.

Splitting these roles is what lets work cross the expertise line. When one person holds all four, every case costs the most expensive role in the set.

1.8Automate, augment, amplify

Automation is the narrowest of the three, and the one most platform strategies start and stop at. The other two change different things and get measured differently, which is what makes this a progression rather than three similar words.

On the blueprint these are directions of travel: down across the automation line, up across the expertise line, up across the visibility line. A roadmap becomes work crossing a line rather than a list of features.

The obvious fourth step is autonomy. It's left out. In a regulated imaging business it contradicts everything worth saying about failure detectability and audit sampling, and it tells the science team their expertise is on a countdown.

Different moves, different measures

Each move needs its own measures. Judging an augmentation feature on cost per scan makes it look like a failure. Judging automation on user satisfaction makes it look like a success when it isn't.

Depth inside automation

Sequencing follows how often something fails, not how interesting it is to build. The layer that removes the most frequent failure pays back faster and also produces the data the next layer needs.

1.9Evaluate it

Moving a capability up the index

Earning the next investment

A thesis doesn't have to prove the whole business before getting capacity. It has to show why the next unit of capacity is rational.

The scorecard

1.10Turn it into revenue

A feature isn't a revenue stream. Two things sit between them, and both get skipped: the operational change the feature causes, and the economic change that follows from it. Naming them is what makes the claim checkable.

The longer form of the same chain gets used when an item is being written up rather than checked: problem, who has it, what changes if it's solved, which capability creates that, how the capability is delivered, how it's charged for, what it costs to serve, and what measurable result says it worked.

Unbundle before inventing

A study gets delivered as one item and invoiced as one item, but it contains several services with different buyers, different cost structures and different ceilings: site access and qualification, capture and harmonisation, computation, expert interpretation, evidence assembly, comparison against a wider population, and delivery into someone else's workflow. Pricing them separately, internally at first, shows which layer carries the margin and which is subsidising the rest. Most new revenue in an analytics business comes from selling one layer to a buyer who'd never buy the whole thing.

Making an offer out of a capability

Contract path and seller are the two that get forgotten, and both are product decisions even though neither is software. They belong on the roadmap next to the build.

How much of the work the customer does

Matching the model to the customer

The point isn't to push everyone to self-service. It's to stop expensive expert delivery being applied to every customer regardless of what they're worth.

Selling what the work leaves behind

Data doesn't become revenue in one step. Each level needs the one below it, and the bottom two earn nothing directly.

Rights position gets stated before any of this is proposed, because it's the first question anyone asks. Operational and process metadata usually sits in a different position from patient-level data, and that difference decides which candidates are product work and which are legal projects. The cheap move is a contract template that seeks aggregate-use rights in exchange for giving the customer access to the resulting comparison. It costs nothing today and it compounds with every study signed afterwards.

Testing a stream before pricing it

1. Does the buyer have a budget line for this kind of thing today.
2. What's the unit, and does it grow with their activity or with selling effort.
3. What does one more unit cost to serve, including the expert exception path.
4. Does it displace revenue that would have been earned anyway, and in what proportion.
5. What has to be true before an invoice can go out: capability maturity, a price, a contract route, and someone whose job it is to sell it.

The fourth is the one people skip. Where a channel reaches segments not sold to directly, the volume is new. Where the segments overlap, a written channel rule is easier to enforce than a price floor and settles the question before the first conflict rather than after it.

1.11Build the product unit

The function starts as one role, supported by people who already have day jobs. A director who tries to be the product manager for everything becomes the bottleneck the role exists to remove, so what the function refuses matters as much as what it owns.

Cells, not squads

A squad model needs a product manager per squad. Instead, a small cell forms around a live thesis, made of people already here, and ends when the question is answered. Nobody leaves their day job for it.

In a specialist business the real fight is rarely about priorities. It's about whose expertise counts as authoritative. Naming four owners and giving two of them a hard stop settles that up front, and it costs the product function very little in practice.

Components, not squads

A squad model needs a product manager per squad. The alternative is a component model with stewardship spread across people who already work here.

Build, buy, partner or decline

The decline column is the most useful one. A lean organisation has to be able to state what it isn't doing, so people stop asking.

1.12Scientific product leads

The aim isn't to turn scientists into junior product managers. It's to make them better at turning a scientific insight into a product decision, while Product absorbs the commercial and delivery mechanics. That distinction is what makes the path acceptable to the people asked to walk it.

Making the time real

This falls over when the time is notional. One of four mechanisms gets chosen for each person, explicitly, rather than assumed.

Learning it by doing it

Sessions on validity, architecture and regulatory claim are led by those functions rather than by Product. Two run the other way, with scientists teaching Product and Commercial the underlying science. That buys more credibility than anything Product could deliver on its own. Everything worked on is live; there are no case studies.

1.13The product agent system

Every framework here has stated inputs, criteria and output. That's what makes an assessment come out the same whoever runs it, and it's also what lets part of it be prepared automatically. What follows is a check that runs before meetings that already exist. Not a decision engine, and not a new platform.

Whoever is about to submit something runs it first. They get a verdict and a list of what's missing, and they fix what they can before anyone else's time is spent. Then the same assessment travels with the item into the review, so everyone reads the same page.

The value is in what never reaches the meeting. A lot of what gets deferred today is deferred for a missing number the person who raised it could have found in twenty minutes, if anyone had told them it was needed.

What each check applies

Where the checks sit in the workflow

What each one reads and hands over

Specifying one

Build order follows the records. A check that reads a decision log, a version register and a contract summary becomes possible as soon as those exist in a consistent shape, which makes the record-keeping in the first ninety days the thing that unlocks this layer rather than a separate project. The release check is the one with real money behind it, because a method change inside a running study affects comparability across the whole study rather than one result.

Part 2 — Governance

Part 1 covers how something becomes a product. This part covers who decides, on what evidence, and where the capacity comes from. The aim is to take decisions off the calendar rather than add meetings to it.

2.1Five demands, one pool, three bands

Two roadmaps already exist: a platform roadmap owned by Technology and driven by operational requests and near-term client work, and a science roadmap owned by Science and split between long-term clinical strategy and near-term client needs. The growth agenda doesn't add a third stream. It adds three — partner integration, automation and standardisation, and the regulatory path — each with its own clock, buyer and way of failing.

Merging the two roadmaps would remove what makes each of them work: scientific judgement, architectural coherence, contractual awareness. What unifies is the decision framework and the capacity view. Ownership stays where it is.

What each function brings and holds

Decision rights

One accountable owner per decision. Hard stops sit with whoever carries the professional risk, and get used at gate entry rather than at launch review. Consensus does one of two things in a specialist business: the loudest function gets an informal veto anyway, or a generalist ends up ruling on questions they aren't qualified to rule on.

2.2Two lanes, four forums, one log

Gates protect against expensive mistakes. They also make small experiments impossible, because nobody convenes a committee to spend three days finding something out. So there are two lanes with different rules, and most of the volume goes through the fast one.

The weekly one matters most for what it doesn't do. Delivery meetings are where roadmaps quietly get rewritten by whoever is under the most pressure that week.

One artefact

Each entry in the decision log records the decision, the date, the owner, the band, the evidence relied on, the capacity committed, what would change the decision, and when it gets looked at again. The last two are the ones that matter. They make reversing a decision cheap and unembarrassing, which is what placing bets in a moving market requires. A decision reversed on new evidence is the system working. A decision reopened with no new evidence means the decision rights aren't real.

2.3Gated evaluation

Ideas earn capacity as they earn evidence. Promotion is joint between Product and Science; validity stays a single function's call. The decision at every gate is one of four words.

2.4Making the split real

In a lean organisation, scarce scientific and engineering capacity behaves like capital. Governance should show not just what the company wants to build but what capacity each intention consumes.

• The opening split gets set against measured capacity, not proposed in advance. Working out what's actually consumed today, in expert weeks and engineering weeks, is a first-month job. A split offered before that is a guess presented as a decision.
• Expert weeks and engineering weeks get counted separately. Something can be cheap in engineering and impossible in science.
• Urgent work draws from GROW first, then LEVERAGE, never from RUN. Every draw is written down: what it cost, and when it's repaid.
• The split gets published. A published split makes a deliberate underspend defensible when people expect activity fast.
• Actual against planned gets reported at the quarterly gate. A split nobody measures is a statement of intent.
• A fourth band exists for non-linear work, funded with cash rather than capacity. Its rules are in the appendix, and it never draws from these three.

2.5Product-to-revenue assessment

The trace from 1.10 shows up in governance as two extra columns on the portfolio view — the value unit and the stream — and one question at the gate: which stream does this touch, and can the walk down to named features be made. If neither direction survives, the item goes back rather than in.

2.6Benchmarks and traction

Benchmark against ourselves first. Generic software benchmarks describe a business with a different cost structure, a different buyer and no validation obligation, and importing them produces targets nobody can act on. The first quarter sets a baseline. Direction of travel comes after that.

The one number

Configuration share of new-study setup — how much of a new study can be stood up without engineering. If it's rising, licensing gets cheaper to deliver, onboarding speeds up, margin improves structurally, and the regulatory conversation gets less expensive because the validated surface is smaller. If it's flat, features are shipping and the platform position isn't moving.

Baselines to establish

The formulas

Two families

Reporting only the first family is how a company finds out too late that its process was theatre. Decisions reopened with no new evidence is the one to watch hardest — it points at a relationship to repair rather than a forum to redesign.

Part 3 — The first ninety days

All of it has to go in alongside live delivery. Seven streams run at once rather than three phases in a row, because they depend on each other: records before agents, a measured denominator before any split, cost to serve before any price. Contracted delivery is where care is needed, and nothing in it moves in the first month. Most of what the growth agenda needs isn't in flight at all, which is where the work goes first.

3.1Seven streams, three phases

3.2What depends on what

3.3Committed outputs at day ninety

• A blueprint of the delivery lifecycle everyone has agreed to.
• One portfolio view of everything in flight, with capacity consumed and band assigned.
• A published capacity split, agreed at the first gate, with actual against planned.
• A decision log with two months of real entries, including at least one thing stopped or put back to bespoke with the reasoning written down.
• A cost-to-serve baseline, published with its assumptions visible.
• The repeatability position and service mode recorded for every significant capability.
• A component map with named stewards, and named scientific product leads with protected time visible in the split.
• A two-quarter roadmap across platform, partner and regulatory work, written as moves between stages.
• One approved, quotable fixed-scope offer that didn't exist before, with a contract path and a named seller.
• A completed trace across the portfolio, with untraced items and untraced streams named.
• The first assessment checks running, and the rest specified.
• The one capability gap that genuinely needs hiring or interim support, if there is one.

The commitment that goes with it: nothing in flight moves in month one. Governance that arrives by breaking delivery doesn't survive contact with a live study, and it spends the trust needed for the quarter after.

3.4Anticipated resistance

3.5The model in one page

Appendix

A.1Non-linear development

The plan is linear and should be judged that way. This exists because unplanned products usually turn up inside companies that then talk themselves out of them, and because the mechanisms that make the linear plan accountable are the same ones that would kill an exploration before it produced anything.

That last row matters more than it looks. The instinct is to put the best scientist on the interesting problem, and it's the fastest way to damage the business funding it.

A.2Finding the idea

Two mechanisms: one that generates candidates on purpose, and one that catches them when they arrive on their own.

Describe the capability more abstractly

Most descriptions sit at the level of what gets sold, which only ever surfaces adjacent markets. Climbing a couple of rungs surfaces problems that look unrelated. Run it over a few capabilities, with Science and Commercial in the room, a couple of times a year.

Catch the ones that arrive on their own

• Someone outside the current market asks whether this can be done for them.
• A customer uses an output for something it wasn't designed for.
• Work regarded internally as trivial gets paid for, or thanked for, disproportionately.
• A by-product turns out to be wanted on its own.

They go in one shared log: what happened, who saw it, what they wanted, and what was said back. Nothing else. What gets looked for at review is the same thing arriving three times from unrelated directions. Three is a pattern. One is a good story. The log costs nothing and survives staff turnover, which a memory of a conversation doesn't.

A.3Six questions that produce candidates in this business

The abstraction ladder and the anomaly log are general mechanisms. They work better with a set of questions written for this specific position. Non-linear candidates here rarely come from the capability. They come from the position — sitting between sponsors, sites, scanner estates, readers, platforms, consortia and regulators, and seeing things none of those parties can see alone. So the useful question is not what else the technology could do. It is what can only be seen from here.

A.4Validating it

The gates in Part 2 assume the thing being made is known. The right ladder here is the one Science already uses for a finding, applied to a commercial question. It carries a standard people already respect, so the argument is about evidence rather than about who's more excited.

Stages one to three should cost days. Stage four costs weeks. Stage five is the first time anybody builds anything. Four of the five end with a written reason to stop, which is the only way a bet gets killed without it feeling like a defeat.

A.5Governing it: the fourth band

Exploration sits outside the three bands, with different rules. Roadmap discipline applied to an exploration kills it, because it asks for evidence of delivery that an exploration doesn't produce for a long time. Exploration language applied to the roadmap makes delivery unaccountable.

There's no hold. On the roadmap, holding something is sensible — the work is understood, it just isn't the priority. On an exploration, holding is how a bet becomes permanent: it stops producing evidence but keeps its claim on attention, and two years later nobody remembers why it's still open.

One rule holds the boundary: an exploration never draws capacity from the roadmap. If it needs people, it needs a decision, not a favour.

A.6What a shaping session sounds like

A.7Signals that the model is working