Rapidscoper

7 practical steps to building your startup MVP

Chris

August 18, 2019

Agile

393

Whiteboarding ideas and designs

Not sure where to start with building your app? Here is a top level outline of the process I’ve used and refined over more than a decade building software for the web. This process can be used for mobile apps or building any online platform.

This is a guide to the process of building software, not building a startup. If that’s you and you’re just getting started, I strongly recommend learning about the lean canvas that helps guide startups through the process of getting their business off the ground.

You can follow this process on your own if you’re building an internal development team. Alternatively, if you are outsourcing the project to an external agency, this should give you an overview of the process to expect. An external agency may go through this process with you from beginning to end, or perhaps come in part way through.

1. Write user stories

The first step in building your software is documenting what it needs to achieve for users. At this point you will have had many hours of discussions with customers and gained a clear understanding of the pain points you are trying to solve.

Non-technical people have a tendency to write a large list of “features” for their new product and then want to hand it off to a developer to build. Unfortunately writing software is time consuming and expensive, so that isn’t going to cut it if you are serious about saving time and money with an efficient development process.

User stories should be structured in the following way:

As a [User Type] I can [do something] so that [I can achieve something]

This allows you to define different functionality for different types of users whilst focusing on what the user wants to achieve.

For example, instead of writing this feature:

Find flower arrangements by category

You would write:

As a [Visitor] I can [find flowers for my girlfriend] so that [she knows I care]

As a [Wedding planner] I can [browse flower arrangements for weddings] so that [I can find the best arrangements for my clients]

This emphasis on who is doing what, and why, is essential information that will help your designer create a user interface tailored to the specific use cases of your end users.

There’s a lot more to writing effective user stories, but that’s worthy of its own post in the future.

2. Prioritise stories

At this point you should have a long list of user stories describing all the functionality of your application. You now need to think carefully about what functionality is essential from the beginning and what can be left for later. This is commonly referred to as defining the Minimum Viable Product (MVP) — what are the bare minimum user stories required for my product to be viable for its first users?

I’m a big fan of the MoSCoW method of prioritisation. Go through every user story and label it as one of:

  1. [M]ust have
  2. [S]hould have
  3. [C]ould have
  4. [W]on’t have

Any user stories defined as “Must have” will become your MVP.

Depending on the complexity of the project, it’s possible some of your “Must have” user stories will be difficult to implement. This is where it’s very useful to have access to a technical adviser who can do a review and flag any obvious issues.

If there are issues and the functionality is critical to how the product works, it may be necessary to conduct technical research or invest in building a small proof-of-concept to de-risk any technical issues.

3. Mockup designs

The next step involves creating visual mockups of what the application will look like. These will be shown to prospective end users to gain feedback in the next step. They will also become the blueprint for the frontend developer(s) building your application.

This process typically involves creating low fidelity mockups and then upgrading them to high fidelity mockups.

Low fidelity designs are “boxy” black and white designs that demonstrate the key functionality and workflow of the application. You can work closely with a User Experience (UX) designer to quickly try different ideas and ensure there is a logical flow to the application.

High fidelity mockups are a pixel perfect representation of the application. A User Interface (UI) designer will take the low fidelity designs, combined with an understanding of the user stories, and create high resolution designs of every screen, page, button, image required for the application.

You can mockup just the MVP (Must have) user stories or all of them. There are many things to consider in that decision (budget, timing, confidence etc.). If you are unsure which category some of the priorities should be in, it can be helpful to include those in the mock ups. You can then show potential end users to get their feedback and further refine your user stories and priorities.

It is possible to skip the low fidelity designs if you have a small project with a simple workflow and jump straight to high fidelity mockups. It willdepend on the project and experience level of your team.

There are many excellent design tools such as Figma, Sketch and Invision. I strongly recommend using these tools as they provide useful information to developers implementing the designs, helping save significant time and money across the life of the project.

4. Feedback loop

Gathering feedback from potential end users and feeding it back into your product is a critical part of the process of building your app. How well you understand your end user’s needs and translate them into your product will make or break it. This is a key role of a Product Manager.

While feedback is mentioned here as a separate step, it really should be occurring throughout the whole process.

Meet with potential end users and show them the low fidelity mockup. You must ensure the end user understands the workflow of the app and the key MVP features identified are clearly understood.

This is a critical time to learn more about your product and it’s end users. Does the user become really engaged / excited seeing the product starting to take shape, or are they ambivalent? Do they start suggesting new features that would make it even better, or are they just going through the motions?

It’s important to note down all the feedback, analyse it and then review the user stories and priorities. After seeing the screens it may become apparent that a new feature is essential to the MVP which needs to be added as a user story and prioritised. You may also discover a user story previously considered important, didn’t seem to register with people as much and it should be dropped from the MVP.

Next, complete the high fidelity designs incorporating any changes to the user stories for your MVP. Again, going through the process of showing these to potential end users enables you to further fine tune the functionality of the app.

All going well, users will be excited and asking when can they start using it!

5. Technical scoping

At this stage you have a comprehensive list of user stories for your MVP and high fidelity mockups of what the app should look like. Here is where most people make a mistake and think they have everything they need and start building the app.

Three more pieces of the puzzle are necessary; technical stories, implementation scoping of the existing user stories and a database schema. These are critical steps as they help define the technologies to be used in building the app and are an essential input into the next step — estimating the development time.

Technical stories (aka technical requirements) define key technical issues that must be considered for the project to be a success.

For example:

As a [System] I must support 500 active users

As a [Mobile app] I must support iOS

As a [Mobile app] I must support Android

As a [Web app] I must support responsive design

These will go a long way to shaping the technical architecture of your product and define the different devices you need to support — providing a much clearer picture of effort required to build your app.

Again, these technical stories should be prioritised. For example, you may say that Android support is a “Must have”, but iOS can come later so is a “Should have”.

Implementation scoping of user stories involves looking at each user story and working out the technical steps to implement it.

For example:

User story:

As a [ Visitor ] I can signup with my Facebook account so that I can have a streamlined signup process

Implementation stories:

Requires an [ Integration Library ] called [ Facebook connect ] that initiates the signup process with Facebook

Requires a [ Page ] called [ Facebook Auth ] that accepts the signup response from Facebook

Requires a [ Business Rule ] called [ Signup via Facebook ] that creates a new user in the system using Facebook email address and a temporary password

Requires a [ Business Rule ] called [ Sync Facebook data ] that loads Facebook profile picture, name and email into the new user

etc.

From my experience, implementation scoping of user stories is rarely done in a formal fashion on software projects. This is a significant cause of poor estimates. Unless you think through every step of implementation, you’re just guessing.

A database schema provides a map of how your application will store data. It is basically a list of tables / collections (User, Product, Order, Session, Cart) and fields (name, email, password, lastLoginTime). This is an important document to develop and maintain as it ensures all developers have the same understanding of how data is being managed across the application.

In many projects the database schema is organically established during the development phase. This can lead to poor final database performance, missing database indexes, confusing / inconsistent field names amongst a host of other problems.

6. Estimation

It’s now time to estimate the effort required to complete the development work for your MVP. In step two (prioritisation), you may have performed a rough estimation of effort for the user stories to help determine your MVP requirements. You now have a much better idea of what you’re building, with high fidelity designs and technical scoping completed.

How to estimate the effort required to build software has many schools of thought and in reality, there’s no correct answer — rather you need to find the best approach for your project. Story points and hours estimation are the two most common scenarios I have come across.

Story points estimation works best when you have an internal development team working in an agile manner. The development team goes through all the user stories and implementation stories placing a weighting against each as a measure of effort. These numbers are typically 2,4,8,16,32,64 — but be careful, they do not relate to hours, the numbers are a comparison of effort between each story.

Hours estimation is most commonly used when outsourcing development to a third party development company and you require a quote for the work. In this case, the development company hopefully has significant experience to provide an estimation that they can hit. It’s very common for an agency to include a buffer in the project build to allow for unexpected implementation issues.

If you are working with an agency, be aware that they need to do some level of technical scoping to provide an estimation and quote for the work. Unfortunately this process isn’t well understood so agencies find it difficult to charge for. As a result, this process tends to be rushed often resulting in incorrect estimates, pricing and timelines. This can damage trust between the agency and client or lead to failed projects.

7. Commence development

You’re now ready to start building!

If you have chosen to build an internal development team, you will be best suited to use an agile development approach. This is where you take all the stories and put them into a “backlog”. You then define a sprint length (in weeks) and size (in story points) as a structure for your developers. The aim is to successfully build all the stories in the sprint, fully tested and ready to use, by the end of the sprint. Again, this is just a very brief overview of agile development which has many variations and nuances.

Alternatively, if you have outsourced development and asked for a fixed quote, it’s more likely you have a waterfall development process for the development of your MVP. Here the agency will typically provide a time frame for the development with clear milestones,  payment schedules and periodic reviews.

You must think carefully about the best appropriate technology to use for your project. There are many different programming languages, system architectures and frameworks to choose from. Working through that decision is beyond the scope of this article, but I strongly suggest you find someone technical to assist making the best decision. It can be very expensive to rebuild your application once you realise you made a poor technology choice on day 1.

Final comments

Assuming all goes well and your MVP is successfully built, tested, released and has a growing user base — you will need to consider your development strategy moving forward.

If you outsourced the development, you have three choices:

  1. Build an in house development team to take over the project and continue developing
  2. Continue with your agency and scope out another “phase” of development with a known price and time frame
  3. Continue with your agency, but using an agile methodology, defining a fixed budget per month and start churning through the “backlog”

The process outlined here appears quite linear, but in reality you will jump around quite a bit and that’s okay. This is particularly true with getting feedback from potential end users. You should be doing that all the time and continually updating your user stories, priorities and designs based on that feedback.

It’s also important to recognise compromise is essential for any new product to be successfully developed. You will need to compromise on features to include in your MVP. You may compromise and build some functionality knowing you have to throw it away in the future, because it helps you get to the next stage.

The team and its ability to effectively communicate is also critical. A great team should always be challenging each other’s ideas and approaches, without it being personal. 

I’ll be expanding on many of these steps in future posts so feel free to reach out if you have any questions or comments.

Good luck with your project!

See also

Need help scoping your product?

Reach out for a free 1 hour, no obligation, discussion of your project requirements

Send message