Thoughts on Aesthetic MVPs?

[flipflop2234]

I wanted to push back on the sentiment I’ve heard expressed by YC folk. I’m not necessarily married to this opinion and am just thinking out loud, and would be curious as to what everyone thinks. Michael Seibel explained once in a video that when it comes to MVPs, you should 'launch quickly and iterate. Get a product into the hands of our customers and then learn whether it helps them or doesn't, and then iterate it and improve it over time.' The sentiment is echoed in the YC ecosystem, especially when responding to concerns about launching a less-than-clean MVP. When I say 'less-than-clean,' I don’t necessarily mean unusable or lacking MVP-esque features. I mean one that perhaps has a few small bugs, or perhaps isn’t very visually pleasing, or even just plain hideous. I understand that the core philosophy behind launching an MVP is to validate a business idea with the minimum amount of effort and resources—in essence, an MVP is supposed to provide data, and the data is supposed to inform the decision on whether or not to iterate.

Here is where I am pushing back. The assumption is that a customer will want your product so badly that they will concede a less-than-clean MVP. However, personally, I would not use one of these no matter how bad my need for something was (unless I’m literally on the verge of dying, and if you’re solving THAT problem, props to you). The logic kind of goes, 'If your customer is on fire, give them water (or whatever),' and their need will outweigh their reservations or biases. But my whole thing is, if that water is irremediably putrid, some people won’t use it including me. To me, that’s where the logic breaks because we are supposed to use our MVP data to iterate—I feel as though a less-than-clean MVP will create skewed insights. In my case, I could very well want the product, even need it, but could be just turned off by the MVP. In this case, the founders should not iterate the whole idea; they should clean up their MVP. Maybe the idea could use some iteration, but wouldn't it make sense to capture the low hanging fruit first—certainly feels like it'd be cheaper and less time-consuming than iterating? I could be wrong, but I feel as though I can’t be the only one who is pretty unforgiving of less-than-clean MVPs. Here is what I want to know: Would you use (my definition of) a 'less-than-clean' MVP? Would you use an even lesser-than-clean MVP wrought with bugs if you really needed the product? What is the minimal threshold for how aesthetically pleasing an MVP should be? Again, not married to the opinion, just thinking out loud—no need to totally destroy me lol

 

[grounded]

@flipflop2234 You’d likely not be a first user then, and that’s totally fine. And I do agree that for consumer products, it should have a good amount of polish. This advice is likely more geared towards B2B businesses — where it’s incredibly common for companies to trial very barebones tools (like MVPs) and work very closely with the startup founders to solve their needs. A lot of consulting work is also essentially that. These early users understand that it’s not pretty, but if it’s a real problem for them, interests are aligned in trying to fix it.

Another way I like to think about it is — say you’re running a company, and you need to build an internal tool to do some task. You don’t wait until you have a polished product to use it, you just build the minimum required thing that does exactly that. This is super common on many software teams - we had tons of tools and scripts at ours that looked like shit but it worked well enough, and many of those could be starts to b2b products. Over time as your scope grows, whatever tool you build will need to be more fleshed out as it gets more complicated. But you don’t get to that part without the iteration. Software startups especially are essentially this, except their users aren’t limited to just themselves but other companies as well.

And one of the worst things a resource-restrained startup can do is waste all your time over engineering a product only to find that no one actually wants to use it.

 

[sen_]

@flipflop2234 I may be incorrectly reading into your post. But I wonder whether you're making a strawman argument on both sides.

The prevailing wisdom is correct. You should get a viable solution into the hands of first-users early.

On the other extreme there are some solutions which require certain and prolonged ingenuity to 'wrap-up' into an mvp. In those cases, releasing early wouldn't work because of said required ingenuity and creative vision.

Perhaps "clean" isn't the right metric. To me it's more a case of risk management:

- for the VC operating at masse, they can afford to play an outliers game; disregard anything that doesn't fit cleanly into that model

- for us builders believing in our ingenuity and vision it's a personal faith journey on whether you can persevere the wilderness of building an ingenius m.v.p

 

[flipflop2234]

@sen_

I may be incorrectly reading into your post. But I wonder whether you're making a strawman argument on both sides.

The prevailing wisdom is correct. You should get a viable solution into the hands of first-users early.

On the other extreme there are some solutions which require certain and prolonged ingenuity to 'wrap-up' into an mvp. In those cases, releasing early wouldn't work because of said required ingenuity and creative vision.

Perhaps "clean" isn't the right metric. To me it's more a case of risk management:

- for the VC operating at masse, they can afford to play an outliers game; disregard anything that doesn't fit cleanly into that model

- for us builders believing in our ingenuity and vision it's a personal faith journey on whether you can persevere the wilderness of building an ingenius m.v.p

Very fair--I appreciate the nuance!

 

[growingbygrace]

@flipflop2234 Michael Seibel by saying "launch quickly and iterate" talks about some startups that can build MVPs and can test them fast in the market, and survive (mainly in Silicon Valley, or NYC, or places like that)

Indeed, YC and other VCs "traditionally" are looking for startups that have "tractions" (indeed, have survived)

But you don't need to launch your startup as MVP to realize that it will be successful or not?

You can examine your idea (as a problem and its solution(s)) or hypothesis directly with a mock up

https://www.reddit.com/r/startups/comments/1aidumr/comment/koufkxp

 

[warriordocjensen]

@flipflop2234 IMHO YCs MVP approach is mostly valid if company wants to become a unicorn. Build fast, iterate, pivot, find PMF and let's go to insane growth.

A more regular scenario is that entrepreneurs will build an MVP for a while, release it more or less polished, then try to iterate slowly. Most of them will fail since MVP already cost too much money and time. Some of them will succeed but won't be a unicorn because this approach is simply too slow. Fraction might become a unicorn company.

Remember that YC is all about the scale. It's not bad to be a profitable company with some small % of your growth. But that's not what YCs methodology is.

P.S. I've been building MVPs for the last decade, mistakes are always the same and patterns are somewhat clear. YCs approach works. It is just not for everyone to handle.

 

[becknps]

@flipflop2234

Would you use an even lesser-than-clean MVP wrought with bugs if you really needed the product?

I wouldn't, and Im a passionate first user. I love beta testing stuff, for me the bar is just so high, and there's so much stuff out there, I'll try something once but if it isn't at least a little better than what I'm currently using I'll never use it again.

It's so disappointing when founders can't execute. I've seen it so many times, not only that but products only tend to keep getting worse with time.

 

[revena]

@flipflop2234 That's the hard part of innovation. You learn all the rules and then you find yourself in situation where rules don't apply. If you're doing something where all the startup school rules apply perfectly, your probably not innovating enough.