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.

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: