Totally. Though I took stock of all my projects in the last 15 years, and almost every single one of the projects that I launched for the sake of shipping quickly failed. The ones that got traction are ones that I spent a lot more time(and emotion) towards.
This is something I struggle with thinking about too as the founding designer, and generally most quality-driven person, at our company. The simplified version of the spectrum as I see it is:
1. Shipping quickly with a shitty solution.
2. Shipping slightly slower with a polished solution.
3. Shipping very slowly because minor details took over.
The frustrating thing is I can generally feel the difference between #1 and #2 myself, but I'm not sure how to distinguish between #1 and #2 enough to argue my point to the rest of the team. Instead I usually have to result in vague responses about quality and reputation and such, or just go into the UI or codebase and tweak things myself.
But on the flip side, I also know that I bring up issues that, at first glance, I think are must-haves for quality, but really aren't. Instead the scope should be decreased not to include the feature at all. But my credibility each time I bring up something like that is diminished, rightfully so.
I often struggle with this when giving friends advice about their MVPs too. Everyone has gotten so wrapped up in MVPs and they equate the MVP to throwing quality out the door, but MVPs are much more about throwing away scope in my opinion. I actually think quality can actually break or break an MVP, but it's hard to convey this properly to non-design-focused founders because they might not see the difference between certain purely-aesthetically-driven decisions and the more general and important product-quality driven decisions.
We built the Segment.io MVP in two days, but we did it by cutting scope, not quality. We didn't have a settings page, a way to delete accounts, a way to reset passwords, a way to invite teammates, anything that seems like it's necessary to work on a project. We literally had:
1. A junky home page.
2. A login page that literally just two inputs and a submit button.
3. A signup page that was similar.
4. *The* product page that was a glorified settings form.
Instead we spent that time making sure the core form in the product was as helpful and simple to understand as we could make it. There was an animation that we added when turning an integration on that was completely unnecessary from an MVP standpoint, but it was one of those quality things that made it super obvious how the form worked, and added a touch of polish to the product.
Obviously this is completely anecdotal, so I have no idea what would have happened had we went the other way, but I do really think that some of the things we spent time getting right had an impact on our user's perceived quality of the launch. I'm not sure how successful we would have been had we not done that.
There's a really good article[1] by Ryan Singer (from 37signals) on this topic that argues that it basically boils down to scope. And we've found this to be really true for ourselves while working on Segment.io. Basically you go with the designer's (or close to it) opinion on what quality should be, and the way you reduce time taken to ship a feature is to drastically cut scope. It sounds way easier than it is, but I think finding ways to cut scope is easily one of the top 5 things I've learned since starting the company.
And Ryan also has another good article[2] about how to cut down on design time by focusing on capability instead of styling. I think he's right there, style in the early stages (while important from a first experience point of view for your users) only need to be "good" not "great". Basically most designers can pretty easily decide on a style pretty quickly for an MVP and then execute on it, whether it's amazing or nt. But capability should be paid more attention to because that is where things like "did this solve my problem?", "do I want to share this with my friends?", etc. come into play more.
I don't know if that helps at all, but I'd definitely love to read more people talking about this.
the way you reduce time taken to ship a feature is to drastically cut scope
That's such a great way of putting it! I think what makes this difficult is that it is hard to come up with a formula - so much of it is a "feel" that you develop over years of doing it.
Also, in tech we often account for the development time but not as much the time for everything else. Even though segment.io took you two days to build the MVP, I have a feeling it took you many, many more "passive" hours of thinking about the problem(may be even before you decided to turn it into a startup). When you take that into account the time you spent experiencing the problem and thinking through the various solutions, the MVP took you a lot more than 2 days to build.
One of my most successful projects took me barely a day to code. But it was a painpoint that I experienced and thought about pretty much every week of my undergrad. But for some reason, I did not feel I was in a position to attack the problem until a very particular moment. I'd like to think that if I attacked the problem the very first time I had the inkling of the pain, my solution may have been very different and less likely to gain traction.
That's a really good point about passive time before the actual building. We had definitely been thinking about the problem for a while, and analytics.js[1] had already existed for at least 6 months in its current form and another 6 months in a prior one.
It just takes a while to start developing solid, bigger-picture ideas about a problem. This is also why it's hard to realize the negatives of "pivoting" all the time, since we take for granted how much we've already invested in groking a particular space.
The same thing happened recently while hacking on Myth[2]. To everyone on the team it felt like building the entire thing only took a couple days, but really I had been experimenting with a similar idea[3] for multiple months, and it was already being used in production for our own CSS. The piece that took a few short days was just figuring our the best way to design the landing page—much less scope that conceiving the entire idea.
It's really hard to quantify that kind of time investment, and even harder to explain that to friends who think that everyone is launching fully-formed, successful MVPs in a single weekend without much thought. It definitely seems like something that can only be learned through experience. It's just an earlier stage version of the classic problem of founders always thinking that successful startups spring out of nowhere, when really the multiple years of living in a cramped room and almost killing each other is just shielded from view.
At least it makes things more defensible :)
Random other thought: I often catch myself bundling up tons of logic into a "first commit" and wishing that that wasn't a common practice, so that we could learn about how the beginnings of codebases are iterated on.
> 2. A login page that literally just two inputs and a submit button.
> 3. A signup page that was similar.
I don't think I'd be amiss in pointing out the login page of the site we're using right now, which has one page with both of those forms in exactly that format. :)
