How MVPs Can Avoid Being Maximally Crappy

The right way to build a product is the MVP approach: cut all possible corners, launch something half-assed, figure out where the biggest problem is, improve it, and iterate.

This is the right way, but it often results in products that are as crappy as the developers can get away with. Or for which there’s no data to prove that something is bad. Especially when small but repeated annoyances with the product add up to make the user conclude it’s a crappy product. Each of these flies under the radar because it’s too small to measure. Or because the team doesn’t have bandwidth to measure every tiny thing.

As an analogy, if a typical startup builds a car, the steering wheel won’t have any padding; it will be exposed steel because there’s no data to prove otherwise. There won’t be any floor mats because where’s the data to say that X% of users are abandonding the product for this reason?

For these reasons, MVPs end up being maximally crappy.

But we can adopt a different approach, which is to build for one user, the founder. Only when that user approves the product does the team start focusing on other users.

Separating out the “team member” and “user” perspective is hard. All the more so when the team member is the founder. The temptation to believe something because you need it to be true is great.

One tool I’ve found helpful is to create a separate Google Doc What I Want As a User. Putting things in writing clarifies our thoughts. When I write this doc, I ignore the team aspect. If as a user I want something, I don’t think about technical feasibility or the team’s perspective, like “But that will take two months to build!” I stick with the user’s perspective and always keep coming back to the question, “If I wasn’t working here, would I use this app the way it is today?” You can’t think in two mindsets at once any more than you can drive a car in both forward and reverse at once. So stick with one mindset at once.

The What I Want As a User document has some must-haves, things without which I wouldn’t use the product. These must-haves could be specific features. Or philosophical aspects like “When I use a camera app, I want to make creative decisions, not technical ones.” Or UX goals like “Don’t ask me questions for which I don’t know the answer.” Or performance goals like “If it doesn’t start recoridng in 2s, I wouldn’t use it.” I capture all of these functional and non-functional requirements in the doc. Conversely, the doc mentions some features I wouldn’t use even if they were there.

Nice-to-haves are explicitly identified and put in a footnote, with a clarification that things in footnotes are not requirements. You won’t be able to identify nice-to-haves when writing the doc, only when revising it. So multiple iterations are necessary, over days and weeks. I always stop and ask myself, “Yes, this is how it should be, but would I use the product if it didn’t do this?” If the answer is yes, it’s a nice-to-have. All that matters is whether the user uses it or not. Every product has some friction, and considering that makes you lose track of what’s important. Our minds have only a limited ability to handle multiple perspectives at once. So ignore nice-to-haves.

I revise the document over days and weeks, and we then have a team meeting to discuss it. I tell my colleagues:

In this meeting, I’m the user, not the founder. One of you take the lead. Pretend you’re the founder, and that I’m someone who just walked in off the road. Imagine you’re an outsourcing company and I’ve hired you to build this app for me. Don’t ask me questions like “How long will what you’re asking take to implement?” because that’s a question for a founder, and I’m not a founder, in this meeting. You can ask questions to clarify, but you can’t contradict me. If I say that I want a camera app that records a timelapse, you can’t say, “But timelapses take too long to record”.

At the end of the meeting, my team told me that they have a much better idea of what we’re building and why than before, despite having worked for more than a quarter with me.

This process of separating out the “user” and “founder” role requires practice and mental discpline and needs to be done in the right way, but it can be done.

One unexpected benefit of building for me was that we were more confident about making decisions. Earlier we were flip-flopping because we didn’t have conviction about decisions. If a few users insisted on something, for example, we’d go down that path, but then waver a month or two down the line. Under such conditions, progress slows down.

Be confident about where you’re going. Once you get there, if you don’t like it, you can go elsewhere, but you can’t keep doubting yourself every step of the way.

This is why scratching your own itch is so important [1]. It’s much easier to build for a user in the room than a bunch of hypothetical vaguely-defined users who exist in theory.

To be clear, I’m not advocating that you delay launching the product till it’s good. You should launch it before it’s ready. And then iterate. But the iterations should first be driven by what you as a user want and only when you’re satisfied should you think about other users.

[1] It also gives you at least some level of validation that you’re solving a real problem.

Scratching your own itch doesn’t work for all kinds of startups, of course. For example, it doesn’t work for enterprise startups.