Are You Shipping Faster than You Learn, or Learning Faster than You Ship?

Here’s a question from my Amplitude coworker Tanner McGrath:

Before you read on, ponder this question for a moment. What is going on at your company? Why? I enjoy Tanner’s framing because there is a lot of nuance baked into that simple question:

• Non-value producing product complexity inhibits your ability to ship and learn. It kicks off a wicked loop. When a system is truly clogged up and the flow of work is low, we see the learning pile up. Frustration levels go up. Teams try complex maneuvers to get work done but this exacerbates the problem.
• When a team accumulates a lot of learning, it can be tempting to settle into a period of fast shipping. “We know what we need to build, and just need to execute!” But that certainty is a mirage. We let our guard down. More efforts miss the mark multiplied by the increased rate of shipping.
• Plus, say the learning is customer feedback (not exploratory research). Our work will reflect that focus —be generally “good” and “helpful” to our customers —but fail to create a step-change.
• Shipping is tangible. Learning is not. It is easy to rationalize “monitoring that feature for a couple weeks” and moving on. And then forget to loop back.
• Teams tend to underinvest in their learning abilities. This overburdens those functions/tools, and in turn predisposes the team to ship more. For example, an overworked and stretched thin design team will focus on shipping.
• Shipping IS important. But an overdeveloped shipping muscle and underdeveloped learning muscle will cause injury. Many teams rationalize a shipping focus because they feel they need to build THAT muscle before they can build the learning muscle. “Walk before we can run!” But they end up with a bloated product and no learning focus. When they finally get around to solving that problem, the effect is too jarring.

So what can you do about this? How do you seek balance?

The first step is visualizing a “loop” vs. a . Then add healthy forcing functions to equalize the two sides of the equation. What types of forcing functions? Learning reviews. Starting together. Exploratory research (together). Kill-a-feature day. Weekly usability testing and customer interviews. Getting out of the build with each major effort. Teams don’t do this stuff “naturally,” so you’ll need to make it a habit.

Acknowledge that not all things need the royal research treatment. Or need rigorous experiments. If you’re a designer, I know you’re saying “don’t say that!” But here’s my take. By saying everything is a big deal, we lose our influence when it comes to the things that deserve that treatment. Figure out where reducing uncertainty will be of key strategic importance and focus there.

But first, pose this question to your team:

And .