7 things to test for other than viability
What are you really trying to validate?
Everyone has a different definition of what viable means.
While we can agree it means something capable of working successfully or at the very least feasible the definition will change depending on who you ask.
For marketing, it will mean one thing, for the development team another, and for the CEO it’s something else entirely.
These different viewpoints and qualifications result in a disconnected team and misaligned motivations. Which means the expectations are probably not the same either. And if the expectations are off, you run the risk of delivering something that’s not what your client was asking for, or your team will show you something that doesn’t solve the problem you were trying to fix.
This happened to us once when we delivered on functionality, but the expectation was for polished design. We had failed to adequately explain that to get to the design implementation we first had to ensure the functionality was in place. It was a tense call, but we had the conversation and moved on. Though it was clear the expectations were off for both sides.
Now we make sure everyone is on the same page.
Here’s how we do it.
MVP or Minimum Viable Product is a catchall term people use to describe the first few iterations of a new idea.
The purpose of an MVP is to build a platform that will be iterated upon in order to test and learn as quickly as possible. However, that’s hard to do if you’re trying to test and learn a lot of different things at once. You won’t know which factors contributed to what’s now working or what’s setting things back.
This broad approach doesn’t help when you need to develop a strong hypothesis to test or set clear expectations.
Rather than work towards an overall, and undefined goal of an MVP. Let’s make sure the expectations are clear for all team members and stakeholders and that everyone is working on the most crucial part of the product at any given time.
To do that we have to redefine what we mean by MVP.
First, we have to assume we’ve made it past the first hurdle and that the core piece of functionality is viable. That it does work. If you’re not there, then otherwise, yes, start with creating a minimum viable product. (This is the stage we were in in the example above)
However, let’s say we’ve done that and we’re ready to start testing our product. At this point, it’s critical that we’re specific about what we’re trying to learn. Without doing that everyone will be biased towards working on what is most important and relevant to themselves.
To do this, we change out the Viable aspect of MVP to something that explicitly calls out what the current focus is.
Instead of a Minimum Viable Product, we might define and test a Minimum Marketable Product or a Minimum Designed Product. Whatever is most important at the time needs to be known by the whole team as every discipline will be involved in one way or another in seeing it through.
Here are 7 things you can test for instead of viability:
Every product needs to be marketable, but especially any new product that no one knows about yet. Your Minimum Marketable Product will need to clearly explain what it is you’re building and what benefits people can expect from it. You need to tell the story about your product and why what you’re doing is important.
Being sharable is different than being marketable as it’s based on other people, people you don’t know, doing your marketing for you by recommending your product to their closest family and friends. To make it easy for them to do that you have to create assets and brand that is memorable and that people want to share.
One of the best indicators that your product is on the right track is when people start paying for it. To make your Minimum Sellable Product you might need to focus on implementing your payment system and also make sure people can find the information they need when they need it. Which can mean looking into the analytics to see if there are any bottlenecks in your user flows that might be blocking people from getting to your pricing and sign up sections.
(Protip: Stories are marketable, sharable, and sellable if you have a good one)
If you’re handling any sensitive data, this should be a prerequisite. But if you’re at all concerned, it’s best to take some time and make sure you have everything locked down.
It’s impossible to use a product that crashes at critical moments. If this is something you’re product is doing, stop trying to push things forward and instead make sure you're working from a solid foundation. Everything will be easier.
MVPs can be a bit rough when it comes to design as the focus is first on making sure the functionality is in place. After that, though this can hurt the credibility of the product if it’s not up to market standard. To move past this, you should put new features on hold and make sure you have a Minimum Designed Product that is relatable to other products in the market. You don’t have to go overboard, but a polished and consistent design language with a few micro interactions go a long way.
Now this one is a bit more internal, but early on you'll usually know if your product will grow to include a number of features or connect to a handful of third-party applications. The best thing you can do in the beginning is to make sure your architecture is coming together in a way that will accommodate and work seamlessly with those later additions. This one related to making sure you have a Minimum Stable Product as well.
Now all of this ties into creating what we call a Minimum Lovable Product. A product that people love to use so much they come back to it and tell others about it.
However, the point of changing out Viable for a specific target is to come together as a team, understand what the most important goal or objective is, and then execute against that.
Because, what you want, and what's best for the product, is that everyone is clear about what the expectations are.
Make sure you’re testing the right thing.