The purpose of this document is to orient the team as to the current stage of the company and how that affects the way we need to think about velocity of shipping and the bar for quality.
The most important thing for a company at our stage is to focus on learning (or as it's defined in The Lean Startup, the "Build, Measure, Learn feedback loop"), and we achieve that through running experiments. So, for the next few months, we should focus more of our time on discovering new sources of value rather than delivering on value we already know about*.
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, as set through clear expectations, authenticity, and participation.
We need to make sure that we have as many resources as possible working on the things that move the ball forward as a company.
Before we discuss the appropriate quality bar for our stage of the company, it's important to dive deeper into the big picture on how focusing on learning with our limited resources is the right move for the next few months.
By maximizing our rate of learning now, we're truly leaning into a deep concern for quality — but you have to zoom out to see it. We're playing a long game, and in order for us to have the best quality products over time, we need to uncover what our members value and what they don't — and that takes experimentation. Given a fixed amount of resources, we need to maximize the learning by limiting the short-term quality.
As a reminder on Level's current stage of company 👉
If we focus too much on comprehensive quality at this point in time, we'll have limited resources for learning what our members find valuable. In the long run, this will hurt our desire to have high quality products, as we'll build something that is high quality, but may not have been the right thing to build.
During this early company stage, it's critical that we tilt toward learning. And once we've learned, we can build it the right way with future resources. This approach to optimizing for learning (while maintaining a bar for acceptable quality) gives us a better chance at overcoming "default dead" and building the things that should be built.
Another way to think about quality and velocity is through the below graphic. If our intent is to build a car and we hypothesize that people want an easier way to commute, we should not slowly proceed to iteratively build pieces of a car. We'll validate our hypothesis much too late, after investing the majority of our resources into building something we're not even sure if people want. Instead, seek the hypothesis we want to prove in building a car, and build a quality smaller version that meets the same need, like a skateboard or bike, to test whether it'd be worth building the full-quality car one day.
Here's where we are today with Levels: