An MVP is not a Cheaper Product, It’s about Smart Learning

These days, I'm beating the drum that a MVP is not necessarily a V1 of a product idea.

If you consider the goal is to learn whether you can have a business or not, you start thinking less in terms of your product and more in terms of what is the underlying problem, customer segment, market conditions, discoverability etc etc

Also, instead of thinking as idea -> MVP -> product, it can help to think of MVPs as a series of experiments, rather than a monolithic product designed to verify all assumptions.

I blogged about this process that we could have followed at my company, instead of burning cash and months of work building something nobody wanted: http://www.sparklewise.com/minimal-valuable-experiments/

Sometimes I think the whole lean startup movement is either heavily misunderstood, or just overrated.

If you have a validated market willing to pay for your audience's eyeballs (based on, let's say, startups that have been in the space before), do you still need an experimental MVP? Or should one focus on building the real product?

This reminds me very much of pg's recent essay about doing things that don't scale (http://paulgraham.com/ds.html). That essay's very direct title seems to come from the fact that technical founders, like the Stanford students mentioned in the article, can be biased to solving engineering problems before solving business problems. "Do things that don't scale" (as well as Steve's advice here) is a reminder to solve the actual problem, and to solve it in the easiest way, not the most fun, technically challenging way.

So I asked, “Would it be cheaper to rent a camera and plane or helicopter, and fly over the farmers field, hand process the data and see if that’s the information farmers would pay for?"

After the 2nd paragraph, I assumed a question like this was going to be asked, but my "frugalness" assumed it was going to be:

"Wouldn't it be cheaper to get a DSLR, and spend 8 hours walking through a field and taking pictures?"

TLDR: we often rush to building an initial version of a product when we can jump straight to manually creating value for a customer and testing demand by charging for it, then crystalize that learning into a product later.

I believe there's a corollary to this: you can jump straight to building an MVP when you're building for yourself and are confident there are others like you. I remember PG describing it (in a video that I can't find the link to) as a design pattern where the broadcast signal and receiver all within the same brain.

Even better is when the thing you build solves a real problem at a business you're running and it makes you more money. My favorite YC example is Ilya from Mixrank. He was working as an SEO consultant when he realized some of his process was abstractable as scripts, wrote some to help him do his job better, then emailed it around to other SEO colleagues to see if it helped them as well, and all of that validated learning helped him attract his technical cofounder and then build Mixrank as a product. I believe they may have even been profitable before starting YC?

I am actually in the process of reversing the process and building the marketing first, and not building the product until there is enough marketing validation. My thought is, if maybe 1 in 10 or 1 in 20 ideas is going to sell, better to figure out what will sell before building out every idea and then hoping for the best each time.

The sentence that jumped out to me:

“We’re engineers and we wanted to test all the cool technology, but you want us to test whether we first have a product that customers care about and whether it’s a business. We can do that.”

...

Me: I find it a little interesting the amount of silence on this type of post, that cuts out the noise of building for the sake of building and focusing on what customers, actually, want, and not over-obsessing on your stack.

Most things can get you through build-measure-learn quick enough, leaving plenty of room to get out of the building.

I think you can read the post and come to a very different conclusion and one that I have written about in the past.

The MVP is a curse for ambitious technology companies that want to grow. In an increasingly transactional world, growth comes from long-term customer happiness. And long-term customer happiness comes when customers adore your product or service and want you to succeed. You should be thinking about what it will take for customers to love you, not tolerate you.

In this case, insights from the data about the agriculture is what customers really need. And if you give it to them in a meaningful and actionable way, they will love it (at least that's the theory). That's radically different than what might be minimally viable (e.g. a ton of data that they could sift through in Excel).

Really think about the type of mindset change it would take. What would it take you to create a Minimum Lovable Product (MLP)?

http://blog.aha.io/index.php/the-minimum-lovable-product/

This is one of the problems I face with building 5KMVPs for clients. They often confuse how they want their final product to work, with the product that their clients will pay for.

The truth is, I think most entrepreneurs (and engineers) can easily fall into this trap. It is helpful to have someone else to bounce ideas off of - and that forces you to build what the client would pay for, versus what you want to build.

Even I fall prey to that for my own projects. Even though I build MVPs for people, when it comes to my own projects, I have to make a conscious effort to CONSTANTLY ask myself - is this what I want to build or what the client will pay for. Often times, I have to even take a step back and talk to a trusted friend that understands the internet. Get their feedback.

So, the most valuable thing I have learnt in my year+ running 5KMVP is that my most valuable service is when I push back on the client. Asking more questions, probing to get to the heart of the problem they are trying to solve.

Very good point on market centric versus customer centric view of the MVP. Is the critical path "Will someone pay for this" or "Can we get it to work"?

The MVP is meant to be a wet thumb in the air: is the wind really blowing north, the way we think it might be?

This is true not just at "building an MVP" stage. At my current startup, we are focusing on traction, across different channels/verticals. We have found it quite useful to test and learn about these channels by running experiments.

Perhaps a better name for MVP would be FVP: "Fastest viable product". The end goal is to get something in a customer's hands as quickly as possible. There is no reason for the product to be minimal (or cheap). Renting a plane and manually processing images is extremely expensive from a per unit perspective - but the more important feature is that it can be deployed quickly.