Morning guys, happy Saturday.
I’ve started noticing that a lot of work now arrives looking finished before I’m convinced anyone has really thought about it. The deck is clean, the memo has a neat structure, the launch post has exactly the right cadence, and the product somehow already has six features. None of those things are bad, obviously. The weird part is that they used to contain a small amount of evidence that somebody had spent time on the problem.
AI is removing that signal. You can now make an ordinary idea look like a polished idea almost instantly, which means polish tells us less than it used to. I increasingly find myself trusting the slightly rough memo with one interesting observation over the immaculate one that could have been written about any company in the world.
The same thing is happening to products. Building is cheaper, experiments are cheaper, new features are cheaper and launching something is cheaper. When execution gets easier, the interesting decisions move earlier: what should we build, what actually belongs together, what deserves a launch, which experiment is worth taking seriously, and which perfectly buildable thing should simply be left alone?
A few things I’ve been reading lately all seem to circle that same problem.
Sponsored by…
The fastest teams stopped typing.
Your day is Slack threads, emails, docs, and CRM updates. Every one of them starts at a keyboard, and the keyboard is the bottleneck.
Wispr Flow turns your voice into clean, ready-to-send text in any app. Speak a three-paragraph client update in 30 seconds. Dictate the proposal while it’s still fresh. Flowstrips filler, fixes grammar, and formats it so you just hit send.
4x faster than typing. Used by teams at 270+ Fortune 500 companies. Works on Mac, Windows, iPhone, and Android, with Flow for Teams for your org.
Try Wispr Flow Free →
1. Bundling only works when the products make each other better
I went back to an old conversation with Hiten Shah on Relay because his explanation of bundling is more useful than most of the current conversation around “compound startups.”
His basic point is that software companies keep rediscovering bundling under new names. Parker Conrad calls it the compound startup. HubSpot figured out a version of it years ago. Freshworks, Zoho and plenty of others have built broad suites too. But simply putting a lot of products under one logo is not what makes the model work.
The important thing is the core underneath them.
Hiten describes Salesforce as owning the customer record and HubSpot as owning the contact record. Rippling is trying to do something similar with employee data. Once one system becomes the place where an important object is created, updated and trusted, every adjacent product can use that same information without rebuilding the context from scratch.
That gives us a much better test for whether something is actually a bundle. Imagine removing one product from the suite. Does another product become worse because it loses data, workflow or context that only the combined system had? If yes, there is something compounding. If nothing changes and the main benefit was one invoice and a 20% discount, you have a Costco multipack.
This distinction matters because software companies naturally want to sell adjacent products. You already have the customer, so why not add payroll, expenses, recruiting, analytics or whatever sits nearby? But adjacency on a slide does not create product advantage. The new product needs to become better because the customer already uses the old one. Otherwise a great point solution can still arrive and beat you.
The system of record is what makes that possible because it gives every new product an unfair starting point. If Rippling already knows who every employee is, where they work, what role they have, what device they use and who manages them, another product built on top of that dataset does not begin at zero. It inherits the company.
I also like Hiten’s observation that these strategies usually sound much cleaner in hindsight than they did at the beginning. Early HubSpot was an inbound marketing company. I doubt somebody in 2006 had a perfectly drawn map showing how it would eventually compete across CRM, sales, marketing, service and commerce. Rippling probably did not begin with every detail of its current thesis either.
That might actually be the important bit. You probably cannot sit down on day one and declare that you will become the system of record for an entire category. Nobody awards you that status. You discover that the narrow product you built happens to sit upstream of something much larger, then you methodically earn the right to build outward.
Which is probably why Hiten says he would not talk much about it if he discovered the same thing at Nira. Not because somebody will copy the idea tomorrow, but because the idea is almost meaningless before the product proves it. Big strategic narratives sound intelligent after the compounding starts. Before that, they mostly sound delusional.
The clever part is noticing the core early enough to keep building around it.
2. Duolingo didn’t hijack Apple’s launch in nine minutes
When Apple unveiled its new iPhone Duo, Duolingo immediately started having fun with the name. Its account posted variations of “it’s called the iPhone WHAT???” and eventually landed on the obvious joke: an expensive iPhone Duo versus Duo on your iPhone for free. Samsung joined the pile-on too, and the whole exchange ended up getting covered well outside the original posts.
It is easy to file this under “brands should be fast on social.” I think that misses most of what happened. Plenty of companies could have posted within ten minutes and produced something painfully unfunny.
Duolingo’s reaction was fast because the company had already done years of work before Apple ever announced the phone. People know what the owl sounds like. The social team knows what it can joke about. The company has a fairly clear sense of how strange it is allowed to be. Whoever wrote the post was not inventing a personality during the keynote. They were operating one that already existed.
That is what a good brand voice actually buys you. It is not just consistency across website copy. It reduces decision time. When something happens in culture, the team can ask “What would we say?” instead of first asking “Who are we?”
I think companies underestimate the operational value of that. A weak brand voice creates a meeting every time you need to speak. Someone writes the first version, marketing makes it safer, legal removes the joke, leadership asks whether it aligns with positioning, somebody edits it again and two days later the internet has moved on.
A strong identity acts like a decision framework. It tells the team which jokes belong, which opinions sound natural and where the line is. That means you can move quickly without making every post a miniature governance exercise.
So the lesson I’d steal from Duolingo is not “roast Apple.” It is to decide what your company sounds like before you need to say something quickly.
Relevance looks spontaneous from the outside. Usually it was rehearsed for years.
3. Launch day is disappearing because release day already did
Kyle Poyar recently broke down how Notion, Rippling and Profound approach product launches, and one point stuck with me: the release and the launch no longer need to be the same event.
That sounds small, but it changes quite a lot. Software teams can now ship continuously. A feature can reach users quietly, collect feedback, improve for a few weeks and only then get a proper launch once the company understands what story is actually worth telling. You no longer need to attach all the emotional weight of “launch day” to the exact moment the code becomes available.
This matters because shipping has become much faster than customer attention. Internally, your team can produce meaningful changes every week. Externally, your customer did not suddenly gain another ten hours a week to understand all of them. Five launches in a month might feel like momentum to the company and noise to everyone else.
The job of a launch therefore changes. It is no longer enough to announce that you shipped something. Customers assume software companies ship things. A launch has to explain why this particular change deserves to enter somebody’s mental model of the product.
That is why I like the examples of founders and builders talking directly about what they made. A PM saying, “We watched customers do this ridiculous five-step process for six months, so I built this,” contains information. It tells me where the feature came from, why it exists and why somebody cared enough to build it.
Compare that with the usual “We are excited to announce our next-generation workflow experience.” The second sentence is cleaner. It is also nearly empty.
There is a connection back to the writing problem here. When beautifully polished output becomes cheap, polish loses some of its signaling value. That does not mean every launch should look amateur. It means evidence becomes more valuable. Show me the customer reaction. Show me the broken workflow. Let the person who built it explain what annoyed them enough to fix it.
The companies that are genuinely shipping useful things should probably become more comfortable showing the fingerprints of the people making them.
Maybe the future launch is less of a giant event and more of a running public record that your company keeps noticing real problems and fixing them.
That is harder to fake every two weeks.
4. AI made the $10,000 experiment cheaper. It did not make being wrong cheaper.
A guest essay on Annie Duke’s newsletter makes an interesting argument: big companies say they want more experimentation, but their internal incentives often make small experiments personally riskier than large projects.
A $10 million initiative usually comes with institutional cover. There is a committee, a strategy deck, a budget process, consultants, leadership approval and enough signatures that if the whole thing fails, everybody can reasonably say “we decided.” A $10,000 experiment might have one person’s name beside it.
That creates a strange situation where the smaller financial risk can carry the larger career risk.
The essay gives a good example of the mismatch AI is creating. A team used modern tools to make an enormous change to a legacy codebase over a weekend, work that previously would have taken months. The old security process then required a manual review that was expected to take even longer than the original development would have taken.
AI removed the production bottleneck and immediately exposed the permission bottleneck behind it.
We are going to see this everywhere. A prototype can now be built before the meeting where people decide whether someone should be allowed to build a prototype. A market test might cost less than the hours of senior management discussing whether the market test is worth running. At some point, deliberation becomes more expensive than experimentation.
The obvious response is to tell people to be more courageous. I think that is mostly useless. People respond to incentives, and if success is shared while failed experiments get attached to individual names, rational employees will avoid bets that can make them look stupid.
A better system evaluates the quality of the decision separately from the outcome. Was the hypothesis sensible? Was the downside bounded? Was the experiment cheap? Did we decide beforehand what result would make us stop? Did we learn something useful when it failed?
I especially like pre-committing to the kill condition. If nobody uses it by this date, stop. If conversion stays below this number, stop. If three customers do not ask for it, stop. Then when the result arrives, you are not negotiating with a team that has spent six weeks becoming emotionally attached to its own work.
Cheap experimentation only matters if stopping is cheap too.
Otherwise AI just helps us produce zombie projects faster.
5. Software’s biggest problem may be that almost nothing forces us to stop
There is a great essay called “Software Drives People Insane” that makes a fairly simple observation: software combines speed, abstraction, complexity and an almost unlimited ability to change your mind. Put those together for long enough and perfectly normal people start behaving as though everything is permanently one refactor away from being fixed.
The physical world gives you friction for free. If you decide halfway through building a house that the kitchen belongs on the other side, you can see the pipes in the wall, the timber already cut and the labor required to undo the decision. Changing your mind has a visible cost.
Software hides most of that debris.
A request might sound like one little button while touching six services. A rewrite creates no pile of demolished concrete for management to walk past. The cost appears later as regressions, context switching, abandoned assumptions and engineers spending another week relearning a part of the system they had finally started to understand.
Because the cost is hidden, “we could change this” slowly turns into “we should change this.” Growth slows, so redo onboarding. Customers are confused, so redesign. Development feels slow, so replace the process. Then replace the tools supporting the process. Then reorganize the team using the tools.
Eventually the company itself starts getting treated like software: permanently mutable and permanently one reorganization away from finally working.
AI makes this temptation worse because implementation is becoming less of a natural constraint. If a founder can ask an agent for another dashboard, another workflow, another pricing experiment and another microsite before lunch, then engineering capacity stops protecting the product from the founder’s imagination.
The thing standing between the company and enormous complexity becomes judgment.
Or, maybe more accurately, taste.
People use “taste” as though it only means knowing what looks good. I think one of its more valuable forms is knowing what does not need to exist. Which feature should not be built. Which customer request should not be followed. Which process is good enough. Which slightly ugly thing should remain slightly ugly because fixing it would make three other things worse.
Leaving something alone sounds passive, which is why companies are bad at celebrating it. Nobody gives an award to the product manager who spent a quarter deciding not to redesign a working settings page. But restraint can preserve years of accumulated user understanding and engineering stability.
There is an old startup instinct that says speed wins. Often it does. But speed helps when you know roughly which direction deserves acceleration. Moving faster between a hundred unnecessary changes does not create clarity. It just shortens the interval between mistakes.
A useful question for almost any established product might be: what would actually happen if we did nothing to this part for six months?
Customers might have time to learn it. Engineers might finally understand it. The team might discover whether the original idea was actually good before replacing it with the next one.
In an industry built around making change cheap, restraint may become one of the expensive skills.
If you’ve been enjoying Token Economy, subscribe and share it with someone who might like it too. Each week, we look at what’s changing in AI, tech, startups, and business, why it matters, and where things might be heading next.