Software — and software companies — break down into two distinct modes:
- Build mode - you’re in blue sky territory, creating something where nothing existing before, trying to find product market fit.
- Optimize mode - you have an existing product, and you’re iterating on it to grow your user base and increase revenue.
It’s an incredibly important distinction to recognize, for a few reasons. One is professional. In my experience, people strongly prefer working in one mode or the other. If you know which and pick jobs accordingly, your career will be better for it. Me? Build mode. The times in my career when I’ve been in optimization roles correspond 1:1 with professional low points.
The other reason is that techniques and practices aren’t one-size-fits-all. The trouble is, discourse is dominated by people working at larger companies that operate in the optimization mode. That’s led to the general idea that the best practices for optimization mode are the One True Way to Do Things.
Why is that a problem? Bringing optimization mode approaches to build mode is like bringing a knife to a gun fight; it puts you at a fundamental disadvantage, and the the likely outcomes range from bad to worse.
One example is the bit of conventional wisdom that dictates that you should have a measurable KPI for every project, every piece of design, every feature that you ship. Side-stepping the fact that you can’t measure most design outcomes holistically, this idea makes sense when you’re optimizing, since it mostly ensures that you don’t move backwards. It trades speed for reduced risk; pretty good calculus for mature companies.
The same approach applied to build mode leads to rudderless products, feature factories, bad decisions made on bad data, and a major blow to your ability to move quickly. Companies at Facebook can run A/B tests and have statistically relevant results the next day. At an early startup that day turns into weeks and months. That’s a kiss of death in a competitive space. In build mode, there’s simply no substitute for taste, vision, deep knowledge of the problem space, and direct user feedback.
Design system are another example. A strong focus on creating and maintaining a comprehensive design system makes perfect sense for a large, mature company. Design system are inherently a scale concern after all. But if your first move as a founding designer at a new startup is to establish a comprehensive design system, you’ve chosen unwisely. Priority one at an early startup is finding product-market fit. If you don’t have that, nothing else matters.
Pragmatically, you also don’t know what you don’t know. Building first lets you see where patterns form, then extract those patterns into a focused, just-enough design system. The end result is business that finds its footing faster, and an app that doesn’t feel like a bunch of LEGO parts stuck together.
Staying mindful of the mode you like and the mode you’re in makes work better.
