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

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

How to Organize, Manage, and Grow Your Team

12 July

Vineet Puranik, Senior Engineering Manager at DocuSign, discusses the impact of roadmaps, organization, and proper management for your teams to procure growth.

Managing Expectations
Delegate
Collaboration
Roadmap
Strategy
Vineet Puranik

Vineet Puranik

Senior Engineering Manager at DocuSign

(Re)Organizing Your Teams Using Domain-Driven Design

12 July

A proposal for how to create an org structure that will deliver software systems that you want, not ones you get stuck with.

Alignment
Architecture
Scaling Team
Building A Team
Internal Communication
Reorganization
Ram Singh

Ram Singh

CTO at REAL Engagement & Loyalty

How to Navigate Your Manager Role at a New Company

1 July

Saikrishna Desaraju, Engineering Manager at Marks & Spencer, draws from his personal experience to advise new managers on thriving in their roles.

Managing Up
Managing Expectations
Leadership
Collaboration
New Manager Of Manager
Changing Company
Saikrishna Desaraju

Saikrishna Desaraju

Engineering Manager at Marks and Spencer

Team Development Framework for new managers

26 June

Individual Contributors are familiar with a technical development framework that helps them with building products. Managers, especially new managers can leverage a parallel framework to help them build their teams while drawing analogies from an already familiar framework.

Building A Team
Team Processes
New Manager
Viswa Mani Kiran Peddinti

Viswa Mani Kiran Peddinti

Sr Engineering Manager at Instacart