‘The shortest distance between you and your product’ by Katherine Radeka

‘The Shortest Distance Between You and Your New Product: How Innovators Use Rapid Learning Cycles to Get Their Best Ideas to Market Faster’ by Katherine Radeka

Who should read this book?

Innovators and (product) developers.

Agile Coaches aiming to transcend Scrum, SAFe, and Kanban.

Why you should read this book (or not)?

This isn’t a breezy read. It’s not a page-turner. My suggestion: start with ‘When Agile Gets Physical by Katherine Radeka & Kathy Iberle’ for a smoother entry.

Prepare for a paradigm shift with the Rapid Learning Cycles approach. If your world revolves around innovation and development, these concepts are your new best friend. This book meticulously unveils the ‘Rapid Learning Cycles’ framework and its practices.

Now, it’s labeled as the agile remedy for any innovation with a high cost of change. But beware, it’s not a one-size-fits-all. Originating from the intricate world of HP printers, applying these concepts to process innovation demands a bit of customization.

Summon your courage to navigate this book, and you’ll unearth a trove of insights that can revolutionize your perception of agility.

Combine this book with ‘The Lean Startup’ by Eric Rise and you’ve crafted a potent synergy. Together, these works offer invaluable insights and concepts that can significantly enhance your journey in the realm of innovation.

Interesting extracts

“Rapid Learning Cycles are a synchronized set of experiments to remove uncertainty before key decisions need to be made in a product development program. One Rapid Learning Cycle is 2 to 8 weeks of focused work to help the team make better decisions when uncertainty is high and so is the impact of the wrong decision.”

“An Agile Software Development team learns through building the product. For the most part, they use a set of well-known technologies (coding languages, algorithms, protocols) and an established technology platform (the chip, the operating system, the Internet). (…) The cost of a Build-Test-Fix cycle in software is the cost of the developers’ time. In hardware, we need to coordinate with the model shop, suppliers and testing groups, all of whom have other programs competing for their time.”

“Traditional mitigation strategies for late design changes make things worse. Tight change control adds overhead that makes it difficult to move quickly when the team finds a problem. Locking down requirements early increases the likelihood that they will change. Design “freezes” operate the same way: forcing decisions to freeze early increases the chance that a given decision will be wrong. Forcing development teams to set aggressive dates too early drives them to take shortcuts that will hurt them later. A product development group should be able to deliver its products on time—if the group does not set the final launch date until midway through the development process. At that point, the team members should know enough about what they understand and what they still need to learn in order to deliver a finished product that is good enough for the market it’s going into. They should be able to establish a launch date that they can stick to. The more you can push decisions later, the more predictable your launch dates will be. “

“The Core Hypothesis has three dimensions:

1. Customer: What customer value does the product deliver, and how does the customer interact with the product to realize that value? E.g. ‘Writers will buy Time Your Words! because it is designed for them to track their time without being distracted, as a timer app on a smartphone might.’
2. Technology: What core technologies will be used to deliver the value? E.g. ‘Our known technology in delivering timers with features tailored for specialty markets.’
3. Business: What is the business model? How will you turn this into a profitable business? E.g. ‘Capitalizes on an opportunity in a new market.’ “

“When a raft goes through rapids, a pilot steers the raft, but for everyone else, the objective is to keep paddling in sync with one another. Paddling provides the forward momentum that helps the raft cut through the churning water without getting diverted into obstacles by the current. Cadence works the same way on a project with high turbulence: it keeps everyone pulling in the same direction and generates forward momentum to carry the team over obstacles.”

“Hold people accountable for sharing interpretations and recommendations-not just activities and data. It’s hard to explain the rationale for a recommendation or a decision if you’re not allowed to share what you did to learn what you learned. But if a team member describes an experiment and reports the data without offering an interpretation and a recommendation, ask for them. Without this analysis, the team hasn’t learned anything. This is especially important when working with new engineers. Since they lack experience, they may hesitate to offer their opinions. But they will learn much faster if they do give interpretations and then listen to the feedback.”

“Stop doing anything that does not contribute to Learning. (…) If you have an idea for a different approach that will generate the same knowledge but faster, better or cheaper, that’s what you should do instead.”

“Status reports are to be avoided at all costs. They communicate nothing of value to your stakeholders and sponsors, because they focus on doing and not learning. Instead, I suggest that you use the status reporting format to discuss the team’s active Key Decisions and Knowledge Gaps. Don’t report that Dora is running the XYZ experiment, but ran into problems with the centrifuge. Instead, report that Dora is working to understand the optimal concentration of the stabilizer, so the team can finalize the product’s formula. This will lead you to talk about the stabilizer options instead of the centrifuge, and that will help you get better feedback from your stakeholders. They might know something about stabilizers that can help you work around the centrifuge problem to eliminate the risk of putting in too little stabilizer.”

“Convergence is a method for making a complex decision by investigating multiple alternatives and narrowing down to the final solution in a series of steps. First, you establish a set to explore. Then you define a series of tests to probe the set for weaknesses. Each test will eliminate some options until you have found your final solution. (…) Our default behavior, especially if we have an innovator mindset, is to choose the winners. We like working with the ideas that seem to have the most promise. We like making decisions and locking down options. It feels like progress. When we choose the strongest options to go forward, we focus on the strengths that we see to find the ideas that perform the best. We forget that good performance on one test does not guarantee that the option will perform well on every test. It’s easy to overlook weaknesses because we are not looking for them. If we are looking for winners, that’s what we find. (…) Convergence works best when each step is a hurdle that alternatives must pass.”