Validating ideas and the role of MVPs
Specific points to keep in mind while validating your idea.
I always wondered what the most difficult part of starting a company could be. A thought into this question and some twitter scrolling later, I think I have an answer — It's definitely the initial years, or the time until you are growing your team.
Concluding this isn't that hard, especially if you have been reading startup news, social media discussions, and been part of knowledge sharing over the internet. Here's why I think the initial years are the most difficult:
First, you have to make the biggest future determining decisions — like finding the right partners, understanding the market need accurately, predicting the best long-term vision, studying the viability — at a point when you are least experienced.
Second, in most cases you have to accurately understand the philosophy of starting-up — as in, why start-up? especially when working for someone else is much easier — is it a desire for money, is it a pursuit towards social good, is it what you just feel you should do? The trickiest part is that there's no definitive answer to this particular question. You just have to find a way to be in peace with your mind and heart (like achieving a semi-version of enlightenment in the most anxious years of your life).
Third — Timing, Luck, and Risk. You have to play Russian roulette with three of universes' most dazzling conspirers. This point is also closely related to the universe being a teacher. If the first two points aren't executed properly, there would be a considerable load in dealing with events of risk, timing, and bad luck.
That's not it, there's more. I will leave a point 'Four' here for you to think about. What problems did you face in the very initial phases of starting-up?
Given these difficulties, it's understood that 'starting' already is a big enough wall to climb across. Though, the scenario is not the same as before. The Internet has been a friend and foe regarding this situation of starting-up. Friend as in making it easy to learn from other's experiences, foe in the sense of sometimes providing more than we need, through its sheer hugeness, abundance, and pace of information.
And hence, here I am leveraging the 'friend' part of the internet, to explore one of the many problems of starting-up: the role of building a minimum viable product (MVP) to validate our ideas. Due to the fact that 90% of the internet is vague, I intend to add more value to this write-up by being more specific. As in, concentrate more on understanding the exact methods that founders have used to make it work for them, and then conclude it down in points. Later, I plan to use these learnings to validate my ideas as well.
Let’s see how this goes:
Before we dive deeper, let's ask the question — What an MVP is? By definition aka Google's top results say it to be the barebones product wherein features are usable enough to get feedback from initial users.
That said, it doesn't have to be something that requires a lot of capital and a lot of human resources. In contrast, it needs to be something that requires a lot of thinking. Thinking about the idea, the future of it, how people could use it, how to understand if this solves a problem, what possible pivots exist, and so on. So here's a myth-buster: MVP requires time — it's just that, rather than coding/building time, it requires majority of 'thinking time'.
MVP = 80% thinking, 20% building
Eric Ries; Validated Learning
Talking about MVP, the first person that comes to our mind is — Eric Ries, author of The Lean Startup who learned how a startup is more about management. In his book, he mentions how the importance of MVP is regarding the learning about the customer segment that helps you validate your idea and further realign trajectories.
How exactly to learn? It’s by asking questions in an effort to prove our assumptions in any way possible. And that’s the reason Eric says — an MVP is not necessarily an easy way to build something which the name suggests, it does require some pretty hard thinking and questioning.
Where to ask these questions? Well, that’s what we will see in our following points, but briefly, the answer is to reach out to your target market on whichever platforms they are available on. The platform could be Facebook, Quora, Offline events, Youtube, Google Search, Hacker News, Whatsapp, etc.
Also, it's not necessary that the MVP is built in a 'minimum' possible time frame — what matters is if it helps you achieve the 'validated learning' target. Validated learning is having enough data to conclude an interest or disinterest in the idea. It could be anything from ratios to the number of subscribers to surveys to meet and greet discussions to direct messages or cold emails. Anything that gives you data that connects with your assumptions is valuable. No matter if the data is positive or negative, it helps you conclude. [1]
Through MVPs: aim to achieve validated learning
Ryan Hoover; An MVP is not necessarily a product
Ryan Hoover, is the founder of ProductHunt (PH), after starting PH he blogged on how the idea started, here's what we can learn from it.
PH started with everyone falling in love with a 20 minute MVP, which was building a list of subscribers through a third-party platform to whom an email was sent everyday highlighting new products. The idea was validated by gauging the number of people that were interested in subscribing to the emails — in this case 170 people subscribed in just two weeks. Ryan also mentions how his network played a very crucial role in validating this idea, years of blogging and building projects made things more accessible to him. Networks help not just with validation but later also in building a team. [2]
Once the MVP showed positive results, a desire in early adopters, then the coding actually began. The following image is an archive of PH website from December 2013 (It was built in the Thanksgiving holidays).
Back then Ryan used a platform called Linkydink — a link sharing tool — to gather interested subscribers.
To summarise an MVP has two important elements: A call-to-action (CTA) and a network. A CTA could be a landing page, a video, a blog, a cold reach out, while a network could be social media platforms, community platforms, messaging apps, offline events, email clients, search engine, etc.
Today we can create many such combos of CTAs and networks to test our assumptions, depending upon what our target market is and what kind of audience a platform provides. It also makes sense to diversify your MVP testing between different combos.
MVP doesn't have to be a product. It can just be any CTA + Network combo to test our assumptions.
Joel Gascoigne; Think what kind of 'minimum' serves you best and then sever one assumption at a time:
Joel is CEO at Buffer — an application which started specifically for scheduling tweets. In 2011 he wrote a blog about how they built and he mentions how he didn't make the mistake of diving directly into coding. They built a very simple landing page checking one assumption at a time. Here are the assumptions they busted stepwise:
a. Do people need a Twitter scheduling product? CTA: ask for email
b. Will people pay money for it? CTA: before asking for email, let them select the pricing (which also includes a zero dollar option).
Check it below:
Joel mentions how once the core assumptions are validated, the next step is to build with initial adopters, course correcting the product while making sure it's in-line with your vision and also with what would be best for the users. [3]
Check one assumption at a time with your MVP
Shreyas Doshi; Biases related to Product development:
Shreyas Doshi is PM at Stripe. He wrote a Twitter thread regarding this, but for this article, I will only be selecting biases that could closely take place while the MVP phase.
a. The business model assumption: As in the previous point we discussed assumptions, a more closer thinking could lead you to more hidden assumptions which can be cleared out while MVP testing. One such assumption is ‘how important is the problem for the user‘, the background idea of asking this is the fact that a person has many problems, but only has enough time to address the most important of them. Is our idea a problem big enough to be solved with a product? Or can consulting be a better business model?
This could be solved by asking questions about how important this problem is for them on a linear scale of 1 to 10.
Think about more hidden assumptions
b. The Focusing Illusion: This means when we focus on a problem specifically, it becomes important at that particular time. This links to the previous assumption we discussed, how big is this problem? are we pitching users a story which once forgotten, the desire for our solution will too? So if future users are committing under this scenario, there's a chance their commitment to use it or pay for it is inflated. The best way I think to tackle this is 'Not to sell an MVP, but rather to just put it in right place to see the reaction', 'Keep the MVP simple and to the point'.
Don’t sell your MVP, just place it in the right platforms
c. IKEA effect: If we build something with our own hands — it attracts more value from our perspective. A valuation illusion. This arises because we consider ‘our time’ as an additional value into the product. For instance, if we put X hours in developing an MVP: for us the valuation = product + X hours, for the customer it is = product. For customers, it is just the product, no matter what. The best way to move away from this is to minimize 'X' i.e make sure if your MVP in a true sense is a ‘minimum‘ viable product. If you have not thought of clever ways of validating the same assumptions, think about it before proceeding. MVP is smart work plus some level of ‘jugaad‘ (focus on achieving end results). To exactly define how minimal, here's a quote from Eric Ries: “Probably much more minimum than you think “
The 'minimum’ time required for an MVP is different for different products. One needs to identify what minimum best works for them.
d. Build MVP end-to-end: This means that if an MVP is a feature, most probably it is a core to your idea, and hence the get best quality data this feature needs to have an end-to-end functionality as if it can be a standalone product in itself.
This avoids excessive reiteration and testing different permutations and combinations for the same basic assumption testing. Research for once all the questions we need to ask ever for this assumption. This also to some extent includes the ‘Bias-of-Building’ fallacy wherein some research/development is postponed due to time limits or any other constraints.
Build robust end-to-end MVP
The right way to build a product post basic MVP could also be to test many assumptions as following MVPs. This makes a product a set of standalone MVPs aka features. Here’s an image to explain what it means:
In the above image, the inner circles depict the many end-to-end MVPs aka features, while the outer circle is the product itself. As the inner assumption testing MVPs increase the product inflates backed by standalone features.
To learn more about biases in product development, read Shreyas’s thread:
I guess we have made this essay enough big and can reserve future explorations for next time. An interesting exploration for a future post could be ‘clever ways of validating assumptions‘. Let me know in the comments if you would like to read more on this topic.
Let’s conclude the points we came across:
MVP = Minimum capital, minimum human resource. 80% thinking: 20% building
From your MVPs, achieve validated learning about your customer segment. In the case of feedback Positive = Negative, it helps us conclude.
An MVP doesn't have to be a product. It can just be any CTA (call-to-action) + Network combo to test our assumptions.
CTA could be a landing page, a video, a blog, a cold reach out, while a Network could be social media platforms, community platforms, messaging apps, offline events, email clients, search engines. There could be many different smart combos of these.
Make a list of your assumptions. Check one assumption at a time through an MVP.
Keep learning from initial adopters. Build, Measure, Learn, Adjust the trajectory/Pivot, Iterate. Make sure your vision is inline too.
Find more hidden assumptions. Be aware of product development biases.
The minimum time required for an MVP could be different for different products. One needs to identify what minimum works best for them.
Don’t sell your MVP, just place it on the right platforms to check the reactions.
Build robust end-to-end MVPs.
Thanks for reading the playbook! Use what you learnt to build your own playbook.
Loved the essay? Haven’t subscribed yet? It’s free!
Think your friends can benefit from this and content regarding startups, technology, business. Share with them this article.
References:
What is an MVP https://leanstartup.co/what-is-an-mvp/
The wisdom of the 20-minute startup https://www.fastcompany.com/3023152/the-wisdom-of-the-20-minute-startup
Idea to paying customers in 7 weeks https://buffer.com/resources/idea-to-paying-customers-in-7-weeks-how-we-did-it/