Alpha

Purpose

Alpha is used to test possible solutions and the riskiest assumptions. The goal is to learn which approach is most likely to work before building at scale.

When to Use This Phase

Use alpha when discovery has identified a valuable problem but there are still major uncertainties about the right solution, technical feasibility, user journey, data flow, operating model or assurance route.

Primary Decision

At the end of this phase, we should be able to answer:

Which solution option should move forward, and what evidence supports that decision?

Core Questions

• Which assumptions are most risky?

• Which options should we test?

• Can users complete the key journeys?

• Can the technical approach work?

• Can required data be accessed and shared safely?

• What security or assurance barriers exist?

• What should be built in beta?

• What should be stopped or discarded?

Key Activities

• prototype creation

• user testing

• technical spikes

• architecture options analysis

• integration proof of concept

• data feasibility testing

• service design iteration

• content design testing

• accessibility review

• security risk exploration

• operating model design

• beta backlog development

Expected Outputs

• tested prototypes

• user testing findings

• technical feasibility evidence

• architecture recommendation

• data feasibility assessment

• security considerations

• preferred option

• beta backlog

• beta roadmap

• updated risks

• commercial assumptions for beta

Entry Criteria

• discovery recommendation approved

• alpha objectives defined

• riskiest assumptions identified

• team roles agreed

• prototype tooling agreed

• security constraints understood

• commercial authority in place

Exit Criteria

• key assumptions tested

• preferred approach selected

• evidence supports the recommendation

• beta scope is understood

• major risks and constraints are recorded

• technical approach is credible

• customer decision is recorded

Evidence to Capture

• prototype links or screenshots

• research findings

• test results

• architecture decision records

• spike reports

• accessibility notes

• security notes

• beta backlog

• show and tell outputs

• alpha recommendation report

Commercial and Statement of Work Considerations

• make clear that prototype work is not production build unless agreed

• define which alpha outputs are deliverables

• update assumptions for beta pricing and scope

• identify any change from discovery expectations

• prepare acceptance criteria for beta deliverables

IP and Accelerator Considerations

• use accelerators to build prototypes quickly

• label prototype code appropriately

• avoid accidentally transferring reusable components

• record any reusable improvements created during alpha

• confirm third-party or open-source components before wider use

Security, Data and Assurance Considerations

• do not expose real sensitive data in prototypes unless approved

• review data flows early

• identify likely threat model areas

• confirm access control implications

• identify security evidence needed for beta and live

Common Risks

• prototype mistaken for production service

• testing too many options weakly

• not testing the riskiest assumptions

• user research gaps

• technical spike results not documented

• accessibility left too late

• beta scope based on opinion rather than evidence

Practical Checklist

• Confirm alpha questions

• Rank riskiest assumptions

• Plan prototypes and spikes

• Run user testing

• Run technical feasibility tests

• Review security and data implications

• Compare options

• Develop beta backlog and roadmap

• Run alpha playback

• Record proceed, stop or reshape decision