Build, then align

In a world before agents, it was genuinely important for a team to align on what to build before doing any coding. The costs of building the wrong thing were high. Coding took the most time and money. So before starting to code, you’d want everyone on the same page. Specifically, you’d want alignment between the people coding the feature, designers, PMs, senior engineers, leadership, and so on.

In today’s world, if you’re spending a lot of time in meetings, docs, and Slack before building stuff, you’re doing it wrong.

Let me explain.

You went through the alignment process for two reasons: first, to try and build the best possible thing on the first try; second, to avoid situations where one stakeholder thought we were building X, but actually we built Y. These stakeholder surprises result in large delays and are one of my least favorite things to deal with.

Getting aligned required lots of meetings, Slack threads, Looms, and so on, which was costly, but not nearly as costly as the alternative. Building without alignment would leave you with the painful choice of shipping something bad or internally contentious, or accepting the sunk cost of admitting you built the wrong thing and starting over (painful but usually right).

To be clear, by “alignment” I mean humans aligning with each other on how a product should work, not humans aligning with agents on how to build. I’m all in on human / agent alignment (see my article on Spec and Verify).

This process used to sort of make sense, but it’s not the way to operate a product org now. It’s a hard habit to break. But if you can, you will move faster and ship better.

At Warp, we are having to change the way we work to adapt to this new reality. In 2023, for example, we spent countless hours trying to figure out how our collaborative platform, Warp Drive, should work based on mocks, slack, PRDs, and on and on before writing any code. I would not do this again.

Instead, I would align the team on the problem space, get some initial ideas from our designers, and start building solutions asap to dogfood internally. Alignment should come after we have solutions in-hand.

What you shouldn’t be doing is worrying if that first built solution is ideal. It doesn’t matter. You should build a testable version as quickly as possible and try it. Build several versions if you want. If it’s possible, have users try it. The key is to not waste cycles guessing if a product is designed right, when you can just build it and experience the actual solution with very low cost and risk.

Once something is built, you are no longer guessing. You are experimenting. What’s more, you are all experimenting on the same thing, not on some hypothetical implementation of a thing which every stakeholder is imagining working in a slightly different way. This is the old way, and a source of so much wasted time.

The new design process

Here is our old process for reference, adapted from the How we solve user problems section of our public How We Work guide:

• Clearly state the problem and user goals

• Explore the solution space together as a team, both from a product and technical standpoint, usually via a “product jam”

• Mock up different possible solutions (<– design bottleneck)

• Align on what we as a team think is the best solution to build (<– team alignment bottleneck)

• Code the solution (<– coding bottleneck, going away)

• Review the code and product to make sure it’s to the initial spec (<– verification bottleneck)

• Dogfood and refine the solution internally until we think it’s good

• Bug bash and ensure quality of the thing we decide to ship

• Ship, monitor and adjust based on user feedback

Most of this stands, but Step 4 should be moved to after an initial build (steps 5 and 6). You still need to do a bunch of the prework – get clear on the user problems, do a product jam, design the best guess solution, but the main goal is to start a feedback loop based on a tangible product as quickly as possible.

We are increasingly working this way at Warp. For instance, we recently launched a whole suite of features for making coding agents work better in the app. We spent time aligning on the problem we were trying to solve – making Warp the best place to build with any coding agent – but we didn’t spend much time bikeshedding the solutions. Instead our design team cooked up some good starting designs, the team built them, and then we iterated together until we got to a spot that felt good. By the time we launched, we were all aligned that the solution was strong.

This is a good time to take a look at your product development process and see if it’s too focused on building alignment up front. You can save a lot of time and headaches by coding first, and then aligning. Working this way will help you move much faster and ship better. It’s also a lot more fun.