Algo Mind
OpinionProduct

The Ten Commandments for Building Product

A record of mistakes I made and watched others make: ten commandments for building product, and the self-deceptions each one guards against.

26 min read

Reading depth

Complete essay, examples, notes, and source detail.

45 min

I spent the past two years at an AI agent startup. We took three swings, across three pivots: a Minecraft coplayer called Project Sid, a general-purpose desktop agent we called Fairies, and finally an Excel coworker called Shortcut. As the founding engineer I had a front-row seat to nearly every decision. I watched the early bets fail, and I watched the team turn the last one into a product that found fit, and saw what that took. So this is a record of mistakes, not a recipe for success. Following all ten earns you the right to maybe succeed; nothing earns you the success itself.

This is about going from zero to one: building a product before it has found product-market fit, when you still don't know who your user is, whether they want this, or whether it should exist at all. There is one disease underneath most of what follows. Every evasion that promises to spare you painful, first-hand contact with reality is an illusion that feels like progress and isn't. Reading logs instead of watching a user, awarding yourself the certainty of a great founder, letting an AI stand up the "correct" architecture before you've found a single customer. All of them feel like moving forward. They are ways of standing still while feeling busy.

AI makes this more dangerous, not less. It lowers the cost of building so far that the old ways of avoiding reality now look like extraordinary productivity. The product is still an organism that has to evolve through contact with the world. It is not a spec you can get right in advance by thinking hard enough, and it is not a system an agent can scaffold into truth before anyone wants it. These ten are defenses against the specific illusions that let you believe otherwise. The first three are about the same failure at three depths: whether you are willing to suffer the user's verdict, whether you are projecting yourself onto them, and whether you can name the exact subgroup you serve.

The Ten

  1. You shall be honest about whether you are committed to the product, or only in love with the idea.
  2. You shall not mistake self-expression for knowledge of your user.
  3. You shall not pretend to know your user.
  4. You shall not mistake a breakthrough for a product.
  5. You shall not throw the problem of how to use your product onto your users.
  6. You shall not treat every feature as equal, nor chase one more feature before launch.
  7. You shall be driven by outcomes, not activity, and ship early enough to face the verdict.
  8. You shall not build for a million users before you have a thousand.
  9. You shall not assume a good product sells itself; you are its missionary.
  10. You shall have patience; attention is a spark, not the fuel.

1. You shall be honest about whether you are committed to the product, or only in love with the idea.

Building means enduring its pain yourself, and any move to delegate that pain is proof the commitment was never there. The pain I mean is not the engineering. You can delegate execution; plenty of people who could not write the code have shipped great products through people who could. The pain you cannot delegate is the grounding and the rejection: figuring out who your users actually are, going to them yourself, selling the thing yourself, watching them ignore what you built, being told no to your face, and sitting in the uncertainty without a dashboard to hide behind. There is a familiar version of this move: "have someone run the user research and bring me the findings," while you keep the decision authority for yourself. That is not delegating labor. You have delegated the only part that was yours, and you are now making product calls from an intuition you never earned, because you were never close enough to anyone to develop one.

The most flattering disguise this wears is the belief that you are Steve Jobs or Elon Musk. You have their certainty that you are right, and none of the scars that earned it. But the imitation misses what the certainty was actually made of. Jobs shipped flops, got pushed out of his own company, and clawed his way back. Musk nearly went bankrupt and watched his rockets explode again and again before one reached orbit. They were wrong constantly. Their certainty was never that they were right about everything; it was a narrow, earned conviction about the few things they would not compromise, paired with relentless honesty about all the rest they had gotten wrong and had to fix. They held the vision and rebuilt the execution. The imitator takes the certainty and spreads it over everything, because they never earned the honesty, or the scars, to tell what they are right about from what they are not. And certainty spread that thin is just another way to avoid finding out you are wrong. It is completely fine to want to survive and to pivot. Just don't cosplay the commitment of people who didn't.

2. You shall not mistake self-expression for knowledge of your user.

Let your taste seed the product, but never let it certify the market. Your taste is a legitimate seed, the point of view and conviction a product needs to begin. But a seed is a hypothesis, not knowledge, and it helps to be precise about what the hypothesis is. It is not the claim that your taste is good. It is a claim about other people: that you are a stand-in for a real group, that what you find compelling they will find compelling, that the thing you want is a thing they need. Those are the bets that matter. Whether the solution is elegant is almost beside the point; the only question that settles anything is whether a real person on the other side wants it.

So self-expression is not the enemy. It can grow into a great product, but only one way: when it earns the user's endorsement, either because you understand them well enough that your taste is really a reading of theirs, or because you carried them with you until what you wanted became what they wanted. Either way the verdict comes from them, not from you. It goes wrong the moment you let your conviction stand in for their verdict and assume the world will love what you love. If you only want to express yourself, that is fine; build the thing and enjoy it. Just don't dress it as a product and hope, on no evidence, that strangers will adopt it and call you brilliant for it. That hope is the tell. So ask yourself plainly: do you want to express yourself, or do you want to express yourself and have the world decide you are great for it? The first is honest. The second is a hunger for applause in a product's clothing.

The line between this commandment and the next is simple: users own the problem; you own the solution. They are reliable witnesses to their own pain and unreliable architects of the cure. Mine them relentlessly for the problem, but never let them design the thing.

3. You shall not pretend to know your user.

There are three ways to get this wrong. The first is crude: not knowing who your user is is bad, but pretending you know is much worse, because it quietly sets the priorities for everything you build, and sets them toward a user you invented instead of one you found. Knowing your user is not a guess you make on day one; it is the result of going into the weeds until the picture is specific. And specific is the word that carries the weight. "Developers" is not a user. Neither is "builders," or "AI pioneers," or "Minecraft players." Each is a dozen different people who want different things and judge your product by different standards. Until you can name exactly which of them you serve, you cannot decide what matters in the product, and you cannot earn the focus that decides everything else.

We learned this the same way three times. Building the Minecraft coplayer, we said our users were Minecraft players. Then we watched them: some live to build, some live for PvP, some only want to hang out with friends in a shared world. Those are three different products, and the label had hidden all of it. Building Fairies, our desktop agent, we said our users were white-collar workers. The honest version was that we wanted them to be our users; they did not see themselves that way, and the distance between what we wished and what was true was the whole problem. Even with Shortcut, our Excel coworker, we started with "all Excel users" and only slowly found the ones who mattered: people doing high-caliber work to a high standard, in finance. The person who opens Excel to jot down a few numbers never became a user, and chasing them would have cost us the ones who did.

The other two ways hide behind a sense of scale. The first is new. When vibe coding makes a feature feel almost free, you start to believe you no longer have to choose: research every kind of user at once, list every need, ship something for each. Speed makes selection feel optional. It never is. Trying to serve all of them is how you serve none, and it is the same pretense in a faster costume, the fantasy that you can hold every user in focus at once instead of the specific few who are actually yours.

The last reaches for logs. Early on, metrics feel like the scalable way to learn what users want, but a log does not capture what a person did, only a flattened trace of it, with the context and the intent stripped out. To get anything from it you have to reverse-engineer why someone behaved that way, which is guessing again, now dressed up as data. Logs tell you what; you are starving for why. And this early you barely have the volume to mine anyway, so you trade your one rich source for a thin one that flatters you with the feeling of scale.

All three are the same move: avoiding the specific, first-hand work and calling the avoidance progress. There is no way around it. Go sit with them and watch what they actually do. A real user interview is not transcribing what they say; it is watching how they use the thing in their own environment, where the details a direct question would never surface finally show themselves. This holds for business products too: the forward-deployed engineer exists precisely because someone has to sit inside the customer's reality instead of inferring it from far away.

4. You shall not mistake a breakthrough for a product.

The last four years made this trap almost irresistible. Model capability jumped so far, so fast, that a generation of researchers and engineers came to feel a breakthrough is self-evidently powerful, and ChatGPT seemed to prove the rest: that a breakthrough can simply become a product. It is a myth, and the people most exposed to it are exactly the ones with research and engineering backgrounds. The researcher is wired to push the frontier, and demonstrating something that was impossible yesterday is thrilling on its own terms. The engineer who meets a new capability falls into the oldest trap there is, the belief that a good hammer entitles you to beat every nail and call the result a success.

But a capability is an input, not a finished good. A product is the translation of that input into a met need, and the translation, figuring out whose problem this solves and how anyone would actually use it, is the entire job, not a footnote to the breakthrough. The capability is real. The product is not there yet, and no amount of admiring the capability will summon it. Someone has to do the translation, and that someone is you.

The reality keeps making this point. The model behind ChatGPT existed well before the product did; what made it a phenomenon was the plain chat box wrapped around it, and even then, by Sam Altman's own account, the early retention was "atrocious."Altman said this in a 2025 conversation with Vinod Khosla. His fuller point was almost optimistic: the early test cohort was tiny and its retention atrocious, but the few who stayed used ChatGPT more and more over time, and that rising curve was the signal that mattered. His rule of thumb was that any retention at all puts you in good shape, and that even something like 5 percent can be fine when the default for a new product is a straight line to zero. The coding ability now inside every model did not turn itself into a product either; it took companies built around product to do that, Cursor and then Claude Code, each a dedicated product effort, not a research result left to speak for itself. We made the opposite mistake ourselves on Minecraft. We got excited that our agent could build a diamond pickaxe, and that a group of agents could build more than three hundred items together, both genuine technical feats, and it won us a lot of attention on X and Hacker News. But it was never clear that the attention reflected a need anyone actually had.

What looks like a research-versus-product tension is really something simpler and harder. Research and product are two different kinds of work with different goals, and the honest move is to respect the difference instead of pretending one becomes the other. OpenAI is the rare case where research seemed to lead straight to product, and overnight a lot of people decided that path was easy and theirs to copy. But even OpenAI did not jump from breakthrough to product; it shipped an API and learned its way toward one.OpenAI shipped the GPT-3 API in 2020, more than two years before ChatGPT, and figured out the product from how developers actually used it. Altman walks through this arc, from playground to product, in the same 2025 conversation with Vinod Khosla. Connecting research and product is a third effort all its own, the translation this commandment is about, and it is real work. The trap is wanting all three at once on day one, the research, the product, and the bridge, with the strength to do none. So choose the problem you are actually solving. Are you building a product, or answering a research question? You cannot fund all three on faith and hope they meet in the middle. The choice is the first commandment again: be honest about which one you are committed to, not in love with the idea of both. And believing the three will converge on their own is the illusion this essay opened with, an evasion that feels like progress while you stand still.

5. You shall not throw the problem of how to use your product onto your users.

Great products carry clear functional affordance: the user simply sees how to use them. Good products carry a clear onboarding path that adapts the user to the product over time. Products built on genuinely new technology arrive with neither, and articulating the usage is your job, not the user's. Clear use is your design, not their puzzle to solve.

We lived both sides of this. Fairies was a blank chat box, much like ChatGPT, and we wanted users to grasp that it was something more, a general-purpose agent. We never managed to say what that meant, not to them and not to ourselves: we could not articulate how a user would benefit, what problem it solved, or even how to begin. So the burden fell on the user, and a blank box that can supposedly do anything reads as nothing in particular. The examples we put out to fix this only proved the point.The one that caught real interest was a desktop-cleanup app that organized the files on your computer. People liked it, but it was a single legible trick, not the general-purpose agent we were trying to convey. Even our best example pulled users toward the narrow thing they could understand and away from the vague thing we wanted them to see. Shortcut was the opposite. On day one it looked like a spreadsheet with an agent panel beside it, and every user understood at a glance, without a word from us, that this was about automating spreadsheet work with an agent. The affordance was the form; we never had to explain what it was.

Once the shape was obvious, the real work could begin: learning what users actually cared about in spreadsheet work, accuracy and formula correctness above all, and showing the agent build a genuinely complicated financial model so the value was something they could see and reach for. Clear affordance did not finish the job, it let us start it. You pay for that clarity in one of two ways: by using the thing so heavily yourself that the right shape becomes obvious, or by working shoulder-to-shoulder with the people who will. New technology does not come with instructions. Throwing "figure out how to use this" at the user is taking your single hardest design problem and tossing it over the wall with their name on it.

6. You shall not treat every feature as equal, nor chase one more feature before launch.

Focus is the discipline of saying no. It is not working hard on everything; it is deciding what not to build, and that refusal is the muscle. And the reason runs deeper than effort: your features are the message you send users about what your product is. A small, sharp core tells them exactly what this is and how to use it. Add features past that core, especially early, and you are not extending the product so much as blurring what it says. The longer the feature list, the muddier the message.

We shipped exactly the wrong kind of feature in Fairies. A developer added a way to ask the agent to change the app's color theme: no settings to dig through, just tell it and watch the whole app recolor. It felt wonderful, genuinely agentic, the software rearranging itself from a single sentence. But I could not have told you why it deserved to exist, how we would explain it to anyone, or which user needed it while their real problems sat untouched. It flattered us and said nothing to them, and it shipped anyway, before launch.

The temptation is sharper now than it has ever been. The general-purpose reach of modern models, and the pull of AGI behind them, really do show that a new capability can be applied to one more field, and then another, so adding one more thing it can do always feels justified. Breadth itself is not the enemy; a product can grow to do almost anything, and users may want exactly that. What you cannot do is lead with breadth. A product enters a user's mental space through a single clear wedge, one thing they immediately understand it is for. "It does everything" is not a wedge, it is a fog. So you keep that entry point clear, refined, and frictionless, and earn the breadth later, once the wedge has taken hold.

"One more feature before launch" is that muscle failing in real time, and underneath it is anxiety. You do not yet know which features will resonate, so you reassure yourself: maybe one more will reach another group and open another door. That hope is a symptom, not a plan. It is the third commandment coming back to collect: you never named your user, so now you hedge across all of them, reaching for one more feature to catch a group you were never sure existed. Each delay feels like care and is really flight from the market's verdict, and the good feeling you get from polishing the eleventh feature is the illusion thickening, because the market has not been consulted and you have learned nothing. Find the core set that gets the product into real hands, and ship that.

7. You shall be driven by outcomes, not activity, and ship early enough to face the verdict.

Shipping ten pull requests and five features is activity. It feels like progress and frequently isn't. Code has never been cheaper to produce, and vibe coding makes a thousand lines in an afternoon feel like real momentum. Garry Tan boasted about shipping thirty-seven thousand lines of AI-generated code a day, until a developer looked under the hood and found bloat and rookie mistakes.The boast was thirty-seven thousand lines a day across five projects, alongside a seventy-two-day shipping streak. The developer who inspected the output found bloat, waste, and rookie mistakes. The point is not that the product had no users; it is that the line count was never evidence either way. When an agent writes the lines, the count measures its throughput and nothing else. It was never a measure of value, and now it is not even a measure of effort. Whether anyone wants the result is a different question, and no line count will ever answer it. AI can compress implementation time. It cannot compress the market's verdict. Cheap code does not move a product to market any faster unless it tightens the loop: ship, measure the outcome you actually care about, learn, improve, and go again, fast. Code is a means to that loop, not the point of it.

So decide, before you ship, which outcome you are actually trying to move, because not every number is one. A real outcome is the market voting with something it cannot fake and you cannot manufacture: people coming back, people bringing others, people paying, a company signing. For most products that means retention and growth; for some it means a paid conversion or a signed enterprise deal. Payment is the hardest vote of all, and going out to win these votes is a commandment of its own. Whatever the form, the test is the same: did the market do something that cost it?

So move your most uncomfortable moment, being rejected by real users, to the left. That moment is unavoidable; you only get to choose its timing, so take the pain early and make your later work easier. Then read the right number. Not signups, not applause, not vanity counts: return. Retention is never granted; you earn it. And when it is missing, resist the reflex to assume a single cause. It might be the wrong user, the wrong problem, a weak onboarding, a real but infrequent need, or an incumbent too entrenched to dislodge. Diagnose which one before you rebuild.

(This is the twin of commandment 6, and they are easy to confuse. Six is about what you build, the discipline of refusing scope. Seven is about how you judge what you built, and when you expose it. You can do one perfectly and fail the other.)

8. You shall not build for a million users before you have a thousand.

Your product is an organism, not a spec. Standing up a system that holds a million users when you have zero feels like rigor. It is procrastination with excellent posture. And for an engineer it is the most comfortable procrastination there is, because scaling is real, hard, legible work, the kind you are good at, which makes it the perfect place to hide from the users who have not arrived yet. If your product is going to take off, your alpha and beta will tell you in time to build the real infrastructure. Before you have a clear signal, building for a million is premature work on a future that hasn't arrived.

The sharper edge of this is new. Coding agents now make it feel free to build the final architecture on day one, as if you could skip exploration entirely and arrive directly at THE correct answer. That is the latest illusion, and AI is its salesman, because it sells the fantasy that you can be all-knowing at the start and never have to discover anything. You can't. The right system is found as the product finds its users. It grows like an organism. It is not dictated like a blueprint by someone who imagines he already sees the whole thing.

There is one honest exception, and it sits on the same research-versus-product line as the fourth commandment. If you are doing research, you may genuinely need to build infrastructure for it, and you should. Just do not mistake research infrastructure for product infrastructure. They serve different needs, and a lesson I paid for is not to couple the two too early: tangle them while both are still moving and you end up with something that serves neither the research nor the product well.

9. You shall not assume a good product sells itself; you are its missionary.

Finishing the first version is the starting line, not the finish. A good product does not introduce itself, and it does not get paid for on its own. Most of the people who would love what you built will never know it exists or see what it can do, unless someone makes them, and that someone is you. If you believe in the thing, you go out and sell it with the conviction of a missionary, because no one will carry that conviction for you.

We think Shortcut is the best spreadsheet agent on the market. Believing that quietly is worth nothing; the job is to make people know it, to put it in front of them until they see what it does. This is not work you hand to a sales hire after launch. It is the builder's job, and it starts with the builder.

The proof that your selling worked is not applause or signups, which are free and forgettable. It is what happens after first contact: whether people come back, whether they bring others, whether usage deepens, whether a buyer is willing to pay. Do not assume payment is always the first number that matters; retention and daily use often matter more, and revenue built on shrinking use is a short story. A good product and a product people pay for are still two different objects, because willingness to pay is shaped by forces you do not control: substitutes, budgets, what the alternative costs, and pricing itself, a trade-off between what people will actually pay and economics that have to add up. None of it is settled by the product being good.

None of this is comfortable. Building feels noble and selling feels grubby, so founders under-invest in distribution, and superior distribution routinely beats a superior product. It is harder now than it has ever been, because attention is the scarcest thing there is and nobody is coming to find you. So go manufacture some: a launch, a demo, a post that stops the scroll are all fair tools for getting the product in front of the people it is for. Do the missionary work; it is the job, not a thing you skip because the product is good.

10. You shall have patience; attention is a spark, not the fuel.

Building a product takes patience. The work is to keep making it better, week after week, long after the first version's thrill is gone. By now you have done the missionary work and grabbed what attention you could; good. But attention is not growth. Attention is a spark; the product is the fuel, and a spark over an empty tank goes out in seconds.

The pattern holds at both extremes. The Humane AI Pin and the Rabbit R1 had every spark a launch could throw, millions of views, sold-out preorders, the press calling them the future, and no fuel underneath; both collapsed within months.Both shipped to brutal reviews. The Rabbit R1 reportedly had around five thousand concurrent users five months after launch, and Humane put itself up for sale and wound the Pin down within roughly a year of launch. At the other end, products with much less manufactured spark caught fire on the fuel alone: Cursor grew to enormous scale on word of mouth with almost no marketing, Claude Code shipped as a quiet research preview folded into a model release,Claude Code arrived as a "limited research preview" inside the Claude 3.7 Sonnet announcement on February 24, 2025. Anthropic later said it reached roughly a billion dollars in annualized revenue within about six months of becoming generally available. and OpenClaw became the most-starred non-aggregator software project on GitHub. The fundamental reason a product spreads is never the launch. It is that the thing is good enough that attention, however it arrives, turns into people who stay and bring others.

We saw both halves of it ourselves with Shortcut. The launch video had a real viral moment, and the daily actives spiked, then fell almost as fast as they came. The spike was never the win. What won the customers, and what kept the number climbing long after the video was forgotten, was the quality of the product. The eruption got us looked at; only the product got us kept.

Timing sits here too: right product, wrong decade is one of the most common ways good work dies unseen, and you cannot hurry the decade. So strike whatever sparks you can, but build the fuel as if the sparks will never catch, because most of them will not. Do not stake your survival on a viral moment, and never mistake one for the thing itself. Attention you can manufacture for a day; a product people return to, you build over a long time.

A last word on the elephant in the room. Almost every illusion in this essay now runs on the same accelerant: AI makes avoiding the real work feel free. It will write the architecture, generate the features, produce the lines, and make a technical breakthrough appear almost immediately, all without your ever meeting a user. That is why these ten matter more now, not less. When building gets this cheap, building stops being the thing that separates you; judgment does, knowing who you are for, what they need, and whether they will come back and pay. AI automated the part that was never the hard part. The hard part is still yours.

Best wishes to you on building your product.