This shouldn’t be news to anybody who works in engineering or product development, but product quality and velocity are always in conflict with each other: Shipping something quickly means shipping something that’s lower quality than it would have been if you put more time into polishing it.
We all wish it weren’t the case, but like many things in life, the first step is accepting this reality. Once you do, you can think about how your team should be balancing the two. If you don’t, development teams may spend too much time and resources on the wrong things.
That could be the death of a company at our stage. Like most young companies, we have finite time, finite resources, and are default dead. If we don’t invest our time and resources mindfully, we could easily run out of them before reaching profitability.
We’re trying to avoid the mistake one of our founders experienced at one of his previous companies — a tale that is unfortunately all too common. Without a clear directive on where to focus their energies, the team focused too much on perfecting small, non-essential things and missed sight of the product they were really trying to build. The engineering team lost morale as the company floundered when it should have been focused.
Here’s how we’re currently thinking about velocity versus quality at Levels (and how I think most early-stage companies should approach that balance), along with some tips on how we implement these ideas tactically on our development team.
Why We’re Prioritizing Velocity Now
I won’t bury the lede here: Velocity of shipping takes priority over quality of product at Levels right now.
The most important thing for a company at our stage to focus on is learning. We achieve this through running experiments, shipping early iterations of things quickly to uncover what our members value and what they don’t. Or, as it’s defined in The Lean Startup, it’s critical that we operate in the “Build, Measure, Learn feedback loop.”
Startups that don’t ship quickly and regularly die because they haven’t verified their ideas about what products or features customers will value. If we didn’t take this approach and instead focused too much on quality now, we may spend months or even years building beautiful products — that nobody is actually interested in buying.
Instead, we’re playing the long game. Given a fixed amount of resources, we need to maximize the learning by limiting the short-term quality. When we get more resources in the future, we’ll have a clearer understanding of which products we should invest that time and money into. Over time, this will lead to the best quality products that our customers actually care about. Product ideas that didn’t work during the learning phase can quickly be nixed, with no more resources put towards making an invaluable product better.
Given this framework, we think about velocity as the speed at which we learn from our members and ship features that improve their experience. This helps us think about where engineers should be spending their time: if our team notices that an inordinate amount of time is going towards things like fixing bugs or building internal tools, we need to figure out how to adjust so they can spend more time shipping things that help us learn from our members. If we notice engineers are taking a long time to ship new features, it may be worth a gut check about whether there’s a misalignment in terms of quality expectations.
How to Figure Out “Good Enough” Quality
Of course, quality can’t be completely ignored. If a product is so poor quality that it’s not even functional, customers won’t be able to give you any valuable feedback on how it would improve their lives. If it looks too bad, customers might not take you seriously enough to try it.
Given that, our goal is to maximize the rate of learning through high-velocity iteration — while maintaining a standard of quality that is acceptable to our members.
Focusing on quality is the default inclination for most of us, so setting team-wide expectations for quality is important. This prevents anyone from releasing something that is so low quality that it doesn’t represent the brand well — while also helping us recognize when we’re putting in more polish than is required to test the hypothesis.
We’ve roughly defined our current quality guidelines as follows:
In short, we want to make sure everything we ship provides a comprehensive user experience (or gives context that this is a test if the experience is lacking), aligns with our brand guidelines so it feels like it belongs as part of our company, and ultimately is good enough to foster an experience leading to trust.
Tactics for Implementing This in the Development Process
This is all great in theory — how do you actually implement it in practice? Here are a few things that have helped us keep our team focused on speed and learning.
1. Scope Everything Back
Anytime you’re considering a new product or feature, think about how you can scale it back to the smallest change appropriate to test your hypothesis. I always suggest removing requirements until it’s uncomfortable. Remember, you can always add things back in later if members ask for it or once you’ve verified the value and are ready to double down on quality.
Think about it this way: No matter how insignificant an individual task seems, it requires meaningful time. It’s smart to assume that every marginal change or additional requirement on a project takes 5–10 hours of company time unless you can do it yourself in 5 minutes without contacting anyone. Every little requirement you remove from a project will have a meaningful impact on how quickly you can ship it and learn from it.
2. Over-Communicate Expectations
It’s critical everyone is on the same page about company-wide expectations for velocity and quality, as well as individual expectations for specific projects. If they’re not, individuals will make their own judgment calls about which is more important.
This article is based on a memo that I sent around to the team at large to help level-set us all on how we should be thinking about this. I also think it’s helpful for the team to reinforce these ideas regularly when briefing on new projects. For example, in this message, one of our software engineers clearly lays out his quality expectations for a project he needs support on. Without over-communicating, the daisy chain of responsibility may have led someone (with good intentions) to spend too much time on a design that was not needed.
3. Use Authenticity and Expectation-Setting to Your Advantage
Even with all this in mind, it can be really hard to ship things that feel less than the highest quality version you imagine. There are a few things I’ve found to be helpful when you can’t index high on quality and aesthetics.
The first is to lean into authenticity. People are more forgiving about the quality of something when they feel like it’s supposed to be a little off the cuff and rough around the edges. When you chase more quality than you can actually deliver for your stage, you run the risk of losing people.
For example, we tried to create an animated video to explain some medical concepts, but it ended up missing the mark because we didn’t allocate the time to make it truly polished. A better approach at this stage might be a casual recorded Zoom conversation between Casey and one of our advisors. Because of the context, the quality bar would be lower than what people expect out of an animated video.
It’s also helpful to give users context if you aren’t going to be able to deliver the level of quality you’d prefer in a perfect world. Our members know that they’re part of a beta product, so they give us more leeway when things aren’t perfect. Sometimes when we launch very rudimentary ideas, we’ll make it clear that this is a test so folks are more forgiving (and feel more open to giving us valuable feedback). If we succeed in setting expectations, we’ll remove bottlenecks where we feel a need to have a highly polished experience out the gate, even before we’ve learned.
4. Have “Anti-Priority” and “Do It Later” Lists
It’s just as helpful to remind your team what they shouldn’t be focusing on as what they should.
For instance, there may be major company goals or blue-sky ideas that are really important — but aren’t projects we should take on now. Having an anti-priority list for these can keep everyone in check.
There are also plenty of smaller projects, bug fixes, and UX improvements that need to be addressed at some point, but that we’re intentionally de-prioritizing in favor of making progress on projects that will help us learn. These live in our stack so we don’t lose track of them, but are tagged as low priority. They end up serving as great first-day tasks for new engineers or filler tasks for engineers between projects.
Plus, once we’ve proved the value of some of these products and are ready to pivot towards more quality, we’ll know exactly what to tackle first.
