Board

Capitalism is hard. But part of the reason this happens is because getting money and keeping money are two different skills. Getting money requires taking risks, being optimistic, and putting yourself out there. But keeping money requires the opposite of taking risk. It requires humility, and fear that what you’ve made can be taken away from you just as fast. It requires frugality and an acceptance that at least some of what you’ve made is attributable to luck, so past success can’t be relied upon to repeat indefinitely.

Compounding only works if you can give an asset years and years to grow. It’s like planting oak trees: A year of growth will never show much progress, 10 years can make a meaningful difference, and 50 years can create something absolutely extraordinary.

Nassim Taleb put it this way: “Having an ‘edge’ and surviving are two different things: the first requires the second. You need to avoid ruin. At all costs.”

1. More than I want big returns, I want to be financially unbreakable. And if I’m unbreakable I actually think I’ll get the biggest returns, because I’ll be able to stick around long enough for compounding to work wonders.

A plan is only useful if it can survive reality. And a future filled with unknowns is everyone’s reality.

3. A barbelled personality – optimistic about the future, but paranoid about what will prevent you from getting to the future – is vital.

What if these higher-level services from different underlying providers could be delivered through the same Kubernetes APIs and with the same level of consistency offered to containers running on Kubernetes itself? What if it can be done with the same Kubernetes declarative approach and the control loop mechanism? This would allow the reuse of Kubernetes semantics, APIs, tools, and practices for managing external resources as if they were containers on Kubernetes. And

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.

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 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.)

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.

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.

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.

Pieter has a distinct approach: he does everything himself and doesn’t build VC-style businesses that are going to IPO. But even for founders wanting to go the VC route, his approach is underrated.

The biggest mistake a startup can make is having a technical co-founder who is more interested in engineering than product-market fit. While these types of people will never come out and say that explicitly, you can infer it through their actions.

The fastest way to learn how is to get a mentor. Find someone who is a good engineer and get them to review your code. If you don’t have a friend who fits the criteria, you can hire someone. It’s much less effective and more time consuming to try to learn all of the best practices on your own from blog posts and books.

It’s a waste of time. I know this may be an unpopular opinion for some people, but no-code tools are often just as complicated to learn as code—except there is a low ceiling on what you can accomplish with no-code, and learning one no-code tool barely translates into any other tool. Code has a compounding advantage because the same patterns come up over and over again, and there is no limit to what you can build. I’m thankful that no-code wasn’t around when I was getting started, because I probably would have wasted a lot of time, and it would have been a dead end.

I reject the distinction between “learning as you go” and “establishing a baseline before you get started.”

You’re always going to ping-pong between acquiring skills and using them. Sometimes the loop is fast (e.g., looking up how to sort an array in JavaScript, then using it), and sometimes it’s much longer (e.g., deciding to use Ruby on Rails to create your web app, then buying a book and doing an extended tutorial before you write one line of code for your own app).

(By the way, this cycle never ends. Coding is a constant loop of looking stuff up every 5-10 minutes, writing code, then looking stuff up, over and over.)

When I’ve spent too much time “building background knowledge” before I started building, I was procrastinating. I was psyched out by the daunting task in front of me, so I gave into the temptation to fiddle around. This same challenge will present itself to you over and over in life, in many different forms. It’s best to see it for what it is, stop fiddling around, and get started.

You’ll learn so much faster if you feel free to start from scratch building the same idea 10 different times. And you should expect to do this. When you approach it this way, you give yourself permission to try to do the first step even though you know you’re probably going to screw it up. And that’s a good thing—because when you get stuck, you will have identified the gaps in your knowledge that are holding you back.

When designing software, there’s a temptation to use off-the-shelf UI toolkits and CSS frameworks. I would be careful about this. Stock UI is never quite right for your specific needs, but it’s so easy to use and so close to “good enough” that it’s tempting to keep going with it. The furthest I go toward modularity is to use a good icon set, like Google Material Symbols or Apple’s SF Symbols library.

I find it easier and more satisfying to start from scratch than to wrestle with pre-made components. But the most important benefit is that it’s easier to achieve simplicity.

The more complex the design, the harder it is for a user to understand it. Have as few elements as possible—and make them count. The same principles I wrote about in the context of selecting which features to build also apply here: less is better, move quickly and based on your intuition without overthinking it, and show the product to users to uncover problems and solve them iteratively.

Over time you can develop your intuition to learn what people will understand and what they’ll find confusing, but the only way to improve is to observe people use your designs. When you’re sitting next to someone as they navigate your product, it becomes visceral just how confusing everything is. Your mirror neurons activate, and you can more easily empathize with what it feels like to see your product through the eyes of a new user.

Design is a little bit about aesthetics, but mostly about clarity. I want as little friction as possible between a user and their goals. The best way to do this is to pay close attention to how other websites and apps are built, and copy the patterns.

The main role of aesthetics is to inspire trust and to support an overarching vibe. If a product feels like it has too much of the wrong personality, it can be a distraction. The best “personality” is not achieved by in-your-face choices like loud fonts or animations; instead, personality shines through when the interface allows the functionality to come through clearly. Such an interface makes the personality more about functionality than style, which is almost always better.

It might be a cliché to end on a Steve Jobs quote, but it’s perfectly apt: “Design is not just what it looks like and feels like. Design is how it works.”

Thankfully, the founders figured out a subtle shift in positioning around the time I joined that made a big difference. They kept all three core elements in place, but started pitching it as a newsletter platform rather than a paid publishing platform.

In Substack’s case, life in the “paid publishing platform” market was rough, because very few people thought they wanted it, and the people who did were locked up by switching costs from the complex systems they rigged together. But competing in the “newsletter platform” market was a dream in comparison. Hamish could email writers on Mailchimp and say, “Would you like to stop paying $60 a month to send to your list?” and it was a no-brainer. Or he could talk to a Tinyletter user and ask “How close are you to hitting the cap?” (Yes, Tinyletter actually caps writers at 5,000 subscribers.) Or he could ask Medium writers if they would like to own their own email list and brand, or ask Wordpress users if they’d like a built-in newsletter. Shoot, he could even nudge professional authors and journalists to start a newsletter as a sort of career insurance policy—and it would work!

Needless to say, competing in the “newsletter” category made life easier. It wasn't perfect: most of the writers we acquired this way did not start paid subscription newsletters, and we generated no revenue off them. But still, it was absolutely worth it. The “newsletter” positioning served as a wedge, and generated a viral distribution loop where more writers came on Substack, made their readers aware of it, some of whom would go on to join as writers. It created credibility and awareness that were the key to giving more people the confidence to start paid newsletters. And, most importantly, it laid the foundation for the network effect that today helps writers on Substack get more readers without having to do any extra work.

The best thinking I’ve found on this is in the book Obviously Awesome by April Dunford, but I felt it could be even more useful if combined with strategy concepts like disruption, wedges, shifts in the the basis of competition, etc.

The Startup Positioning ProcessThere are five steps: Start wide open Identify the bright spots Anticipate where they lead Choose a path Conform everything around that choice

Be on the lookout for different types of people who like your product for different reasons. Don’t assume the default path is the right one.

This advice is dangerous so I’m going to start by saying what it doesn’t mean: “wide open” does not mean “unfocused.” It does not mean “a product that tries to be all things to all people.” Instead, it means “open to many possibilities, able to perceive reality as it is, without warping new evidence to make it fit your prior expectations.”

In this way, you can start narrow and wide at the same time. Your product and target customer should be narrow—just as all the classic advice says to—but your mind should be wide open.

As they process new information, they fail to pick up on the little clues the universe gives them about better possibilities, because it does not occur to them to be on the lookout.

It’s also important not to be too narrow in who you get to try your product. Sure, focus on the people you think are most likely to enjoy it. But be curious about what happens when other types of people try it, too. Casting a somewhat wide net in the earliest days of a new startup is underrated, as long as you know what you’re doing and use it as a part of a deliberate process to find product-market fit.

For example, Figma started out knowing they wanted to build a web-based graphics editor using a new technology called WebGL, but they didn’t know exactly what type of use-case they wanted to focus on. Eventually after a period of experimentation they settled on UI design for web and mobile apps. Who knows what would have become of them if they tried to cling too tightly to an original market?

Of course, this is only good in an early, experimental phase. In order to scale you do need to pick a focus. And the next step in the process explains how to do that.

For people who said they would be “very disappointed” if they could no longer use the product, look at how they answered the second question asking them to describe what type of people they think would be most likely to get value out of the product. They are essentially describing themselves here.

Use this information to identify common circumstances that people find themselves in that make your product useful. There may be a few different natural clusters—give each a segment a name.

For example, Superhuman used this process to realize their product was most valuable for founders, investors, managers, and business development executives.

The important and counter-intuitive thing to do is to actually not act on the suggestions or ideas from people who don’t like your product at all. It’s tempting to try and convert them into believers, but be cautious before you proceed. There are a lot of types of people out there with many different preferences. You can’t make all of them happy. It’s much better to identify the bright spots and try to expand them than to worry too much about the people who don’t get it.

Look for easy-to-understand messages that lead to rapid adoption from some specific group of customers. You might have to make some sacrifices in order to do so, but this is usually a good idea.

Yes, but it’s more complicated than that. Creating a new category is kind of like building a network effect—it’s a reward for growth, and helps growth in the long run, but it doesn’t help you start growing from zero.

When you try and pitch people on a new category, typically you are met with a blank stare. People won’t listen to your whole spiel about what it is that you do. Much better to anchor on an existing category that they already understand, that way they can infer all sorts of features they assume you probably have without you having to explain anything.

It’s much better to “anchor & twist”—start with something easily understandable, and have one big new thing that is different. Substack is a newsletter platform—with payments. Superhuman is an email client—that’s absurdly fast. Figma is a design tool—in a web browser. (You get the idea.)

This idea—that anchoring on an existing category is often good—is one way to anticipate where a bright spot might lead. But it’s far from the only one.

Switching costs. You can avoid a lot of competition in the early days by positioning yourself as a complement to a thing people already do, rather than try and replace a whole system head-on.

Network effects. If your product is positioned around single-player value to start, it is a good idea to anticipate what sort of multi-player value you can layer in as you get more adoption, so that your position can evolve over time towards network-value, rather than tool-value.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

The core idea is that if you, as an investor or a founder, can do the work and understand a market better than anyone else, and appreciate that its actually bigger than anyone gives it credit for, then investors can pay higher prices, founders can be more aggressive with burn, and experiment more broadly

But when it comes to understanding markets, the more perspective you have the more it can give you an advantage.

"If you had a hedge fund analyst and a venture capitalist on a game show you could ask the question "a company's valuation is primarily based on BLANK." The analyst might say "the cash flows that a business will produce in the future." The VC's answer? "The narrative."

Valuation, growth, burn, and ambition are all a function of the size of the opportunity. High valuations, high growth, high burn, and large ambitions are all pretty foolish if the opportunity is small. But sometimes? The opportunity turns out to be so big that it was foolish not to pursue them more aggressively.

They realized they had also become quite good at running infrastructure services like compute, storage and database (due to those previously articulated internal requirements). What’s more, they had become highly skilled at running reliable, scalable, cost-effective data centers out of need."

The insight certainly came from appreciating reality as it was, but several companies had already done that. The question wasn't whether people would transact online. PayPal was over a decade old at that point. The insight was how big the market for simpler payment processing online could really be.

The best way to predict the future is to invent it." (Alan Kay)

Early on, big things might start out feeling like a toy. But their ability to extend from one value proposition to the next, and address more and more of a market is the secret sauce you want to dream about. That's where high net dollar retention comes from. Companies that are able to drive usage (more volume of the same thing) or modules (adjacent pieces of the same thing) will find themselves with more more market to address

Dream the dream vividly.