For a non-technical Startup founder creating a scope can be intimidating but don't worry this guide should help you. If you need help creating a scope then we have a couple of options:

- Use our free scoping tool - accessible via our Startup Lab - Join here

- Use one our Product Managers to create your scope for you

MVP Scope

A good MVP scope should having the following parts:

1. User Persona's

2. User Journeys

3. Wire Frames

4. Database Architecture

A scope with these components can be used by any developer to estimate the time to deliver a project and therefore its price. It's also a great preparatory tool for you to manage your own projects. By completing a scope you can avoid re-work and therefore frustration and wasted time later. It also creates a better end product for your users without compromises being made for a bad initial design.

The scope of an MVP should be tight. It should be focussed on proving the assumptions that you need to test. THIS IS NOT YOUR END PRODUCT (although, in time, it might become your end product). You should be building something that has enough features and functions for a potential customer to be able to test your core value proposition and give you feedback about what else it should include. It should be quick to build and iterative: Get a few customers onboard and providing feedback, iterate, then get some more customers, iterate, repeat.

So why focus on a minimal feature set? This is because of the principle of "Build, Measure, Learn" (Lean Startup). As Eric Ries is so keen to point out: There is nothing more heartbreaking than launching a product after six months of build only to find that nobody wants it. We want to be guided by customer feedback from the earliest opportunity. So build the absolute core functions of your value proposition first, test them and then iterate adding more features from there.

A thing we hear a lot is "I am the customer. I would buy this product and I know what it should do, so that's what I am going to build". Unfortunately you don't know what the customer wants, you know what you want, you alone do not make a viable business, you need feedback from 10's or 100's of customers. This is why we build an MVP to get real data from real customers. Designing an MVP scope requires constant compromise and asking does that really need to be in the MVP.

Let's take a worked example to illustrate:

Widgets Inc

The business is a two sided marketplace. There is a seller who owns widgets for rent and a buyer who wants to rent a widget. The platform brings all the widget sellers together in one place solving the discovery problem for buyers, it also allows the buyer to filter and search for specific Widgets in specific locations that are available between certain dates i.e. Type X Widget within 100 miles of London. Sellers can provide availability & price of each of their widgets via a seller admin portal.

Monetisation

The buyer can transact via the platform and sign a lease agreement. The platform takes 20% commission on each widget lease.

Scope Limiting

Above is a typical marketplace app similar to Airbnb. It's easy to think that the founders of Widget Inc need to build the full journey on both sides of the marketplace for the MVP to be effective, but they don't! In this case the Widget Inc customer is the buyer because the platform only makes money when a buyer buys (generating commission). So Widget Inc could build only the buyer journey as an MVP and manually load data in on the seller side. In this example they would find some sellers and get the information from them via email which is added manually into to the MVP. When buyers buy, Widget Inc could manually deal with the transaction via phone & email. That way they would be able to test their value proposition for buyers much quicker and at less cost. If that test is successful they could then build out the seller side of the market to test if they can onboard sellers as version 2 of the MVP.

User Persona's

Identify the personas or user types for your app. Who is the customer (the one paying) and what other personas do we have. This then allows us to build a user journey through the app for each of these personas.