My Philosophy of Product Building
Divinations My Philosophy of Product Building Mastering the art of 0 to 1
by Nathan Baschez
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:
Coming up with ideas
Deciding to pounce
Creating the time and space to build
Shaping the idea into a simple v1
Programming
Design
Getting and interpreting feedback
Positioning
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.
So, if you’re in love with software and you’re excited by the idea of making it yourself by hand, here’s the short version of how I build new products:
When I feel aimless, I tend to think up lots of software ideas. Most of them are bad, but when I get excited enough, I pounce. I create the time and space to hyper-focus for a short span of time, and shape the idea into a form that is simple yet polished and has a new element that feels genuinely exciting. I design and code it myself, or with one or two other people. I then show it to people to use and see what they think. Crucially, I watch people use it in person or via screenshare. The most important thing is that some people have a visceral, emotional reaction. I used to get discouraged when they get a flat response, but eventually learned it’s totally fine and means nothing if some people are unenthusiastic. Once I understand what’s resonating with the people who like it, I focus on that and position the whole product message around that thing. Then I make a short but sweet launch video or essay, and post it to Twitter and anywhere else I can.
That’s it! That’s the move. Now let’s break it down step by step.
- Coming up with ideas
The best way to come up with ideas for software is to learn how to code. This may seem counter-intuitive, but it’s important. People don’t tend to come up with ideas for things they can’t do. When’s the last time you thought up a new type of airplane or nuclear reactor? I’m guessing you haven’t. Once you learn to use a set of creative tools, if you find it fun to use then you tend to think up reasons to pick up the tools again.
It’s important to have a low bar for what is worth building when you’re just getting started. If an idea is even a little bit interesting to you, go ahead and spend a Saturday working on it rather than studying “how to code” in the abstract.
The way I learned to code is by wanting to build specific ideas I had, and doing everything I could to find the most direct path to making it real. There were some essential resources to my development (Rails Tutorial, Eloquent Javascript, Learn Ruby The Hard Way, Head First Rails), but I never was able to stick with courses or tutorials for very long. If you can’t, either, don’t assume you aren’t meant to learn to code. Instead, just try to start building your idea and use Google when you get stuck.
It’s a mistake to focus too much on coming up with good ideas when you’re getting started. Just try to find ideas you think are cool. It doesn’t matter if it’s a good business or if anyone else thinks it’s cool—you’re just jamming and learning your craft.
The most important thing is to protect your enthusiasm. If you’re enthusiastic, you’ll keep building and generating new ideas. At times you’ll feel naïve around people who don’t understand what you’re doing. They’ll see your “little” project and give you unhelpful feedback on the assumption that you’re trying to raise a series A from Sequoia. For example, they might encourage you to stop building the product yourself and recruit a team. This is good advice if you want to make one valuable thing right now, but it’s bad advice if your goal is to build skills that will enable you to make many valuable things in the future.
Once you become a skilled builder, you’ll want to graduate from toy ideas to slightly more serious ones. And at that point you’ll need to be more selective about where you invest your energy. 2. Deciding to pounce
When I first started building products, all I cared about was whether it was cool, but as I get older the decision to pounce becomes more about whether it’s cool—and does it serve my goals.
There are four distinct yet equally important questions to ask yourself:
How likely is it to work?
What will it take to make it work?
If it works, what kind of thing will it become?
Is that the kind of thing I want to be doing?
Much like learning to code, there are unfortunately no shortcuts to improving one’s judgment at answering these questions accurately. You simply have to build a lot of things and see how they turn out, and closely watch what happens to things that other people build. It also helps to understand general patterns and principles of strategy, like what I write about here: wedges, power, positioning, trade-offs, etc.
It’s more important to develop your intuition by trying your own ideas than it is to listen to others. If you follow someone else’s advice without really understanding it, you don’t learn anything. Better to make a mistake and learn from it than to rob yourself of the lesson. So go with your gut—not because your gut is a sacred source of truth, but because it’s the best way to learn.
Early in my career I took a lot of risks. I quit my job and almost ran out of cash a few times—and I’m glad I did. It taught me how to live frugally. It humbled me, literally: it made me realize my ideas weren’t that special and taught me just how hard it is to build a business.
As I get older, especially now that I have a kid, I’m not going to take that level of risk anymore. But I’m glad I did, because it taught me how to be “OK” outside of my comfort zone.
We live in a time when the main form of financial risk-taking you hear about is buying speculative assets (crypto or otherwise). I would encourage you to speculate less with assets that other people control, where all you can do is sit on your hands as you watch a price go up or down, and instead bet on yourself. It’s a much more fun use of capital in my experience. 3. Creating the time and space to build
If you’re young or don’t have many demands upon your time, it’s a huge advantage, and you should exploit it to the fullest. You can have a full-time job, build side projects every weekend, and still have time to hang out with friends and relax. This is a rare and valuable thing.
But even if your time is a bit more constrained like mine is these days, there are ways to create the time and space you need to build. If you have a significant other or spouse, it’s important to get their buy-in. Tell them about the idea, why you’re excited about it, and why you’d like to spend extra time working on it—but also don’t want to leave them high and dry. Brainstorm ways to create the space together.
You can also take advantage of special occasions, like holidays, to get extra stuff done. This is how I built the first version of Product Hunt: I stayed up until 2 or 3 a.m. every night at my parents’ house in Arkansas when I was home for Thanksgiving break.
This is how I work: I tend to get hyper-focused on one thing. When I do, I have what feels like unlimited energy to work on that thing at the exclusion of everything else. But even if you’re not like me, I think it helps to have a “sprint” mentality when building the first version of a new product. I have a lot of friends who like to tinker away at things, but they often never end up shipping. The idea stays in the “tinker” zone. To build something you can launch and get feedback on, it’s probably going to require more concentrated effort than one “sacred hour” every morning.
But besides creating time to focus, the other key component of building new products is to have a clear conception of what you want to build. When you know what you’re aiming for, it’s much easier to move quickly and with urgency, and get to a point where you can launch.
Next week I’ll continue next week with part 2, where I’ll go over the remaining components of my philosophy:
Shaping the idea into a simple v1
Programming
Design
Getting and interpreting feedback
Positioning
Launching
I’d also love to answer any questions you have in next week’s post. To leave a question, hit the feedback button below and let me know what you’d like me to address.
Thanks and see you next week!
What did you think of this post? Amazing Good Meh Bad
You received this email because you signed up for emails from Every. No longer interested in receiving emails from us? Click here to unsubscribe. 221 Canal St 5th floor, New York, NY 10013