My Philosophy of Product Building (Part II)

4. Shaping the idea into a simple v1

It’s relatively easy to generate good high-level ideas, but shaping those ideas into a good first version—deciding exactly what to build and how, and what not to build—is much more difficult. It’s where things go wrong most often.

The most common mistake is succumbing to the temptation to add too much complexity. People want their ideas to seem important and valuable, so they think it’s better to add a lot of features. I am here to tell you that this is a destructive impulse. Unlike school assignments or intern projects, you get no points for seeming like you worked hard. Nobody cares. The only thing that matters is whether a user A) finds out about it, B) immediately understands why it’s useful, and C) intuitively understands how to use it. Complexity is a drag on each of these. People don’t tell friends or coworkers about complex products that are hard to understand. They certainly don’t sign up for them. And if a lengthy explanation is required to learn to use the product, hardly anyone will bother.

So how can we achieve simplicity? You may hear that simplicity takes a lot of complex effort, but that’s not necessarily true. You don’t have to design 100 variations to arrive at the perfectly simple thing. Often, I scope a v1 in a way that feels obvious to me, and it works.

I iterate along the way, but only in response to real problems, rather than imagined ones. My process goes something like this: make a simple v1 without overthinking it, use it and show it to some test users, see what problems arise, then fix them. It’s so much faster and more effective than filling a notebook with 100 variations. The exception to this rule is at big companies, where it can make sense to do this if you need to convince skeptical execs and managers of the thoroughness of your thought process. But when it’s just you and your users, there’s no need to create a Potemkin village of middling ideas.

With Lex I knew there would be two main screens to start: the list of documents and the document editor. I knew I wanted to have one or two AI features that would be useful and make for a cool demo. I knew I wanted it to work on mobile as well as desktop. And I knew I wanted it to feel like a Google Doc, but simpler and faster.

I can’t tell you exactly why I thought those features were most important while others (like templates or custom fonts) weren’t. It comes down to intuition, which is usually sufficient when you’re building a product for yourself. If you’re building for others, you’ll need to spend more time and energy doing user research, and you shouldn’t expect to be able to achieve the same depth of fit.

Products are like works of art, in that every single detail matters and either support or detracts from the overall gestalt. If you’re not designing for yourself, it’s going to be hard to compete on equal terms with someone who is—especially if you’re operating in a market where decisions are more likely to be made based on feelings than lists of features. It’s one reason why I almost exclusively work on things that I want to use myself. (The other reason is that I find it more fun and motivating to build things I think are cool than to solve someone else’s problems.)

I don’t spend a lot of time documenting what the v1 should be. I write notes explaining the motivation and philosophy behind the product, and to brainstorm ideas and save them for later, but I don’t create a final “spec” or exhaustive plan of what the v1 should do.

Software is a living system that should continuously evolve. Sure, we can stick a flag at a moment in the timeline and call it a “ready-to-launch” v1, but that’s a somewhat arbitrary point in time. The product should be usable before that point, and it should keep evolving long after. What’s more important is to cultivate an organic vision that lives inside your head. Writing documents is a means to this end, and it’s much more effective when you see it as such. The tao that can be named is not the eternal Tao. The name that can be spoken is not the eternal Name. And the product vision that can be written down is not the true product vision.

One corollary is that you should get started coding as soon as you can. Don’t wait until you have it all figured out.

5. Programming

Your most important decision in this step is whether your priority is building cool products or learning cool engineering techniques. It’s alright to be interested in both, but it helps if you have a gut feeling about which is more important to you. I love writing code, but I will always care about product more. Code is a means to an end.

If the same is true for you, it’s important to filter any engineering advice you receive with one question: does the person giving it to me understand what my goals are? Most engineering advice is still going to generally be good, but you should take it with a grain of salt, because most of the time it’s targeted at people who write code professionally inside large organizations. Most of the principles they live by will also be useful to you, but not all of them.

For example, if your goal is to have an engineering career working at tech companies, it helps to stay on top of new languages and frameworks. But if you just want to build a cool product, stick with what you know.

Someone who does this really well—perhaps to a fault—is Pieter Levels, who’s built a collection of valuable businesses (Nomad List, Remote OK, and now Avatar AI and Interior AI) by using the most basic technology possible and focusing purely on shipping.