The concept of a “minimum viable product” came up in a conversation with my friend Mike; as we started the discussion I thought I knew what the MVP was all about. Turns out I didn’t…
I was thinking of product design and controlling feature scope – but it’s actually about market research.
‘Market Research’ is something I’ve been considering recently, so following from this MVP discussion I thought I do a bit of reading. If I was confused, maybe others are too? And is the ‘minimum viable product’ something iOS developers should bother to think about?
Minimum Viable Product: Introduction
Almost all of the articles I’ve read discussing the minimum viable product technique have started with the definition, so this one will be no different:
“The minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
The concept of building an MVP is all about learning; it’s about the validation of your idea. You want to know if the product or service that you have in mind it’s actually something that people want.
Pursuing your product idea requires some kind of investment. You might view it simply as ‘time’, but it could be a whole lot more ‘money’ than that. The minimum part is about safeguarding a bad investment. Spend as little as you can to learn what you need to know. If the data suggested the idea is a flop – building the MVP has saved you the effort.
Minimum Viable Product: Confusion
Building a minimum viable product doesn’t necessarily mean building an actual product. Similarly, it doesn’t necessarily mean building a subset of the final product, or, as per my own confusion, building only those features that are absolutely needed. You’re just building something to work out if the idea will attract customers.
For example, a video could be used to show the overall product concept and highlight the main benefits. Work out a way to show that to enough of the right people and you’ll get some very useful feedback.
Building a minimum viable product doesn’t necessarily relate to small or minimal, product ideas. It’s about research, early in the process, performed as a validation step. In many ways it’s more suited to large projects as the effort/investment risk is higher.
If you want some actual examples, The Ultimate Guide to Minimum Viable Products provides an excellent overview of different ways to deliver a minimum viable product.
An App Store v1.0 Release as a MVP?
What form a minimum viable product takes will depend on the specific product, and therefore the target audience, in question. At the root though, we want feedback from potential customers. Although it’s not always be the case, a large sample set is often considered to produce more reliable data.
When you release a product into the App Store it is immediately available to millions of users; a lot of potential customers.
This is where I think there is potential confusion for iOS developers. It can be tempting to view this as a means of getting feedback on your idea; as the means for getting feedback on your idea.
Developer has app idea. Developer is keen to find out if the idea will be popular. Developer evaluates possible feature set, strictly keeps to the essentials only, plans for an early 1.0. That’s a quick, minimal approach to getting the idea in front of users, right?
The problem is, you can’t rely on a 1.0 release in the App Store as a measured process, as a feedback loop for you to learn about your idea. First, you don’t have control over the exposure of the app so it’s difficult to know how many people have considered the idea. Second, whilst you do have some data – downloads, and more tenuous, ratings and reviews – they’re not necessarily good channels for evaluating customer opinion on the idea.
There’s no reason an ‘app’, in some form, can’t serve as a vehicle to conduct market research. But that doesn’t mean the App Store is the best arena, or only arena, to carry out that market research.
Should iOS Developers Consider Building a Minimum Viable Product?
How do you know if you should make an MVP in the first place? If you should do some market research before starting on the full implementation? There’s a cost involved, after all. Maybe you’re better off getting on with the code…
From the Lean Startup/MVP point of view, it depends on whether or not the product idea has been validated. Do you know if this will work? If people want this?
Making your own version of a well established type of app, e.g. a to-do list app? You’re probably safe to press on and focus on making an awesome implementation. If on the other hand, you’re in uncharted territories, you might consider some validated learning.
PandoDaily’s Three reasons not to build a Minimum Viable Product does a good job of showing both sides of this decision: When to, and when not to, build an MVP.
Market Research – Parting Thoughts
Deciding on whether or not to do some market research goes beyond: ‘what type of app am I making?’. There are a bunch of factors involved. I get the feeling that for some indy developers, reason #2 in the above article, “you don’t care if you’re wasteful”, is cited.
Writing this app is good practice; it’s my hobby and I enjoy doing this; it’s only my time… After launching 3 apps I’m starting to question that. I need to be honest about what I want to achieve.
For now, this is what I’m taking away:
- I’ve got lots of ideas. Just because one hovers at the top of my list doesn’t mean the idea is validated.
- For market research, the concept of a ‘minimum viable product’ is interesting.
- I don’t think iOS developers can rely on the App Store for validating (or disproving) an idea.