Modern software development encourages us to build without learning.
Here’s an example: I’m a designer. My team expects me to know the right way to design things. But I don’t always know the right way to design things.
It’s hard for me to say “I don’t know the right way to design this” because it makes me vulnerable. It feels bad, like I’m saying “I don’t know how to do my job.” So I often say “I know the right way to design this” when I don’t know.
I make my best guess at the right design. The team builds what I design, but they don’t know that I’m just guessing. Maybe I was right, maybe I was wrong. We move fast, so there isn’t time to discuss the unknowns. There’s nothing to validate or invalidate. Nothing is recorded or reviewed. No new knowledge is gained.
We build without learning because we are optimizing for speed. What if we reversed this? What if we optimize for learning?
Here’s how we can optimize for learning:
- If I don’t know the right way to design something, I say “I don’t know the right way to design this.”
- My team supports me: we commit to learning the right way to design it.
- We identify incremental experiments to reduce the unknowns.
- We write and validate or invalidate hypotheses as we go.
- We regularly record and share what we learn. We grow our knowledge base.
- Repeat × ∞
For instance, when a product manager asks “How do we increase conversions of free users into paying users?” I say “I don’t know. Let’s find out.” The team writes a hypothesis, then builds and delivers an update to the product.
Maybe the features are unclear, so we make the pricing page easier to read.
Maybe the upgrade form is too complicated, so we make more fields optional.
Maybe free users don’t see the value of upgrading, so we introduce a free trial.
At each stage, the team might succeed in increasing conversions. But even if we don’t, we’ve learned more about the users and the product. By reviewing what we learn, we write better hypotheses. Better hypotheses lead to more knowledge. Learning compounds.
Optimizing for learning requires embracing unknowns. It forces exploration, and rewards risk-taking. When new knowledge is shared, each new iteration is safer, more confident, and even more educational.
Designers don’t have to know the right way to design everything. When we don’t know, we should openly commit to learning. Next time you don’t know the answer, try this:
“I don’t know. Let’s find out.”
Special thanks to Josh Petersel, Laura Hahn, and James Ayres for their feedback on early versions of this essay.