Know how to scope an MVP quickly?

We’ve all been there. Your idea has been approved, you have the budget, it ladders up to a company level OKR, and the space has been cleared to build. You have the resources, and the time (which in cases like this, often starts *now*), but no scope. How can you scope an MVP in a way that enables you to start user testing in a few days, and maybe even start building tomorrow? A product leader and UX partner can’t do it themselves unless it’s a really simple feature designed to build upon an already existing strategy. And even if you can, it may be a challenge to get engineering to buy in.

Today’s engineers are not code jockeys, or at least they don’t want to be. If they’ve been around the product a long time, they have ideas, and they often have a good idea of the user persona for which you’re building. Also, back to the code jockey thing, no one likes to be told what to do, even if they do think the idea has merit. By getting your cross functional team to buy in, you’re going to have a much easier time when it comes to execution.

So, how do you come up with an MVP in two hours, one that engineering is bought into and excited to build? Some call it user story mapping. Take away the catchy title though, it’s something that should be done in the case of nearly every new product.

Use of Design Sprints

Design Sprints are a functional way to build an MVP, especially if you have the time and truly don’t know what product you need to build. I’ve been a part of many design sprints where the outcome is a stellar design that solves the problem well. However, if you do the full 4–5 day sprint, it becomes expensive, and oftentimes doesn’t get built because the vision is so grandiose, and becomes hard to find an MVP. Do you really want to spend all of that time sprinting, designing, and user testing on something that never gets built?

They’re fun, they build team morale, and they get buy in, they’re just expensive. If you can whittle it down to a couple days, it’s better, but then you miss the full power. If you really don’t know what to build, and are trying to identify the core problem, it can be a great option. However, in early stage companies, the problem is usually much more apparent. The company exists after all, and has hopefully found product/market fit by the time that you’re called in. This is also the case with new business units in a larger organization.

So what’s the answer? Keep reading! Any zero-to-one project with reasonable investment behind it should involve a process like this. It’s simple, and it’s fast.

What is User Story Mapping?

You identify the three or four core features that are required to build a previously identified MVP, and team up with engineering over the course of a ½ day (or so) workshop to write stories that will help build that feature. If you’re willing to bypass user testing (don’t do that, ever), then architecture and backend design could technically start once this meeting ends. However, product and UX should work together to do some light testing on a prototype before sending engineers off to code.

Seems pretty simple, right? Sort of, as long as you know the product you’re trying to build. I’ve done a version of the process above, but it involves the entire team from ideation to story creation.

Starting The Project

This is my version of user story mapping. It happens when you know what product you need to build, and you need to quickly define scope. You also need to start building quickly.

I once worked on a project where my team was charged with an initiative that would increase retention. Over the course of 12 months, retention hovered around 20%. We were acquiring users faster than any competitor, but we were losing them almost as fast, and it was imperative that we figure out how to stop the bleeding. Through a lot of user research, and market analysis, we identified what to build. We needed to make the product sticky. There wasn’t anything significant that prevented a user from going to a competitor.

We had the data, but we didn’t know what lever to pull. After a few user interviews, and watching users use the product, it became clear. In a few cases, customers were using three tools to do the job, where one should suffice. The steps (and tools) were:

1. Write down an order on a piece of paper.
2. Add everything up in a calculator.
3. Enter the final amount to charge on their mobile device.

We concluded that the best way to make the product sticky, and make it user friendly, was to build an inventory management system. It didn’t hurt that it was on the list of things investors, and senior leadership wanted. To be clear, it was the call of the product team and it also aligned with overall objectives.

After deciding to build that system, leadership conveyed that they wanted it delivered in something like eight weeks. Everyone who has been part of a similar process, and anyone reading this, knows that a zero-to-one product is very rarely, if ever, going to be scoped, built, and delivered in eight weeks. But we were going to try.

The Process

1. If you’re leading a product team, you should have access to a UX designer and engineers. You’re going to need all of them for this process. Schedule a four hour block (it’s fine if you don’t need all of the time).
2. In the process of your analysis done prior, you should know what you’re building, why you’re building it, and the impact that you expect it to have on the business. Have something prepared in advance that you can walk through with the team. This will set context.
3. Once you’ve communicated what you’re building, start identifying features that could be included in this new product. Identify all features, even if they seem like they should be in a later iteration. Jot these features down on sticky notes and throw them on a board. No rhyme or reason, just put them on a board, a wall, anything.
4. This step is pretty typical of a design sprint. After you have all of the features listed, group them into similar ideas, and get granular. It’s okay if you have 10–12 categories that have five sticky notes each. The idea is to identify feature sets, not themes. You should have a pretty good idea of what the product could look like years down the road. This doesn’t mean that you’re going to build all of these feature sets. Customers may drive it down a different path based on outright requests, or just by watching how they use it.
5. Start looking at these feature sets and peel them off one by one. Document them, and add them to a long term backlog, but keep your focus on building only what’s absolutely necessary to solve the problem. Continue this process until you peel off a feature and think, “well, now the product doesn’t work,” or “now it doesn’t solve the original problem.” If you’re down to four or five features, and you can’t remove any more, then congratulations! You’ve scoped your MVP.

Not only have you identified the scope for the product, but the entire team understands what you’re building, and why. This is going to make your life a lot easier in the long run, and most engineers love being a part of the process anyway.

A word of caution with this process. When you have all of these possible feature sets on the board, it’s tempting to build as many into the MVP as you can, and there will be dissenting opinions in the room about what really needs to be included. Remember though, it’s your job as the PM to ultimately make that call. And it’s going to be much easier to make that call if you’ve done your research beforehand and have data to back up your decision.

Also, while this is a really great process as step one when you know the product you want to build, it also works well as step two. If you’ve spent time identifying what lever to pull, using contextual inquiry to understand what problem users are trying to solve (that’s all step one in this case), then you can use this scoping process to quickly come up with your MVP. It’s flexible, and it works. This is different from a typical design sprint since you’re collecting ideas from a designer and engineers, instead of the customer. But, you’ve already done your research so you know what you’re building and why. Besides, engineers are the source of great ideas. They’re often passionate about the product, and may have been around it for years.

So, next time senior leadership asks how quickly you can get put together a scope for a specific project, and a timeline. Tell them a few hours.