When it comes to building an MVP (Minimum Viable Product), especially when it is your first time, it is extremely important to clearly identify the goals of what you are trying to achieve. It’s equally important to remember that the goal is to be “lean” and that all the bells and whistles aren’t required for this first product. This post will give you some concrete ideas and steps to get you started on working with us on an MVP.
First things first – What is an MVP?
MVP, or Minimum Viable Product, could also be considered a very basic prototype of an idea. An MVP is typically NOT something that is built to be sent out to the masses, but rather to a small batch of hand-picked, highly engaged users (e.g. friends and family). To build a successful MVP, think about the core offering or value for these users (which would be described in your executive summary or elevator pitch), and build to that. Keeping a laser focus on what that value to end-customers is will help you not build too much too early, wasting time and money – and will also help you either avoid “the pivot” or identity that a pivot is needed as soon as possible.
In my personal experience, when thinking through the process of building an MVP, you really need to re-wire your brain to start to think in a different way. Instead of thinking bottoms up, think top-down from a user perspective – start at a high level and then think down through each of the functional items of the MVP. A great technique we at B&B use is writing out specific use cases on how the end-user might actually interact with and use the product. This helps you avoid the common trap of getting too detail-oriented and not thinking about the big picture from the user experience perspective. By the time you’ve realized that you’ve gone too far down the technical specification path it’s usually too late – at this point you would already be down the development path and to turn back will be money burned. Typically we write 2-3 use cases for each new product we are working on. These are also a great tool to provide to our developers to make sure they have an understanding of the end result and the business reason of what we are trying to achieve.
Let’s look at our MVP example use case
I find a great way to do this is to create a mission statement or executive summary that defines exactly what the product is supposed to do. I have made up what an example of a use case that we will use as we walk through this process:
- Goal: A chat system that allows for communication between different departments of a company, or allows for communication between individuals within the same company and/or department.
With this we identify that the problem we are trying to solve is around making communication easier between individuals or groups of people based on some factor that ties them together (i.e the marketing team or executive team). From a high level this is pretty clear.
Next, we would think in terms of administration levels, and different roles and abilities of each of those levels would be. Here we could approach solutioning the problem in two ways.
- One way is the scenario where – if we were to lose sight of the fact that we are trying to build an MVP – we would come up with a laundry list of features that we would want to see that maybe aren’t entirely traced back to the use cases. The list gets very long very fast. And it will also be extremely expensive and complicated to implement. Read: high risk.
- The second, better way would be to throw out all these superfluous features and stay on task around what an MVP really is – focusing on solving the core problem as expeditiously as possible and that’s about it. We like to stick to the principle of KISS – Keep It Simple, Stupid.
Assuming we’re going with the second, recommended approach, now we have to define the user levels that would work for each associated user role:
- Super admin – The developer/team of developers who created the application and has the ability to control all other potential clients who have access to the platform. This could be considered the “internal company” level.
- Admin – This would be an external company who signed up for access to our application (our paying customer).
- User – A user who would be invited by the admin to join to access and use the application.
These are therefore our core user roles. Now we need to define the abilities or features that each of these roles would have – let’s apply the two approaches/lenses of the robust, full product versus the MVP:
Using the MVP Lens
- Ability to see and manage all active companies who have signed up and who are using the free trial (assuming we do a 30 day free trial for them to get a taste of how it works)
- Top level list of all the companies with some data showing how many active users/groups have been added under this company.
- Ability to deny/allow access of new clients (admins).
- To be able to message admins/users directly for any trouble shooting and or support
- Ability to invite new users via email to use the app under their company
- Ability to create new groups and assign users to these groups (which could be departments broken up)
- Ability to communicate with super admins/users/groups
- Tracked message logs
- Ability to communicate with admins/users/groups that they are assigned to
- Tracked message logs
Using the Robust, Full-Product Lens
Assume all of the items listed above with the addition of what is in this next section -
- Dashboard of analytics
- High level looking at average total engagements each day.
- Deep dive for each individual company that is signed up.
- User level analytics to what days they communicate more/what features they are using the most, chat, video, uploading documents.
- Ability to assign other sub admins who can create new groups and assist with management of a large organization.
- Dashboard of analytics.
- High level dashboard aggregating data of each of the groups they have created such as number of communications per day, average number of times a user communicates.
- Dashboard for each individual group.
- Ability to communicate in all groups they have created either my traditional instant messaging, video chat, uploading and sharing documents.
- Ability to communicate with users/admins in private messaging
- Ability to communicate via instant messaging, video chat, uploading of documents of groups they have been assigned to.
- etc. etc.
Now I list out every possible item that came to mind when building this type of application, but my goal was to show you a concrete example of what going outside the scope and intention of an MVP looks like. A lot of the features that are highlighted in the robust section are great features to have, but when speaking with, say, a new client for Baked & Branded, I would make the recommendation that we consider these items for Phases 2 & 3 (Beta, full productization, etc.). Remember that keeping the focus on the core offering is supposed to be the goal for the MVP.
Working with Baked & Branded to build your MVP
Question: How do I prepare a set of requirements to bring to Baked & Branded to help me build a technical statement of work to get a sense of cost & timeline?
Answer: We like to keep things simple. It is easier for us to understand your goals when you have already compiled and validated the following (consider this your homework):
Section 1: An executive summary, which would be a 2-3-paragraph example of what your product is going to do.
Section 2: Who is the target end user/customer? This is an important step for both of us to understand and for us to be requiring it will make sure that you have done your homework.
Section 3: Similarly to how I broke everything out via bullets (rather than written paragraphs), focus on that individual feature that you are looking to provide. This keeps things clear and concise.
Section 4: Who are your competitors (and you ALWAYS have competitors, sometime the status quo is your competitor)? How do you plan to differentiate yourself from each of these and what do you think they do well/do poorly?
Question: Now that I have all this information together and organized, what is the next steps to get me to creating!?
Answer: With this information, it’s a great starting point for us to have a deeper conversation with you. We will set up a call to go over you business goals, ask some more in-depth questions, and also spark some ideas and provide some feedback from a different perspective on what you are trying to build.
Once all the answers are clear, then we can come in and perform our B&B magic – that is, build out a technical statement of work that will be our guideline to follow when we would start the project. This also is a validation step to you so that you can see that we clearly understood the goals of your product.
Have a question or need clarity on anything? Use the comments below and I will be sure to respond, or you can email me directly at Eric@bakedandbranded.com.
Interested in leveraging our expertise? Reach out via the contact form or you can email me directly.