All Notes

Build something to disagree with

Last updated

Jul 23, 2026

Discussing an idea before anything exists is surprisingly difficult.

Everybody is reacting to a different version of it.

Even when we use the same words and think we agree, each person is filling in the details in their head. Those details might be completely different.

The reverse happens too: we can debate an idea for hours even though we would agree immediately if we could see what the other person means.

The fastest way out is to make something concrete.

It could be a sketch, a rough doc, an ugly prototype, a draft API, or a half-working implementation. It only needs enough detail to expose the choices hidden inside the idea.

Now everybody can react to the same thing. Instead of comparing several imaginary versions, we can point at one shared version and say exactly what works, what doesnโ€™t, and what we would change.

The first version is not a proposal to defend. Its job is not to be right. Its job is to turn invisible assumptions into visible choices.

This is why our brainstorming works better when people sketch before discussing, why I prefer weekly demos to project updates, and why the only way I know to make something great is to iterate.

When a discussion stays abstract, donโ€™t schedule another discussion.

Build something to disagree with.

Other notes about Company Building and/or Learning

  • ๐ŸŒฟ
    How to be better at making decisions

    What can I do before, during, and after making decisions to be better at making them?

  • ๐ŸŒฟ
    How I tend to my digital garden

    My quests with this digital garden are to publish more and to have fun. Let's explore why I even have a digital garden and how it's going.

  • ๐ŸŒฒ
  • ๐ŸŒฟ
    How to present to executives

    1. Know all your details Know and be able to speak to all the details. Review your own work and ask yourself what somebody else might ask you about it, then make sure you have a solid answer to all those questions. Even things that are technically ou...

  • ๐ŸŒฟ
    Developer tools startups are playing on hard mode

    How do you build a business selling tools to people who can technically build anything you can?

  • ๐ŸŒฒ
    Being unreasonably responsive has made my projects more successful

    Creators who respond to feedback quickly unlock two virtuous cycles that allow them to build better solutions more quickly.

  • ๐ŸŒฑ
    How to ship faster

    Humans have the ability to get ambitious things done ridiculously fast. How can I get more things done quickly?

  • ๐ŸŒฑ
    How I manage my todos as a CEO

    Kanban board with five columns: Inbox, Backlog, Blocked, Delegated, Done Most importantly: GTD-style โ€œif it takes less than 2 minutes, do it immediately.โ€ Create todos for everything (and I mean, everything, including replying to people) that go in...

  • ๐Ÿ”—
    Deliberate practice beats every other form of training, even via transfer learning

    Many people are doing deliberate practice wrong in one specific way though. The Brazilians are an example of what happens when you get it right.

  • ๐ŸŒฟ
    Message me whenever

    Send me messages whenever inspiration strikes or when it makes sense for your workflow. I'll respond when I'm back online. This isn't about being "always on," quite the opposite: it's about respecting that we each know how to structure our own work l...

  • ๐ŸŒฑ
    How do you invent the future?

    Innovation happens by combining things we can see and touch today in novel ways. So how can we have more things to see and touch?

  • ๐ŸŒฑ
    How to run recurring virtual meetings efficiently

    Start with a checkin question for connection (10% of the meeting length) Capture decisions made Capture open action items and check in on open ones every time, otherwise they get lost/forgotten due to poor personal execution Align on discussion ...

  • ๐ŸŒฟ
    How I run gratitude circles

    Credit to Sue Ko who taught me this many years ago. Gratitude circles are a beautiful way to get team members feel seen by their peers. I run them in-person at least once a year with each of my teams. Quote from one of my engineers after their first ...

  • ๐ŸŒฟ
    Why I don't compliment people for their talent

    When people see somebody they perceive to be really good at something, they often say, โ€œWow, they are so talented!โ€ I think thatโ€™s a bullshit compliment.

  • ๐ŸŒฟ
    How we make brainstorming work

    Brainstorming usually fails. But, I noticed a pattern in the times that it worked exceptionally well. Here's how to make it work.

  • ๐Ÿ”—
    David Cain: Do Quests, Not Goals

    I love this reframing from "goal" to "quest": "goals" feel like pressure, "quests" feel like excitement and adventure!

  • ๐ŸŒฟ
    How we foster deeper connections in our remote team

    I believe that teams that are more connected perform better and that remote teams have worse connections. How can we improve that?

  • ๐ŸŒฒ
    Why I'm vigorous about giving feedback

    Every day, you will find me hunting down a founder's email to send them feedback about my experience with their product. Why?

  • ๐ŸŒฑ
    How I get things done

    The smallest project management setup I need: visible workstreams, one accountable owner, deadlines, status updates, and fast weekly demos.

  • ๐ŸŒฟ
    Save polish for where it matters

    Internal communication should be clear and useful, not performatively polished.