Doing the absolute minimum in life is often frowned upon, but that’s exactly what we’re planning to do whilst developing SH24.

Once we have tested our early assumptions, we’re going to build and test SH24 as an entire, end-to-end service (not just the online part) by developing a series of minimal viable products (MVPs).

In essence, an MVP represents the absolutely essential features that a service needs to do its job, and no more - it’s the most lightweight skeleton version possible.

By building SH24 in MVPs we’ll avoid building services and features that people do not want or need. At the same time, it will enable us to learn what our users feel are key barriers and drivers to accessing and using the service. Only once we have learned enough about what users want (and why they want it), will we start adding new features and options to the service.

We’ll add these complexities to our prototypes in a low-fi way - continuously building, testing and learning different features in parallel. Our focus will be on learning from the feedback, and iterating.

We envisage a set of four MVPs, mapped over the next 4 years, which are all subject to change. Before progressing onto the next set of features and layering the MVP, we’ll have to pass through a project gateway. Essentially we’re looking to invest the minimal amount of effort to gain the maximum understanding about the value the service provides, and a formal gateway is a device to assess this. Each gateway will assess:

If we have we seen a shift in our metrics that demonstrate a success in achieving our outcomes with the test audience?
If we have we learnt enough from this MVP with regards to what’s valuable to users, commissioners and providers?
If we are we confident that we’re ready to scale the features beyond our initial test sample?