Strategy
Part of A productivity software strategy that measures the current route before proposing a better one
Six parts of a strategy framework that expose weak productivity software assumptions
Use a six-part strategy framework to test a productivity software proposition, expose weak assumptions and make an evidence-based next decision.
A business productivity software strategy framework should force a team to make choices before it funds features. The six-part method below fits on one page. Complete it for one workflow and one initial customer group, then attach evidence rather than persuasive adjectives.
This is a planning method, not a finding about demand. It has not been tested with customers for this article.
What to take away
- A one-page framework forces choices before funding features, using evidence rather than persuasive adjectives.
- Baselines should be written as ranges when cases vary, with evidence sources labelled separately.
- Official population data can bound a segment but cannot identify interested buyers.
- Rank assumptions by consequence if false and current evidence strength, starting with weak ones.
- A decision gate needs an auditable condition, a named decider and a date.
1. Define the work boundary
Write the event that starts the work and the observable result that ends it. Name the operator, approver, records used, hand-offs and exceptions. Add an explicit exclusion, such as multi-site approvals or offline use, if it would make the first proposition materially different.
Work boundary map
- Start event
- Operator and approver
- Records used
- Hand-offs and exceptions
- Observable end result
- Explicit exclusion
The Government Digital Service says a discovery should investigate the problem, users, context and constraints rather than validate a solution chosen in advance. Although that guidance governs public-service delivery, its distinction prevents a commercial plan from becoming a disguised feature request.
2. State the present burden
Collect recent completed cases. For each one, record elapsed time, staff effort, duplicate entry, correction, waiting and unresolved work. Label the evidence source: system record, document, observation or someone's recollection. Do not combine those categories as if they carry equal weight.
Baseline evidence fields
- Elapsed time
- Staff effort
- Duplicate entry
- Correction
- Waiting
- Unresolved work
- Evidence source label
Write the baseline as a range if cases vary. A weak record is still informative when its limitations are visible. It tells the team what instrumentation or observation is needed before making a benefit claim.
3. Choose the first organisation and role
Describe operational characteristics rather than a fictional personality. Useful fields include sector constraints, number of premises, workflow frequency, existing systems, buying authority, implementation support and access requirements.
The Office for National Statistics publishes registered business activity tables by geography, industry and employment band. They can bound an English segment, but they exclude some unregistered activity and do not identify interested buyers. Keep official population data separate from evidence gathered about the chosen workflow.
4. Select an offer and route
Write one sentence describing the core outcome, then list the included delivery work. Configuration, migration, training and ongoing administration can determine whether the offer behaves like self-service software or a managed service.
Choose a primary route to customers for the next learning period. Record why it fits the decision-maker, what proof that person needs, who performs onboarding and what channel cost must be measured. Other routes stay as alternatives, not simultaneous commitments.
5. Rank assumptions by exposure
Give every assumption two ratings: consequence if false and current evidence strength. Start with high-consequence, weakly evidenced items. Examples are access to required data, buyer authority, implementation capacity or acceptable security controls.
GDS recommends that an alpha tests the riskiest assumptions with prototypes and considers legal, contractual and legacy restrictions. Apply the principle, not an assumed government timetable. A commercial test might be a workflow walkthrough, a sample import or a support rehearsal, depending on the uncertainty.
6. Write the decision gate
For the next commitment, specify the evidence required, the person deciding and the date. Include conditions for continuing, narrowing, changing direction and stopping. Avoid a gate such as good feedback. Prefer an auditable condition, such as whether authorised participants can complete the defined prototype task and explain where its record would fit their current controls.
Add legal, privacy, accessibility, security and financial reviewers where the decision crosses their competence. The UK's voluntary Software Security Code of Practice provides questions about product ownership, maintenance and customer communication, but it is neither certification nor a complete assessment.
Review all six boxes together. If the audience changes, revisit the burden, offer, route and risks. The framework is doing its job when it makes a hard choice visible, not when every box remains green.
Before you act
- Define the work boundary with start event and observable end result.
- Record elapsed time, effort, duplicate entry and corrections for recent cases.
- Describe the first organisation by operational characteristics, not fictional personality.
- Choose one primary route for the next learning period.
- Rank assumptions by consequence and evidence strength.
- Write an auditable decision gate with decider and date.
Common questions
What should a team write down to define the work boundary?
Write the event that starts the work and the observable result that ends it. Name the operator, approver, records used, hand-offs and exceptions. Add an explicit exclusion, such as multi-site approvals or offline use, if it would make the first proposition materially different.
How should a team handle weak or incomplete baseline records?
A weak record is still informative when its limitations are visible. Write the baseline as a range if cases vary, and label the evidence source as system record, document, observation or recollection. Do not combine those categories as if they carry equal weight.
What makes a decision gate useful rather than vague?
Specify the evidence required, the person deciding and the date. Include conditions for continuing, narrowing, changing direction and stopping. Avoid a gate such as good feedback, and prefer an auditable condition, such as whether authorised participants can complete the defined prototype task and explain where its record would fit their current controls.
