Phase 2 - Developing a Minimum Viable Product

After a Discovery phase we develop a 'minimum viable product'. This needs to do just enough to be able to test our key hypotheses and/or to understand whether we can overcome key project risks, without doing so much that it's too expensive or takes too long to develop.
This phase is important because sometimes projects move the more complex parts to the end of a project - such as integration between systems or discovering whether users will adopt a new technology. Developing an MVP enables us to understand how to deliver a solution and whether it will work through real-life testing before we commit further resources to the solution.
In Hackney, we talk about building a Minimum Viable Product rather an Alpha phase to emphasise the importance of getting working code in users' hands quickly, and so we avoid making technical investments that we have to jettison before building a beta.
We can use this method even when we've decided to re-use or buy software rather than build it. Our 'MVP' might be a small number of internal users, or using the software for a small number of cases.

Team and skills

During this phase, it is particularly important to work with a team that can share the understanding of what users need and continue to support the project in the next phase of work.
You would normally expect to be working in a team of 3 and potentially a team as large as 8. Much larger than this and the team may be too big to be cohesive. The team will contain:

A project sponsor

A Product Owner

A delivery manager

A developer(potentially a front-end and back-end developer)

A service designer

A user researcher

A subject matter expert

You will also need to draw on the skills of:

a Technical Architect for advice on the hosting and infrastructure - including security

A data expert for advice on the data that will be stored and exchanged

Suppliers of existing solutions

Master Data Officers

Information Governance Officers

Governance

The Product Owner will make the day-to-day decisions in response to the insights gathered from users. The key moments for decision-making will be in the activities to estimate the size of the user stories, the prioritisation and the sprint planning workshops.
Beyond the sprint team, the Product Owner will need to explain these decisions to the project sponsor, head of service and possible the Cabinet Member - depending on the prominence of the work. Getting this input in the prototyping phase helps avoid later changes of direction in subsequent phases of work. We have developed a role description to help Heads of Service and Product Owners understand the commitment.
During this phase, you should be sharing weeknotes and holding a show & tell at least every fortnight. We have created a guide to holding a great show & tell.
At the end of the phase, the team will need to commission an assessment of the work against the Service Standard, consistent with previous phases. This should involve the infrastructure teams and applications management so that they are sighted on the scope of the project and prepared for any change requests when the project later delivers working solutions into the production environment.

You may also want to check back to some of your key outputs from the discovery phase. For example, it can be useful to check back to the personas and have a group discussion about whether the MVP would meet the needs of each of the people in the personas (which is why it's useful to give them a name and face, so the conversation isn't abstract).

Timing

This phase should take between 6 and 12 weeks, depending on the technical complexity of the service. A project involving simple web-based interfaces or off-the-shelf software should take nearer 6 whilst a 12 week phase enables the team to test the development of APIs.
The phase could be designed to tackle the biggest risks to the project first, which can then inform the overall length of the phase.