Leave a comment
Get the GH Bookmarklet

Ask GH

Reid Hoffman has his quote: "If you are not embarassed by your first product, you launched too late." I've been a long reader of Tim Ferriss and follower of the startup world. Due to the whole MED (minimum effective dose) and MVP way of thinking, I can't help but think that there are a lot of ppl (including myself) who take this as permission to do up to what is acceptable (like a 40%) instead of going for excellence (>80%) What do you think? What is the best way to go about creating the essential stuff and testing it without cutting corners?

  • AA

    Anuj Adhiya

    2 months ago #

    Based on the extended description you provided, I think you need to separate 2 concepts in your mind:
    a. What the purpose of an MVP is
    b. What it means to launch

    a. MVP:
    The purpose of an MVP is to Identify your riskiest assumption, find the smallest possible experiment to test that assumption, and use the results of the experiment to course correct.
    Good reading around this topic:
    https://growthhackers.com/articles/a-minimum-viable-product-is-not-a-product-it-s-a-process/
    https://growthhackers.com/articles/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/ by @sblank
    https://growthhackers.com/articles/minimum-desirable-product by @andrewchen
    https://growthhackers.com/articles/making-sense-of-mvp-minimum-viable-product-and-why-i-prefer-earliest-testable-usable-lovable/

    b. Launch:
    I'm bringing this up because you specifically brought up that Reid Hoffman quote
    Can't say it better than this post by @ericries: https://growthhackers.com/articles/dont-launch/

  • SK

    Sean Kirby

    2 months ago #

    I think you're distorting the concept of MVP by thinking of it as the end of the process. If you're doing it right, you still strive for as close to perfection as you can get. You just don't try to do it in a single step. You iterate your way there. The MVP is just the first phase. One the idea is validated, you can always incorporate improvements and add new bells and whistles down the road. In fact, you should always be working on improvements. Great products are never "finished."

    You are also only looking at it from just the product developer's narrow angle. Just because you spend months or years on bells and whistles you are proud of to create a "perfect" product doesn't mean potential customers will feel the same way. And their opinions count more, since they are the one's who pay for it. Personally, if I learn that I need to pivot, I'd rather do it earlier in the process.

  • RS

    Rishabh Saxena

    2 months ago #

    Building an MVP does not mean cutting down on excellence at all! Steve Blank wrote a wonderful piece recently to demonstrate the true significance of an MVP: https://www.forbes.com/sites/steveblank/2013/07/22/an-mvp-is-not-a-cheaper-product-its-about-smart-learning/#6956f1886f0c

    In it, he mentions how a startup looking to build a product for flying drones over fields to help farmers cultivate their fields in a smarter and efficient way got their hypothesis right but the execution wrong. They wanted to test that intelligent data on agriculture and the corresponding practices would be of value to farmers, but to do so they did not have to actually fly drones and invest in equipment up front. By sharing already available satellite data with farmers and seeing how valuable that was in agriculture, the startup could gauge the success of their idea.

    The main point is the you're building an MVP to learn more and validate rather than sell straight away. As to what is the best way to create and test your MVP, I think you should check out this article on the connection between visual feedback and minimum viable products: https://blog.zipboard.co/building-better-mvps-with-visual-feedback-ed9d8a4c3f67

  • FH

    Feras Hirzalla

    2 months ago #

    I think the key is to not bite off more than you can chew when you're about to build your MVP. Say you've estimated your MVP at 100 hours, don't try to squeeze in 100 hours of functionality - instead figure out what your core product is, and strip out any unnecessary features until you have a solid MVP with a core proposition that you can market, and get done in under 100 hours.

    I'm part of a development shop where we routinely remove functionality that shouldn't be part of an MVP and sometimes face a backlash. As soon as you launch, you're going to discover that you'll want to build up a different set of functionality based on what your initial customers are asking for.

    Your best approach is to probably run your MVP by a seasoned developer and understand exactly what the core functionality is, then postpone any non-MVP related tasks until you start getting customers. You should NEVER be cutting corners on your core proposition. If you sense that you're cutting corners, it's a signal that you've taken on too much functionality for an MVP.

Join over 70,000 growth pros from companies like Uber, Pinterest & Twitter

Get Weekly Top Posts
High five! You’re in.
SHARE
12
12