Back to resources

Aligning Towards Product Discovery

Internal Communication
Collaboration
Team Processes

15 July, 2021

Catalin Stoiovici
Catalin Stoiovici

Head of Scaled Engineering Delivery at Capco

Catalin Stoiovici, Head of Engineering Delivery at Capco, discusses aligning engineering processes within an organisation that intensively shifts 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.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

Myth Busting

10 December

Supporting principles on why being data led (not driven) helps with the story telling.

Alignment
Managing Expectations
Building A Team
Leadership
Collaboration
Productivity
Feedback
Psychological Safety
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

The Not-So-Easy Guide on How to grow and develop an Amazing A-Team

5 December

Your Org Team may as well be a Sports team. Let's explore how this cohesive, multi-skilled team can be optimized for Great Group Playoff.

Alignment
Building A Team
Company Culture
Sharing The Vision
Embracing Failures
Team Processes
Jaroslav Pantsjoha

Jaroslav Pantsjoha

Google Cloud Practice lead at Contino

The Growth Mindset in Modern Product Engineering

28 November

The impact you can have with a Growth Mindset' and the factors involved in driving orchestrated change.

Building A Team
Leadership
Collaboration
Feedback
Ownership
Stakeholders
Vikash Chhaganlal

Vikash Chhaganlal

Head of Engineering at Xero

How to improve engagement and retention in remote engineering teams?

25 October

Mrunal Kapade, an Engineering leader, based in Silicon Valley, shares tips that helped reduce attrition in the remote engineering teams while leading multiple teams from startups to Fortune 500 companies.

Remote
Company Culture
Collaboration
Motivation
Team Processes
Mrunal Kapade

Mrunal Kapade

Director of Engineering at Inspire Energy

How to Maintain Happiness: The Underrated Aspect of Creating Team Dynamic

2 August

Jonathan Ducharme, Engineering Manager at AlleyCorp Nord, encourages the importance of a workplace environment that cultivates mental wellness.

Personal Growth
Company Culture
Leadership
Internal Communication
Psychological Safety
Jonathan Ducharme

Jonathan Ducharme

Engineering Manager at AlleyCorp Nord