Published August 16, 2018 | Updated August 17, 2024 | 16 minute read
Teams inside of organizations are often tasked with “working more agile” or leaning into new ways of working. They are tasked with designing new products and services for their businesses. They’ve read the theory and understand the concepts, but putting theory into action can often be a challenge. I want to make it easy for you to understand and get started on getting your ideas in front of customers as soon as possible.
If you missed my last two articles in this series, check out how to get your idea in front of stakeholders and how to do simple user tests to validate your hypotheses. Assuming that your idea has support and you have validated the problem, it’s time to get to designing your solution.
This article will help you understand how easy it can be to prototype and define your Minimal Viable Product (MVP).
Prototype
A prototype is a simple design or sketch of an assumed end product that allows us to quickly validate our assumptions and generate new ideas with users. Typically prototypes are non-functional — they don’t actually do much, but they do allow a real user to get a clear visualization of what you intend to develop based on their needs. A prototype is not the “final version”, rather a quick, inexpensive technique to quickly adapt.
To start building prototypes, I’d suggest starting with a team exercise of simply sketching how your ideas will fulfill the user journey. I like using two exercises offered from Sprint Design Kit: Crazy 8s to quickly generate a lot of ideas and Storyboarding to narrow down what you will develop.
If you are working without much design experience, you can make quick prototype versions using PowerPoint, Keynote, or Google Slides. If you have access to someone skilled in design (or want to play around with prototype design tools) here is a list of software tools that can get you started on developing a more high-fidelity prototype.
No matter how you design your prototype, the objective is to understand, quickly, which features are most critical to solving the users core need so that you can define what will be built into the MVP.
Minimal Viable Product (MVP)
An MVP is a stand-alone functioning product, that addresses the user’s core problem, but lacks many functions and features of the indented complete product or service. An MVP is specifically intended to be tested in the market to learn how users will react before you heavily invest time and resouces into buildilng something that may prove to not be a market fit. Unlike a prototype, an MVP is meant to test a larger user pool and identify additional pain points within your product once it is introduced to the market.
When presenting the concept of MVPs to teams, I like to use this popular graphic (below) to describe the process. An MVP is a product that works, it wont not be the fully-baked solution from the start (the mustang), but it will get users from A to B (the skateboard); building the tire first won’t solve the user’s core problem. Using the continuous iteration steps — build, share, test + learn, iterate, you will eventually get to the end product. Here is a fun list of MVPs from popular companies that you have probably seen evolve over the years.
For teams looking to take a step-by-step approach, starting with a prototype can be a beneficial first step. The next step is to define the MVP. After gathering insights from users on your prototype versions, work with your team to identify what features will be the most valuable to solving the core problem and require little, time, effort, or resources to build. I’ve used this simple canvas to help teams define what should go into the MVP. The Y axis is categorizing features from easy to hard to build and the X axis is categorizing features from less to more valuable to the user. Using this matrix, identify what is easy to build and creates the most value. The features in the top right quadrant are the MVP.
Not all of your features will fit into the top-right quadrant, and thats ok. It doesn’t mean throw them away, it just means that if something is valuable, but hard to build, that it might be part of future iterations, but not the MVP.
If you are a team working under restricted time or funding and/or with strong development and design skills, jumping straight into developing an MVP might be the right approach for your team. Lean Startup enthusiasts would argue that buildilng the MVP as quickly as possible reduces time and wasted effort on prototypes. I have seen some teams go from idea to MVP in less than a month. It worked for them! My advice is: know your team. The overall objective is to get your ideas into the hands of real users as quickly as possible so that you are truly creating a product that works for your customers.
Proof of Concept (POC)
I added proof of concept here because it is often a question that comes up by teams. A proof of concept is a small, internal project to showcase your ideas that you intend to develop. A proof of concept, generally, isn’t usable. For big teams, or large organizations, a POC can be a great way to learn from others and gather insights from teams doing similar work or influence internal stakeholders as part of a pitch for an upcoming project.
For teams getting started on new innovation projects, I don’t recommend creating POCs. I find them to be time consuming and distracting to getting out and talking to real users. A prototype or MVP, in my opinion, are more useful and can also serve as a POC for internal stakeholder purposes.
First time developing a new product of service? Having fun prototyping and buidling MVPs? I’d love to hear from you. Connect with me at www.krysburnette.com
