Why agile coaches should strive to be product coaches

Petra Wille recently wrote that agile coaches can’t be product coaches. Her thesis is that most agile coaches aren’t skilled enough in all facets of product development. As a result, they tend to focus on coaching product delivery, often neglecting discovery and other aspects of product management. Nevertheless, many companies still assign them to coach product managers in order to save costs.

I agree with the assessment of reality, not with the title. I believe that agile and product coaching should be the same thing. A good agile coach should aim to be a well rounded product development coach. I will make the case for that today.

I will also give some advice on what agile coaches can do right now to strengthen their product management skills.


The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 


There are skilled and not so skilled agile coaches

Like many professions, it is hard to find exceptional agile coaches. Many of the agile coaches I have met struggle with the basics of product development and are unfamiliar with product discovery. Many have never actually built products but are simply profiting from uninformed businesses.

But I have also met agile coaches that are excellent all around product development coaches. Most of the time, they are not married to the agile label but simply want to help teams successfully develop products. These agile coaches are able to coach product managers. They are also hard to find.

Just because many agile coaches aren’t (yet) capable of being product coaches doesn’t mean that it’s a universal truth that agile coaches can’t be product coaches, especially considering what the labels actually mean.

Agile development and product management are different labels for the same thing

I believe that agile development and product management have more in common than you think. I understand that there may be a significant difference in practice. I also understand that the agile coach label is one that product coaches may not want to be associated with, especially if there has been a dilution in coaching quality. Nevertheless, let me try to convince you. 

Let’s start with the basics. What is agile development? It means iteratively developing a product through a cross functional team, where developers and “business people” closely collaborate. They frequently deliver product increments, gather user and stakeholder feedback, and plan the next iteration accordingly.

One could say that an agile coach needs to help the team develop small improvements that it can use to test for demand, usability and value, while closely working with functions like marketing or sales to make sure the ideas work for the business as well. 

Well, that sounds familiar. 

According to Marty Cagan, as a product manager “you’re responsible for ensuring that what gets built is both valuable and viable. Great products solve real problems for our users and customers, in ways that our customers love, yet work for our business.” 

If you squint really hard, you can see that the difference between agile and product coaching may not be so significant, after all. The problem is that many have lost sight of what agile product development actually is. They automatically assume an agile coach to be the person facilitating the Scrum ceremonies. There is so much more to it, though. 

The principles of successful teams

Marty Cagan in his great book Inspired – considered by some as the bible of product management – states that the best teams build products according to three principles 

  • Address risks as early as possible
  • Build products collaboratively
  • Focus on problems instead of features

Are these principles part of the agile manifesto? No, at least not directly. Would they fit really well? Yes, they definitely carry the same spirit. 

I think good agile coaches and good product coaches are essentially teaching the same thing: successful product development.

A call for agile coaches to focus on product discovery

It is still an unfortunate reality that many agile coaches tend to focus only on product delivery. I want to encourage all agile coaches to strive to be product development coaches. The most effective thing to do is placing more value on product discovery. Here are a few simple steps you can take immediately:

  • Facilitate speaking to one user per week 
  • Increase deployment frequency
  • Empower the team by pushing for outcomes

Facilitate speaking to one user per week 

I really like Teresa Torres’ continuous discovery framework. Without worrying about all of its details, an easy thing to implement is having weekly – or monthly in the beginning – touchpoints with users. 

The goal is to interview them and gain a better understanding of them, their problems, and how they use your product. There is more to interviewing but you don’t need to do anything fancy in the beginning. Simply talk to users and try to understand their experience as it relates to your product. Establishing a regular rhythm in which the team interacts with users is so insightful by itself. You can always expand the scope later on.  

At least one developer and one designer should always be present. I recommend that every team member participate occasionally.

Increase deployment frequency

Aiming for frequent deployments means you are automatically delivering small increments. This by itself can solve common issues that many teams have. The important thing is to monitor the effects of the changes.

You can gather feedback by explicitly asking for it (e.g. in a review), by watching users interact with the new developments, or by monitoring specific product metrics. 

If you are frequently deploying small releases, it’s only a minor step to start conducting experiments. Testing often and early reduces risks. There are many types of tests (e.g. concierge tests, wizard-of-oz tests, smoke screen or fake door tests) you can use to test demand, usability, and value. 

Empower the team by pushing for outcomes

Empowering a team to come up with their own solutions to achieve defined outcomes is probably the single most impactful thing in enabling successful product development. If you are “just using your engineers to code, you’re only getting about half their value.” The best solutions come from the developers that understand the context and have a clear outcome in mind. After all, they know what is technically possible.   

Nevertheless, most companies still have someone defining specific features for the team to build. If you are in the position to change this to providing outcomes that should be achieved (e.g. increase conversion rate vs. build Feature X), do so. 

Most likely, the path towards outcome driven development is a longer one that requires convincing leadership. You will need to continuously negotiate and push in the direction of outcomes.  

This may be tiring but it’s energy well spent. An empowered team will come up with more creative solutions, display increased ownership of the product, and motivation and happiness within the team will increase. 

In conclusion

While many agile coaches currently focus on product delivery, I strongly believe that good ones apply a more holistic approach, as do product coaches. In the end, the goal is to develop successful products, regardless of the label.

I want to challenge all agile coaches to reflect on their work and – if need be – place more focus on discovery. In my view, agile coaches can be product coaches, provided they are willing to honestly assess themselves and put in the work. 

So, agile coaches, ready to step up your game?

Coverphoto by jcomp on Freepik