Aligning Towards Product Discovery

Problem

A few years ago, when I joined a new organisation, I had to navigate many challenges, from working for the first time on a very complex microservices architecture and a High-Availability system to working with OKRs (Objectives and Key Results) and product discovery altogether. My focus was split between ensuring efficient and effective project and product delivery, staff leadership, and team development. In retrospect, I could tell that the biggest challenge was taking ownership of the delivery backlog for a team working with product discovery.

Actions taken

I was fortunate to discover a book, "The First 90 Days" by Michael Watkins, before starting the role. It's a great book that helped me refine my framework of making a positive impact while simultaneously learning the lay of the land and finding your footing.

Firstly, I tried to approach the new role with a learning mindset. I spent time absorbing information and taking notes rather than taking charge and providing answers. Secondly, I tried to balance humility and ego, thus leading with confidence, without adopting a command-and-control style.

Here is a list of some of the actions I took that helped me achieve my goals and be successful:

• Build knowledge around the product that the Engineering team was developing, especially around how we planned to work with product discovery. As an engineering leader, you must understand the product direction, strategy, and vision. You need all of those to navigate priorities better and, last but not least, build the "P" in the "MAP". I'm speaking about the "MAP" that Daniel Pink refers to in the book "Drive" – the initials stand for "Mastery", "Autonomy" and "Purpose".
• Understand and shape the technical landscape and technical priorities for the team. Ensure that sprint by sprint, you pay the technical debt cost and prioritise engineering work alongside new shiny product features.
• Visualise everything that matters. Peter Drucker famously said, “If you can’t measure it, you can’t improve it”. I ensured that every work item that the team was working on is captured and tracked in a ticketing system. Then I made sure the same happened with the outcomes. You should be able to answer whether you're on track with a delivery or not, if what was delivered in a sprint adds value or not, and understand how many production incidents you have at one time.
• Adopt and promote OKRs. Implemented correctly, OKRs are all about conversations and alignment. They help teams understand what success looks like, how they recognise it, what they need to do to have the best chance of achieving it, what dependencies are there, and who can help and support them.
• Review the ways of working. It's easy to get stuck doing the same thing over and over again without forgetting why you started doing it in the first place. That's not Agile. Agile is about inspecting and adapting and quick feedback. Reviewing what processes work and what not, experimenting with different ways that could work for your team is vital for finding what you want to keep and what you want to change.
  

Lessons learned

• The most important lesson I learned was how to align engineering processes within an organisation that shifts towards product discovery. You will need to change how your team will operate to align with this product discovery.
• The notion of requirements as a predictable and scheduled phase in the product development process is one of the most challenging habits for product organisations to break. Shifting from "requirements and design" to "product discovery" is a difficult mindset change both for product and engineering people. Both functions need to collaborate closely, agree on priorities, and understand what makes sense to invest in and what not. If you want to have product discovery, you can't have a unidirectional flow from the requirement to implementation and track the delivery plan as you would when you knew from the beginning how the end product should look like.
• The core use cases of the product we were developing were well known (they've been previously built by a different team in the same organisation). On top of that, we produced our product backlog by running user interviews and adapting the backlog of features per the feedback received. This added a lot of changes in requirements from sprint to sprint. It turns out the discovery process is not always predictable. When things are not predictable, we usually try to force them to become. The temptation to build something and ship it, so at least you know you've delivered something was there, and we fell to it. We used the engineering team for full release cycles to build the software that was tested and deployed into production systems. It took months to get something usable and useful. We've consciously used the Engineering organisation to build a costly prototype and then used our live customers as test subjects. If I had the chance to do it again, I would probably be more resolute in agreeing to build something we might throw away. Or at least before we made sure we understood the end vision so we could better plan it from a delivery perspective and from the technical pieces that the team needed to consider head first.