This is an excerpt from our (Ryan Brook and yours truly) new book, The Anatomy of a Product, lovingly called TAP. We're excited about it and confident it will help many product teams put their product in context and deliver higher value. Forewords written by Radhika Dutt (author of Radical Product Thinking) and Arie van Bennekum (co-author of the Agile Manifesto). We're here to share the first real bit of content with all of you:)
First Time Right – we’re confident you have heard of this term. Although it sounds great, it’s nearly impossible to achieve. A myriad of different variables affect our development and usage of the product, making it virtually impossible to nail all of those right away. Shortening our learning loop, not just the feedback loop, helps us find the right things sooner. The difference between feedback and learning is that feedback is one-dimensional. In contrast, learning is translating that feedback into the product and validating whether or not it meets the users’ needs. Shortening your learning loop gives you a competitive advantage.
The Learning Loop
Learning how to learn starts with humility. You don’t know everything. Assume you don’t know anything. You can’t know everything. Every assumption, every hypothesis, every roadmap item needs to be treated like a bet, not a guarantee. That means creating room in your process to test, observe, and adapt.
The most effective learning systems start small. Here are a few ways to build that muscle:
- Ideate.
Start here when there is no previous feedback. Consider this your Spark when there is no product yet. What is your idea, and what value does it bring? What problem is it solving? What makes a user more effective in getting to a particular outcome?
If you already have a product, consider your ideation the most important piece of feedback and feature on top of your backlog.
- Experiment & Develop
Create an experiment that can support validating or rejecting the hypothesis created in the Ideate step. We challenge you to think ahead about what information you are going to look for later. What feedback do you need? What do you want to learn? What signals are supporting your hypothesis? In other words, what evidence do you need to prove you are on the right track? Develop whatever it is you defined in the previous step. In development, we include testing, QA, and everything needed while keeping it as short as possible. The challenge is to make it as representative as possible.
- Test and Validate
We’re not talking about integration testing, unit testing, and those kinds of tests. We’re talking about going to your users’ environment and making the circumstances as representative as possible related to where it will be ultimately used. If you can do this on the production environment, do it. This keeps the learning loop as short as possible. Validate using the feedback, signals, etc, we defined in the previous step.
- What else?
Be mindful of the not-so-obvious. Is there anything happening that we did not anticipate, nor is being articulated by the users?
An airport we worked with fired nearly all its security staff during the COVID lockdowns. Waiting times skyrocketed when the lockdowns were loosened because there was almost no security to handle all the people who wanted to travel and celebrate freedom. After bringing security staff on par again, they measure not only the obvious, but also the not-so-obvious. Obviously, the waiting time decreased. But not-so-obviously, the revenue of the shops and restaurants behind security booths went up beyond pre-pandemic times. People were spending more time waiting, and therefore, spending more money.
- Reflect.
Where are we right now in our journey to achieve goals, value, and outcomes? To what degree does the information now available affect these factors? Can we speed up, or should we slow down? Did we strike a gold vein? Did the goal evolve or become obsolete? Can we be more effective in enabling users to achieve their desired results?
- Adapt
Adapt everything that is needed. Not everything that is possible is needed. That could be your backlog, roadmap, ways of working through retrospectives, or whatever you need to adapt to achieve value based on what we just learned more effectively. Not all feedback is equal. Be wary of edge cases, loud voices, and confirmation bias. Look for patterns, not anecdotes. If a user tells you something surprising, don’t dismiss it, but validate it across other signals. Good learning is grounded in context, not just volume.
The goal is to increase the velocity of insight. The faster you learn, the quicker you can build the right thing and reject the wrong things. The best teams operate like research labs, constantly testing, refining, adjusting, and learning. It’s almost an art form where chaos turns into controlled evolution and innovation.
Learning how to learn is the foundation for everything else in product. Without it, you’re just making educated guesses and hoping for the best. With it, you’re building a system that improves itself. And that’s the kind of team that survives the unknown and thrives in complexity. Measure how long it takes to fulfil The Learning Loop. Where can you qualitatively shorten that? Note the emphasis on qualitative, because we do not want you to cut corners in product quality just to turn this learning loop into another vanity metric.
We aim to publish TAP on December 1st. Follow us on LinkedIn to stay up to date with many exciting updates about this book, including workshop tools and card decks.