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:

• Defining the Tech Stack
• Prioritizing & Finalize Features
• Mapping Your User
• Organizing Sprints & MVP Timeline

‍

‍

Define the Tech Stack

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:

• Operating Systems
• Python
• PHP
• C#
•  Databases (e.g., MySQL, Oracle, etc.)
• Cloud Infrastructure (e.g., AWS, Google Cloud, etc.)

The client-side is what the client sees; i.e., the front-end elements. Examples include:

•  Markup languages (HTML, CSS)
•  JavaScript
•  UI-Frameworks

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).

‍

Feature Prioritization & Finalization

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.

Prioritization

Feel like a kid in a candy shop? Here are three methods to help with prioritizing features.

1. Theming. Group your list of features into “themes.” For example, you can group features around metrics like “increasing conversions” or “reducing customer churn.” Alternatively, you can theme around customer delight; what features will have the biggest impact on user satisfaction?
   
   
2. KANO Method. Speaking of prioritizing features by customer delight, the Kano model enables you to get clear on the emotional responses of users.

With Kano, features fall into one of three categories: 

• Attractive needs: Customers are delighted if a feature is included but not dissatisfied if the feature is not.
• Performance needs: Customers are delighted when a feature exists and unhappy when it’s absent.
• Must-haves: Customers are unhappy when it’s not included but improving these features doesn’t improve ROI. 

Then, create a focus group and ask them the following two questions about each feature:

1. How would you feel if the feature existed?
2. How would you feel if it didn’t?

The members of the group then respond with:

• Neutral
• Like it
• Dislike it
• Tolerate it
• Expect it

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:

1. Reach. How many users will it affect?
2. Impact. How much will it move us toward the vision?
3. Confidence. How confident are you in its success?
4. Effort. How much time will it take?

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.”

Feature Finalization

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.

‍

‍

Map Your User 

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.

• Label the top-left quadrant current pain. This is how the current situation is deterring you.
• Label the top-right quadrant current gain. This is how you benefit from the current situation. 
• Label the bottom-left quadrant future pain. This is the cost of the change or risk.
• Label the bottom-right quadrant future gain. This is what you stand to gain if you make the change or take the risk. 

‍

‍

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. 

• Current pain is that you don’t have enough information about your users to really customize their in-app experience. 
• The current gain is that you’re not pestering them for a bunch of information at sign up -- this may be contributing to a higher sign-up rate. 
• The future pain (if you made the change to a more robust sign-up process) would be potentially annoying your users and losing sign ups. 
• The future gain would be you can create a more tailored in-app experience, and therefore may improve the user experience and retention rate. 

‍

‍

‍

Organize Sprints & MVP Timeline

Between the first and second installments of this series, we’ve talked about:

• The why of it (why this product should exist at all)
• The how of it (how you’re going to finance it) 
• The who of it (hiring for the project and getting agreement on roles) 
• The what of it (what exactly you’re going to build)  

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: 

• Higher-quality product in less time 
• Project is more manageable 
• Ability to make smart pivots
• Easier to keep team aligned throughout course of project

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: 

1. What can we get done during this sprint? 
2. How will this get done? 

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: 

• The overall objective 
• What tasks ladder up to reaching that objective 
• Who is responsible for each task
• Length of time 

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: 

• Making note of any bugs or glitches 
• Creating tasks for any items that come up during the meeting 
• Ensuring all these details are captured in your project management tool 
• Hearing out any concerns from the team 

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. 

‍

‍

Summary 

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! 

‍

‍