The first ninety days of a productivity software proposition, ending in a controlled pilot

A business productivity software ninety day plan should buy evidence before it buys scale. The schedule below is a sequence of decision gates for one English workflow and audience. It is not a promise that a safe, viable product can always reach pilot stage within three months. Legal, security, accessibility or technical findings may require a pause.

What to take away

Days 1 to 15: reconstruct the work

Name the decision owner and write the start and end of the workflow. Examine recent completed cases with permission. Separate elapsed time, staff effort, re-entry, correction and unresolved exceptions. Mark whether each observation came from a record, direct observation or recollection.

Identify operators, approvers, administrators, budget holders and people whose information the system would process. Write exclusions.

The GDS account of how discovery works focuses on users, context, constraints and the present cost of a problem. Its public-service process is not a timetable for a private product, but it offers a useful test: the team should explain the work without referring to its proposed interface.

Gate: continue only when there is a bounded problem, a traceable baseline and an identifiable decision-maker. Otherwise narrow the audience or collect better records.

Days 16 to 30: test the damaging assumptions

Create an assumption register covering data access, workflow frequency, buying authority, integration, implementation labour, support and willingness to change. Rate the consequence if each assumption is false and the strength of present evidence.

Use the lightest safe method that can challenge the highest-exposure assumption. That may be a paper workflow, clickable prototype, sample data import or support rehearsal. GDS alpha guidance recommends testing risky assumptions before production build and considering legal, contractual and legacy constraints. Do not interpret a participant completing a prototype as proof of purchase intent.

Start an information map showing data categories, sources, recipients, locations, retention and deletion. Ask qualified reviewers to assess the actual processing and claims. Do not wait until launch to discover that essential data cannot lawfully or safely be used.

Gate: choose continue, redesign or stop. Record contrary findings, not just demonstrations that went smoothly.

Days 31 to 60: prepare a controlled pilot

Define what the pilot will and will not do. Set eligibility, participant roles, support hours, fallback procedure, incident route and exit steps. Freeze the baseline calculation before observing the new process. Decide which evidence is operational, which is reported by participants and which is commercial.

For a hosted service, the NCSC explains that customers retain SaaS security responsibilities around matters including configuration, identity, data and incident response. Turn that shared-responsibility boundary into named tasks for the supplier and participating organisation. Test account removal and usable export, not only onboarding.

Choose one acquisition route for the pilot. Limit the number of organisations and the staff time available. If outreach uses personal contact details, secure data-protection and electronic-marketing review before sending it.

Gate: authorise a pilot only when the scope, evidence permissions, support ownership, fallback and stop conditions are documented.

Days 61 to 90: observe and decide

Run the pilot without changing the success definition after seeing the data. Log completion, failures, support work, exceptions and withdrawals. Preserve the denominator. A missing record is not a successful outcome, and a participant's positive comment is not a measured time saving.

Review the roadmap each week, but avoid expanding scope merely because a requested feature sounds useful. Government guidance on planning in agile delivery recommends detailed near-term plans and less certainty further away. Apply that principle to the evidence: write the next commitment precisely and keep later options conditional.

At day 90, compare the evidence with the original decision gates. Select continue, narrow, change or stop. If continuing, state the remaining uncertainty and the maximum next commitment. If stopping, preserve the decision record, exports and participant obligations. A disciplined stop is a valid result; an invented success story is not.

Before you act

Common questions

What should a team do in the first fifteen days?

Name the decision owner, write the start and end of the workflow, and examine recent completed cases with permission. Separate elapsed time, staff effort, re-entry, correction and unresolved exceptions. Continue only when there is a bounded problem, a traceable baseline and an identifiable decision-maker.

How should a team test its riskiest assumptions?

Create an assumption register covering data access, workflow frequency, buying authority, integration, implementation labour, support and willingness to change. Rate the consequence if each assumption is false and the strength of present evidence. Use the lightest safe method, such as a paper workflow or clickable prototype, to challenge the highest-exposure assumption.

What must be documented before a pilot is authorised?

The scope, evidence permissions, support ownership, fallback and stop conditions must all be documented. Define what the pilot will and will not do, set eligibility, participant roles, support hours, incident route and exit steps. Also freeze the baseline calculation before observing the new process.