My Philosophy of Product Building

As a person progresses in their career they often develop one or two “signature moves”—ways of solving problems in specific situations that produce outstanding results.

For Tony Hawk it was the 900º spin.

For Rich Barton—founder of Zillow, Expedia, and Glassdoor—the signature move is “building Data Content Loops to disintermediate incumbents and dominate Search. And then using this traction to own demand in their industries” (according to Kevin Kwok).

For Reese Witherspoon the signature move is to play a strong yet vulnerable protagonist going through a transformative moment in life.

If I had to name my signature move at this point in my career, it would probably be the way I approach building new software products. There’s a lot that I’m not good at, but I’m pretty good at going from zero to one.

Quick braggy bio: Nine years ago, I designed and programmed the first version of Product Hunt. A year before that, I built a fun way to learn to code called Scratchpad that got acquired by General Assembly, and then built another product for GA that still exists today and has been used by hundreds of thousands of people, called Dash. Since then I’ve worked on lots of products: some big successes (Substack), others more low-key successes but still cool in their own way (Chompers, an Alexa skill from Gimlet Media that helps kids brush their teeth, and won a Cannes Lion), and some that never really broke out but a couple thousand people love and still use every week (Wordie Bird, a word game). And last month I launched probably the best v1 product I ever built: Lex.

My focus now is to get really good at going from 1 to 100 and beyond, but before I do, I wanted to stop and appreciate the 0 to 1 game and write up everything I learned about how to play it.

There are nine components to 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

There is a lot to cover, so this is the first of a two-part series. This part will start with a high-level overview of how they all fit together, then delve into the first three components. Next week’s follow-up will cover the rest.

Let’s dive in.

How (and why) I build products

At some point in college I learned about internet startups by reading Getting Real from Basecamp, and Paul Graham’s essays. I was enthralled. Sure, there was the possibility of making money, but more importantly, building software felt like the perfect creative medium for me. If you’re attracted to the idea of building things by hand that people might love and find useful, and doing so with a sense of craft and love, then my way of doing things might be a good fit for you.

It took me a while to realize this, but most people in software don’t care inherently about software. They don’t see it as a medium of creative expression. Instead, it’s a means to some other end, like building a valuable business or earning a lucrative salary. There’s nothing wrong with that, but if that’s your vibe, my approach probably won’t work for you. It’s an extremely hands-on, DIY way of product building. This method has advantages and disadvantages, but it’s only worth it if you find it intrinsically satisfying to build things yourself.

Here’s the hard part: to do it my way, you have to learn how to code. There is no avoiding this step.

I tried for years to avoid it but eventually gave in—and it was the best career decision I ever made. I was not a computer science major in college, and I thought it was “too late” for me to become a programmer. Plus, I wasn’t sure if I even wanted to be one. I hated my math and formal logic classes, and staring at a screen of code was intimidating. The only thing that mattered to me was building cool software that people could use. Wasn’t there some way of avoiding code? I would start to learn a bit but then get easily discouraged every time I hit a rough patch or got stuck; I was worried I was wasting my time, and it would take too long for me to ever be a “real” programmer.

The truth is that programming involves a lot of complexity, and it’s impossible to learn overnight, but it’s a lot of fun, too. I get a special thrill from dreaming up ideas and making them come to life. Nothing—not even writing—is satisfying in quite the same way. When you can combine the idea of what you want to build with the ability to design and build it in the same brain, special things can happen. I got enough of a taste of this learning on my own in college to keep going with it, and in what feels like a blink of an eye, I’m actually a fairly experienced software engineer now.

Even though I’ve been coding since college, I held myself back for a long time because I wasn’t willing to embrace the identity of a “programmer.” I thought I didn’t deserve it. I would always say, “I’m not a real engineer, but…” I avoided the label because I thought it would put me in a box and crowd out other labels that felt more essential to who I am: entrepreneur, product person, etc. Now I realize it doesn’t matter what I “am.” What matters is what I do. And if something is useful or necessary to accomplishing my goals, and I’m interested in it, it’s good to learn to do it and not hold myself back by worrying about what it means for my identity.