An MVP can be a cultural challenge as much as a technical challenge. Sparkbox president, Rob Harr, shares his ideas about how to tackle it.
Rob, what can you tell us about how (or why) clients decide to adopt an MVP approach?
It can be based on a lot of things. For example, sometimes it’s based on constraints. There’s a limit on time and money. In other cases, there’s just an open question about what should be done. Everyone is afraid of risk in software, and the biggest risk is building the wrong thing. An MVP can de-risk a project by testing a hypothesis.
How do you know where to start?
To be honest, you know you’re making the right decision if it’s a harder decision to make. If you choose to focus your MVP on an area where you know the risk is or where the unknown is. If it makes you uncomfortable, you’re probably getting closer to the right MVP starting point. What you need to do is define the question well, and make sure the MVP is going to help you answer that question.
There are going to be times when stakeholders are unhappy with an MVP. They want the whole ball of wax. How do you suggest handling that?
When you start an MVP project, you need to have the end in mind. You need a vision and you need to set that vision with your stakeholders. The MVP is an initial investment in the vision, and it minimizes risk. It keeps us from throwing good money after bad.
The MVP is an initial investment in the vision, and it minimizes risk.
– Rob Harr
Does it make sense to begin with MVP when you can’t always get to something launchable?
“Viable” means different things to different people. The MVP has to be developed in the context where it exists. You have to think about risk tolerance and how that might be different for a corporate product or a startup. Some organizations are going to be able to push “viable” a little further, while others are going to need to start bare bones. You should also remember to keep the user at the center of your thinking. What makes the user interface “viable” is what it means to the user, not what it means to your team.
Does MVP planning extend beyond the MVP and get into roadmapping for the product?
Often yes, the planning you do for an MVP is going to touch on the bigger project. (Depending on your resources and context, of course.) You always want to have an eye on the future vision. But you also have to realize that the future vision will almost certainly change. That’s why you’re testing (and de-risking) with an MVP. But the fact that you’re doing the planning is incredibly valuable. The act of planning is even more important than the plan itself. This is part of the journey that you go on to get to your end state.
What advice do you have for folks who are tackling an MVP?
Be open-minded. Stay curious. Successful people have strong beliefs, loosely held, and they’re open to learning. Remember that you are not the user. The user will tell you in a million ways what they want, and you need to listen. Document where you are, and document your vision. Always be prepared to learn and adjust to internal and external factors.
