Plant anything. Weed never.

“I didn’t know we shipped that.” — a leader at your company, probably.

It has become trivially easy to build things — not necessarily to build the right things or to build them well, but to build things. And in most organizations, the reward function for shipping is short and visceral.

The result is that we’re constantly planting anything we want and never weeding the garden. This is accruing more debt than most organizations realize, and the way out is both straightforward and expensive.

If you’re reading this, you’ve likely built something with AI in the last few months that, in a prior era, would have been nearly impossible for you to do alone. That’s incredible.

And part of what is incredible is that your skills and abilities were augmented by a system that did things that you don’t understand and probably couldn’t do on your own. Which means that, while the thing you built “works,” you may not understand all of it (and maybe you don’t need to).

This is great for bespoke software and side projects, but not core tools and critical infrastructure. Those systems need to be legible and maintainable. You should be willing to own a production incident tied to your pull requests. (h/t Binshtok)

Around the holidays, Opus 4.5 was released and many of us experienced a shift where the models went from being pretty good to downright amazing for what we wanted to do with them. Activities that felt like they were riddled with friction now felt frictionless.

“Software is free, like puppies.”- Vercel’s CTO Malte Ubl

Malte used this metaphor to describe the current phenomenon. Anyone can now build anything! But the act of building has a tremendous amount of hidden costs, and we are rarely aware of them or willing to pay them.

The challenge we’re facing comes from how so many organizations, especially within EPD, reward launches and ignore landings. Launching provides a quick dopamine loop — the thing you’ve built is live! You can touch it and play with it. But landing takes time. The reward function is much longer and inherently multiplayer. And not setting up a launch to land well is often invisible until you’re trying to land. That’s when you realize that support can’t answer customer questions, sales can’t position it, and marketing doesn’t know the story.

The reality is the work of landing that I just described has always been a part of the job of a builder. You are accountable for everything that you put into the world, and that means both to your customers and, more importantly, to your colleagues. Part of the job of building good software means that you are also enabling the people you work with to do their job to make this piece of software successful.

But most organizations do not hold builders accountable to landing. They’ve shifted that burden to their GTM teams, so EPD behaves as though they have air cover to put whatever they want out into the world, leaving GTM to make sense of what to do with it.

This is organizational failure and it’s everywhere right now. If you’re not willing to be accountable to what you’ve built, both internally and externally, you have no business building.

(To be clear, I’m not arguing for a 10-page document for every feature. Discovery is part of product development, but your job doesn’t end when you launch.)

There are a few different things every company can do today, but the biggest levers you have are shifting accountability and making the right things default by design.

The first and easiest thing to do is to be clear that people are accountable to landing, not just launching. Launching is a milestone, not a destination. While you should celebrate the work that got something out into the world, you need to be clear that the job is not done.

And this needs more than lip service at an all-hands. This needs to be a part of how you evaluate the success of the people building products and a part of the feedback that you’re soliciting from partner teams. While I wouldn’t necessarily suggest that partner teams can block launches because they don’t feel properly enabled, I do think there are situations where not being aware of what’s coming to a sufficient degree is worth friction between the feature and the customer.

This could be a small change like regular post-mortems and metrics reviews after launches or as large as changing how people’s performance is evaluated. What’s right for your organization will vary, but incentives work, and the lack of them is part of what got us here.

Another thing organizations can do is make the right thing easy by default. Changing behaviors is hard and telling people to do something rarely sticks. What does work is removing unnecessary friction and building a system where doing the right thing is easier (and more attractive) than doing the wrong thing.

One of the ways that we tackled this problem at Vercel was with something we called “Launch Calendar,” which was a Notion database that acted a bit like a two-sided marketplace or communication tool. On one side, the EPD organization supplied entries for upcoming launches and included what’s shipping, why it matters, what’s changing in the product, and what customers need to know. On the other side, partner teams like support, marketing, or docs relied on those entries to do their job.

Like any tool, Launch Calendar’s outputs were a function of its inputs. A good entry meant that someone in support could handle customer questions on day one without a single DM to the product team. A bad entry meant that there were dozens of hours of back and forth that could have been avoided.

The initial version was very manual. Over time, my team built automations and agents to handle intake and updates, so Vercelians could feed in Notion docs, Linear tickets, PRs, or Slack threads as context and an agent would create the Launch Calendar entry. These entries were then pushed to a Slack channel where we could automatically tag partner teams and leads as an FYI.

In building this system, we were not putting the burden on every individual engineer who is shipping something to go team by team and let them know what they are shipping and why. We were expecting that they did one thing really well, which was to fill out the Launch Calendar to a sufficient level of detail that the rest of the company could act on it.

You may be able to solve this problem by simply holding people accountable to landing and the rest of the behaviors will take care of themselves. Again, the goal is not to stop people from planting things. It’s to prevent your customers from seeing your products like an overgrown garden that has not been tended to.

While we’ve seen incredible compression in the assembly layer of building software, the burden of choosing the right thing to build and ensuring that the people we are building for are getting value from those things has not changed. It’s only gotten harder.

Some follow up thoughts and comments in response to readers. I’ll continue to add here over time.

1. One of my underlying premises is that human attention is scarce. I recognize that we are no longer in the “building is slow and expensive” era, but choosing what to release* because it is worth your customers’ attention should be intentional.

2. I have a follow up post about how to evaluate what’s being built and determine whether it’s ready to release (or not) and how well to support it. This shouldn’t be a surprise coming from someone who spent a decade in user research, though I’ll be focused more on shipping internally and the role of design partners.

3. Yes, agents can complete full build cycles from idea → ship and they can even update docs and inform your partners of what’s going on. I’m less focused on addressing paper cuts and instead nudging you to think “just because I can doesn’t mean I should,” especially when it comes to releasing products. That said, if you’re building explicitly for agents as end “users” we need to have a different flavor of this conversation.