In the second installment of our MVP series, we’re going to explore the planning & development of an minimum viable product.
Previously, we looked at What to Do Before Developing an MVP – which was all about the preliminary research that helps entrepreneurs and businesses determine whether their idea is a good one. Once you’ve confirmed your product idea is viable (through both market research and competitor research) and figured out how you’re going to finance the MVP, then it’s time to sit down and figure out exactly how you’re going to manifest this vision.
Planning an MVP and the actual development go hand-in-hand. If you put the legwork in during the planning stage, development is much easier; you simply follow the plan.
In this article we’re going to explore what it takes to get your product over the finish line, including:
A tech stack, or technology stack, is made up of all the services you use to build a web or mobile application. If you are building a digital product, then your team will need to determine what programming, frameworks, scripting, and markup languages will serve as the foundation for what you build.
There are two “sides” of a tech stack: server-side stack and client-side stack.
The server-side stack refers to the “back-end” parts of an app that the user won’t encounter directly. This includes items like:
The client-side is what the client sees; i.e., the front-end elements. Examples include:
The more ambitious the product, the bigger tech stack you’ll need. When creating an MVP, you can probably get away with the tried-and-true Python-Django or Node.js-React -- but that will, of course, depend on your product and your developers.
The people using the tech stack should have the biggest say in it. You want your developers to be comfortable with the technologies they’re working in. That being said, it can sometimes be a balancing act. On one hand, you don’t want your devs wasting time trying to learn a new tech stack. On the other, you don’t want to opt for any tech stack that’s outdated and therefore inefficient. Especially if you’re working with older developers, seek a compromise.
The final consideration when defining your tech stack is scalability. If your product takes off, will the tech stack be able to grow with it – horizontally and vertically?
Horizontal growth means expanding to include a growing number of users as well as various devices. Vertical refers to the ability to add new features (this is especially important for an MVP, because each iteration will involve new or evolved features).
You’ll likely have a long list of ideas and possibilities for the MVP. Some of these can be stuck on a “wish list” of items that would be nice to have.
These are low-priority items. The rest should be prioritized with numbers.
In addition to numbering, be sure to include a reason why a particular feature has received its respective ranking.
Feel like a kid in a candy shop? Here are three methods to help with prioritizing features.
With Kano, features fall into one of three categories:
Then, create a focus group and ask them the following two questions about each feature:
The members of the group then respond with:
From their responses, categorize each of the features into one of the three categories. Prioritize them in order of “Must Haves,” “Performance Needs,” and “Attractive Needs.”
RICE Method. Established by Sean McBride of Intercom, the RICE method is yet another way of prioritizing your MVP features. He boils it down to four criteria to measure each feature against:
There are myriad methods out there when it comes to feature prioritization. Whatever you use, build your ideas all the way out but realize that you may have to “trim the fat.”
Ideally, this happens as you’re prioritizing features, but if you get to the end of the last step and find that the project is looking too big then you’ll need to determine what is mission critical vs. what can wait for the product roadmap.
Once you’ve decided exactly which features matter the most, it’s time to take a walk in the shoes of your customer. A long walk. At this stage, we recommend implementing both user action mapping and a “pain-and-gain” grid.
User action mapping entails mapping out every conceivable action a user could take. So, if you’re building a digital product like an app, you want to take a look at all the buttons and avenues a user could take.
As you have it currently planned, is everything accounted for and operating as intended (i.e., serving the user in the way that it needs to)?
And the follow-up question: Which avenues or features create the most friction? You can map this using a “pain-and-gain” grid.
To do this, divide a box into four quadrants.
The top row correlates to your current situation. The bottom row correlates to your potential future situation. It’s a bit like a pros and cons list, with a little more nuance.
Every user action has a corresponding pain and gain. Take each possible action and explore it using the grid. What pain (effort on the user end) is required for them to make progress toward solving a problem (i.e., the gain)?
Take the sign-up process, for example. Perhaps you’re trying to decide whether to keep your sign-up fields minimal (name and email address) or have fields for additional user information.
Between the first and second installments of this series, we’ve talked about:
That leaves us with when. What we need now is a timeline.
When it comes to building an MVP, sprints are considered a best practice. Building an MVP is definitely a marathon...but it’s run in legs. In stretches at a time. In sprints.
This mode of working comes out of agile methodology, which was created by an innovative group of software developers who were fed up with the slow-moving, traditional waterfall method.
They sought to replace something that was complex and documentation-focused with a system that is quicker and more effective. Since its inception, agile has become tech and software’s preferred method for development. For a deeper dive into agile methodology, check out this article.
Today we’re just going to be looking at the heart of agile methodology: Sprints.
Before agile, development was typically kicked off with an eighteen-month project plan. One of the issues with this was that companies would follow the plan, only to cross the finish line and realize things weren’t working as intended.
Sprints help teams avoid this pitfall. By working in short-term bursts, teams can evaluate their progress iteratively and make adjustments as they go.
This means:
Have a deadline in mind for the entire project, and then start hosting sprint planning meetings. It’s a good idea to limit the planning meetings to 2 hours per sprint. These team events involve coming together to ask:
At a minimum, this discussion needs to take place between the product owner and the development team, but you may opt to include a greater range of roles depending on your organization’s structure.
Since you already took the time to hash out priorities and dependencies (re: feature prioritization), your product owner will have a very clear idea of what needs to get done with each sprint. And if you hired well, the development team will know how to get it done. The team then builds out a plan for the sprint, including:
These planning meetings may end up being a bit of a back-and-forth between the product owner and the dev team, because planning an effective sprint is about nailing a balance of value and capacity.
The team should also have daily check-ins to see how the work is progressing. This includes:
Doing this keeps everyone on track and helps surface any challenges that stand in the way of executing in the plan.
This stage is thrilling. It’s all about “delivering working software frequently” so it feels more productive than waiting 18 months for a working product.
Post-sprint cycle, gather the team to identify weak points. In terms of process, what can be improved going forward? Then jump right back in with the next sprint. Rinse and repeat until the MVP is complete.
Coming up with a solid plan for your MVP sets your team up for success. If you truly take the time to map out your tech stack, product features, user needs, and timelines, you’re going to have a much easier time when it comes to the actual development of the product.
Stay tuned. In the third installment of our MVP series we’ll be divulging all the elements of a successful launch!
