My Philosophy of Product Building (Part III)

This is the final edition in a three-part series about the way I approach building software products.  If you’re new here and curious about how to build new software products that users love, start by reading parts I and II.

---

Congrats! You’ve built a first version of a software product. Now what?

What comes next—showing it to people, learning from their reactions, refining, and launching—can seem downright mystical compared to building. I’ve seen it go wrong many times, and I’ve gone wrong myself. Thankfully, there are some simple techniques that make the process much easier, both logistically and emotionally.

That’s what this final edition about my philosophy of product building is all about. This week I’ll cover the last three steps of my approach:

1. Coming up with ideas
2. Deciding to pounce
3. Creating the time and space to build
4. Shaping the idea into a simple v1
5. Programming
6. Design
7. Getting and interpreting feedback
8. Positioning
9. Launching

Let’s dive in.

7. Getting and interpreting feedback

Before you publicly launch your product, it’s critical to show it to early users to get feedback. You’re looking to answer two questions:

1. Once someone has used and understands the product, what about the core value proposition resonates (if anything), and why?
2. What stands in the way of people getting to that point?

In other words, you’re looking for the product’s engine and drag. (I use the same framework to evaluate essays, too.) The engine is the reason anyone shows up or cares in the first place, and drag is all the little problems and confusing parts that get in people’s way.

When you’re new at building products, everything you build is going to have drag. The product will be buggy, confusing, and poorly designed. The most common mistake beginners make is to assume that when people don’t come back, it’s because their core product engine isn’t any good. So they pivot to a new idea or give up. Resist the urge to do this. It’s better to keep going for a while and try to reduce the drag.

In practice, this looks like:

• Fixing bugs
• Making the app simpler
• Refining the visual design
• Using simpler language
• Making the app faster
• Helping users solve the “cold start” problem

Even if your product’s engine really is bad, it’s still a good idea for newbie product builders to not pivot too soon, because product building is a skill that requires deliberate practice, just like any other. It’s not a waste of time to spend weeks or months refining something that nobody will end up using, because you’re accumulating valuable skills in the process. And when a product has a lot of drag, it’s hard to know if the engine is any good or not.

This approach runs contrary to the gospel of the “lean startup,” which states that you should test ideas as cheaply as possible and pivot quickly when it seems like people don’t like them. It’s perhaps rational to approach product building this way if you’re only optimizing for the current idea. But my philosophy is more concerned about cultivating skills you can use over and over again, and it recognizes the fact that beginners almost by definition can’t create products with a level of polish necessary to get anyone interested. Overcoming this hurdle, rather than finding product-market fit with one idea, is the central goal when you’re early in your journey.

Once you do have a v1, and you show it to users, how can you interpret the feedback?

Don’t get discouraged if some people don’t get excited by your product. There are lots of reasons why some won’t be interested, so any single user’s reaction is just noise. It’s also okay if most people you show your product to don’t care. The only thing that matters is that you are able to find at least a couple of people who genuinely LOVE what you’ve made. (I used all caps there because the most common mistake is to fool yourself into thinking a user loves a product, when they really just like it.)

How can you tell the difference? When a user loves something, they will come back to it frequently. They will tell friends about it. When you watch them use it for the first time, there will be a moment (ideally within the first few minutes) where they get a twinkle in their eyes and say something like, “Holy cow!” For me, watching this happen is one of the best feelings in the world. Once you experience it for the first time, your “bar” for what counts as a good reaction will be forever changed, and you will begin to hold everything you make from there on out to the same standard. Anything less isn’t ready yet.

When a user just likes a product, they will be polite. They’ll congratulate you. They’ll look for something positive to say about the product. But it will be the same tone of voice they use when they’re looking at a friend’s wedding photos. The overall vibe will be “good for you” rather than “good for me.” Every single time you build something and show it to anyone, some people will react this way. Again, it’s nothing to be too concerned about. What’s more important is to keep showing it to people until you get a genuine “holy cow” reaction, and try to understand why, until you can replicate it.

Until that point, it’s best not to do any costly or official big “launch.” You’re not ready yet. Instead, recruit your first users manually. Lenny Rachitsky has compiled two helpful guides on this topic.

There’s no secret to this step. It’s just a matter of sweating the details until the thing becomes amazing. For some types of products this can happen quickly, while others require a lot more iteration and upfront investment. When you’re new to building, it helps to work on more tractable problems, and save the bigger swings for when you have more experience.

8. Positioning

As you’re showing the product to early users, you may notice that the way you explain it to a person affects their experience of it. When people encounter new products, they put it in a category of similar products, and can generally remember maybe one thing that makes it different. The way you explain your product to users has to fit into concepts they already have in their head. How it fits determines how memorable or intuitive it is. Therefore, it’s just as important to iterate your product’s positioning as it is to iterate your product itself. 

I wrote a whole post on product positioning a few months ago, but here is the short version:

1. Start wide open. Don’t explain too much to early users—try to let them figure it out themselves. Be open to surprise. Perhaps people like it for a different reason than you expect, or a different type of person uses it than you thought would. Don’t cling too tightly to your original vision.
2. Identify the bright spots. As time goes on you’ll start to notice patterns of who likes it and why. Hone in on those people. Ask them to explain what they like about the product, then explain it using those words and phrases to the next set of people. Ideally a higher percentage “just get it” right off the bat.
3. Anticipate where each bright spot leads. You might notice multiple archetypes of people who like your product for slightly different reasons. Sometimes your product can serve several use cases equally, but more often you’ll have to prioritize one over another. It’s tough to make these choices, but it helps when you develop an intuition for where the different paths lead. The easiest lens through which to evaluate each option is market size, but it’s important to take into account power and defensibility, too.
4. Choose a path. Don’t waffle.
5. Conform everything around that choice. Re-evaluate every feature of your product, every line of copy, and every design detail through the lens of the new positioning. Don’t be afraid to let go of big features you spent a lot of time working on—you can always bring them back. Better to make a bet and follow through rather than stay in the mushy middle.

With Lex, the original vision was not centered on AI as much as it is now. I was more interested in creating a better writing experience than Google Docs. But when I showed it to early users, the feedback was clear that the AI was the most useful part. So when I launched I made the entire story about that. It was hard to let go of a story I was excited about, but ultimately it was for the best. People can discover the rest of the value as they get deeper into Lex.

9. Launching

Once you’ve built a product and a system for recruiting a steady stream of new users, launching is a fairly low-stakes activity. You’re already winning!

As Sun Tzu said in The Art of War, “Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.” (It’s cheesy but true.)

People build up a launch in their heads and worry they’re not doing it right if they don’t get press or go viral on Twitter. But the majority of successful businesses start from humble origins and don’t make a splash on their first day. Conversely, many products that have big launches flame out. 

The more products I launch, the more convinced I am that the tactics you use to launch your v1 don’t matter that much. I’ve done the press build-up, and I’ve casually tweeted out a link. Either way, it doesn’t seem to make that big of a difference—the main thing that matters is how obviously cool the thing is that I’m launching.

The word “obviously” in that last sentence is important. Sometimes a product is genuinely cool, but it takes longer to understand. That doesn’t mean it won’t work, but it does mean that it’s less likely to explode on launch day. A muted reaction on Twitter is fine if you’re building an enterprise SaaS tool; B2B products rarely go viral. But if you’re building for consumers, it’s a problem.

My best piece of advice for launching is to write a piece explaining your vision. It shouldn’t be the main thing you direct people to on launch day—that would be the product itself—but it’s nice to plant a flag in the ground and say, “This is what we’re building.” The reason to do so has  less to do with attracting a lot of users and more with communicating deeply with the smaller group of people who are interested. It’s also a good exercise for you to do even if nobody else reads it.

---

If I had to leave you with one closing thought, it would be to go with what feels right to you. Every time in my career that I’ve listened to how things “normally” should be over what I think really could be, I’ve regretted it. Even if you make mistakes along the way, going with your gut is the best way to learn. And often you’ll discover things that nobody else has been able to, because it doesn’t seem possible.

Most of all: have fun!