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'm currently putting together MVPs of the difficult UI aspects of my system, because those are the parts I'm worried about. The back end is actually pretty straightforward. The UI stuff is the stuff I want to get in front of users for review.
After that, I need to do some technical MVP for proof of concept, to prove to myself that my assumptions about certain data patterns are actually correct.
The important thing, though, is to get to where I have working code I can show others to get feedback, even if that code isn't anywhere near complete as a marketable product.
Testing your UI is what most people would call prototyping, though. You've already decided on what you want to build, just not what the interface to what you're building should be exactly. An MVP is for deciding what to build or whether to continue to build.
Or more importantly, what version of what you build will your customer pay for/use - i.e. what will add value such that it would change their behavior.
An MVP will tell you if it's even worth doing that UI design in the first place. If you can get people on your site going "I'd pay for this if only it didn't suck to use" then you have an MVP that's validated you have a market.
If you have a great to use product and can't get people to stick around on the site, you've wasted a lot of effort.
A UI is the M in the MVP. The back end would be a fair bit of work for nothing very exotic. I can test certain assumptions about the front end using public data without all that effort. Technically, it's probably a demo, not a true MVP, but it should tell me a lot about what works and what doesn't, and it shouldn't be too hard to expand into a true MVP afterward.
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?
I can see what you mean here. I feel like this often applies to SaaS products and Network companies like Facebook, where forerunners in the field have validated the need for something in the market, but failed from a technical or a distribution angle rather than a product perspective.
Its a very good point. I think the 'lean' movement is really meaningful when you're talking about big engineering innovations (where the alternative is often between doing a big build or doing manual work) rather than a network or service business where the concern is actually around the quality of the network or service you're providing, which can't be easily faked or tested.
Not sure what you mean by 'validated market'? How can you have a 'validated market' without having a 'validated product'? A landing page, or a competitor's customers, don't quite count as a validated market.
A validated product is simply a product that people find of significant value such that they change their behavior to use it. That can be either paying for it, or just replacing some existing tool in their current toolchain.
If the point of an MVP is to reduce product risk (and I think it is), then yes, products where you're essentially certain that if you build it they will come don't gain anything from an MVP -- you've already solved the problem it addresses.
The people who are beating the drum for "always do an MVP" suspect that founders systematically overestimate how well they've figured out the market and how exactly they've nailed what their customers will want. I think they might be right, there's a "whistling past the graveyard" habit that optimistic startup-types take on where they avoid bad news in the hope it'll go away.
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?"
If you've got a friend who's a private pilot or working on some sort of flight certification and needs hours... you could probably talk them into taking you up for the cost of fuel and lunch.
A farmer may not feel comfortable with you trundling through their fields on foot.
Back in 1984 I took the first infrared crop pictures in Michigan. We rented a Cessna, took out the passenger seat and I got on my stomach and pointed the bosses 35 mm out the inspection port.
Special IR film from Kodak that had to kept refrigerated when it wasn't in the camera. I could feel the pilots tight turns in my gut. Good times!
Good thinking, but in this case no. The high value crops they were going after were almond orchards and the specific data they wanted from the trees were only visible from overhead.
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.
I recall, but can't find, a story on HN about someone who, before building any product at all, put up a website with an explanation of value, and a "purchase" page. People put in their credit card number trying to buy the product, validating there really was some market for them.
I've played around with it a bit, though haven't followed through heavily on any of my PoCs so far, but the market first idea seems to be quite useful for a lot of areas. Enjoyed the book quite a bit, was not a fan of their startup academy at all.
I liked Start Small Stay Small, but haven't tried the academy. I just try things in my own business, school of hard knocks as it were. How much is the academy?
It was a year ago, so not sure I remember, but I think it was $50/month and more if you wanted content faster. I think it was a lot more paying for forum access/feedback than for material, but I felt it wasn't worth it for me and cancelled after a month.
“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)?
I agree with a lot of what you write even though I still see value in the idea behind MVPs.
My biggest issue is with the discourse and the stories that are written about. I find most so-called case studies of successful product dev by methodically following the lean process to either be lacking OR highly suspect(due to key missing details).
I was reading the book Nail it before you Scale It and while I wholeheartedly agree with the title of the book and even the theoretical ideas, it was disconcerting to me that a lot of the successful examples cited in the book are companies that no longer exist.
Overall most authors on this topic do a great job of pointing out how a company wasted ton of money on building a product no one wants but the same narrative seems to oversimplify how the company finally achieved success.
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"?
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.
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/