Agile or Product Coaching

Why are Agile Coaches so much more common than Product Coaches when Product is supposed to bring home half the bacon?

Have you noticed how many Agile Coaches there are compared to Product Coaches? Why do companies focus so much on achieving faster and smoother development with Agile, but don’t pay as much attention to Coaching Product Managers towards making better, more customer-centric decisions on what to develop in the first place? Only on a few occasions and only in recent years have I seen in-house Product Development Coaches or Mentorship programmes. It seems to still be a common belief that an Agile Coach will also support Product people. Why is that?

So in essence that tells me that a lot is being invested in increasing the speed to roll out new features and products, but not nearly as much effort goes into the steering wheel and the breaks — ensuring that the teams are not just moving fast but also in the right direction, making good (data-based) decisions and building only products and features that truly benefit the customers and the business.

Product Management beyond Agile

I agree that for most companies Agile makes a lot more sense than the traditional Waterfall method. Plus, I like the idea of incremental changes and “failing fast” in terms of shipping new products fast and letting them sink or swim on the market and then improving. But this does not mean that you should skip Discovery in your Product Development process, a crucial step designed to significantly reduce the chances of launching a product that doesn’t meet market needs. Software development is still one of the biggest cost centres (yes-yes, theoretically it is an investment…) in any company. Shooting into the darkness without going through the steps of User and Market Research, Requirements mapping, Process Analysis, Product Design and Prototyping, etc can be a very risky investment. While failing fast is important, it is more important first to do everything possible to avoid failure before you even begin development.

In my experience, these are some of the most crucial aspects of Product Management where Product Managers can greatly benefit from a Coach or a Mentor:

• Validating that the problem is really a problem and how big it is. You might use data available on the internet, and conduct a survey and sometimes interviews to do this. It is also important to try to assess the value of solving the problem at this stage — asking questions like ‘will it bring in extra revenue, save time, or improve customer satisfaction?

• Understanding the users — how users experience the problem, the solutions they currently use, and their emotional responses. This will tell you which types of users might want your solution and what are their pains they need relief from. Next to interviewing users, Jobs to be Done and Customer Journey Mapping are excellent tools to do this. At the same time, you should not forget that Google Analytics, Hotjar screen recordings and heat maps are just as useful.

• Understanding the market and the legal landscape — This involves ensuring that your product complies with relevant laws and regulations, a fundamental responsibility for any Product Manager.

• Envisioning and validating the solution. My recent favourite in defining the scope is based on Jobs to be Done. The Desired Outcome statements paired with the importance and satisfaction assessments by the end users help nicely outline the necessary scope and the must-have aspects of your future value offering. This approach simplifies brainstorming sessions and helps keep the focus on user-based solutions.

• Prioritisation and Roadmapping — Based on the discovery stage, prioritisation and roadmapping become a different kind of game. Using simple yet effective methodologies (https://foldingburritos.com/blog/product-prioritization-techniques/) like MoSCoW, RICE, Value vs Cost or Story Mapping, turns prioritisation into a straightforward, data-driven task. Roadmaps on the other hand will start giving you a better overview of what is going on in the general scheme of things rather than a fragmented to-do list that is difficult to comprehend from the strategic point of view. Love Productboard (productboard.com) for roadmapping and prioritisation by the way.

• Prototyping and UX testing — the prototype (a clickable mockup of the UI designs accurately depicting your future digital product) is your last and best way to do one final test to figure out if your assumptions of the problem, the solution with its value offering, the desirability and usability of your product are actually on point or you still have some polishing to do. This is the first time the whole solution will come together on one screen making it easy for the users to comprehend and give in-depth feedback. The more realistic (without programming) the mockup, the better. Figma, of course, is my go-to tool with a bit of help from the designers, but InVision was my favourite for years because it is simply so easy to use.

• Preparing for development — here, the challenge is to break down the solution into manageable tasks for development, balancing detail with clarity.

• Preparing for the launch of the product — will you launch it as a beta test to a small group of users and collect feedback before rolling it out to everyone? Gmail was in Beta for about 5 years. Will you do a silent launch to ensure the team can fix any bugs quickly or will there be a Marketing campaign right after launch? How do you mitigate risks?

Coaching Product Managers

Agile Coaches can certainly help Product during delivery, but there is a world of responsibilities that lie on Product Managers’ shoulders that have nothing to do with Agile practices. The Coaching of Product Managers and Product Owners, as well as Business Analysts and User Researchers (subject to the specific organizational framework), is ideally overseen by an experienced Product Lead. However, this is not always feasible in practice. The reason primarily lies in practicality: Product Leads often juggle numerous responsibilities and oversee a large team. In many instances, those leading Product Teams may not have direct experience in the field, with teams sometimes falling under IT or Marketing departments. This can leave the Lead ill-prepared to provide effective coaching to their Product Managers.

Consequently, in my experience, it’s commonly expected that Product Managers be self-reliant, possessing an innate understanding of their role, the ability to identify their own areas for improvement, and the initiative to develop and follow through with their personal professional growth plans. This, however, is not sustainable in the long term. When you’re working solo, without continuous feedback or the chance to reflect on your work alongside a fellow professional, it’s surprisingly easy to develop blind spots in recognizing opportunities for your professional growth. You might even start to think that you’ve learned all there is to know. I’ve been in that position myself, so I understand the challenge it presents.

I believe that a great solution would be if every Product Team would have a long-term Product Coach assigned to their team, much like every team has a Scrum Master or an Agile Coach in many companies. A coach that would dive into their work, provide mentoring and training whenever needed and most importantly — provide continuous to-the-point feedback based on the actual work done.

Conclusion

While being able to blaze through development in a fast and frictionless way with an engaged and motivated team is very important, it is only half of the story. Perfectly executed Agile methodologies alone will not guarantee you success. Great products come from really understanding what users need and knowing what can be done with today’s technology. It would be nice to just ask yourself, your in-house stakeholders or customers what they want, but doing that usually only leads to small changes or quick fixes, not the big, dramatic changes we’re trying to make that would truly move the needle.

Invest in coaching your Product Teams to recognise better problems and dream of better solutions. I promise it will pay off.

PS! Remember that popular mantra about Agile’s speed making it divine and Waterfall being evil because a five-year development cycle would render a product undesirable to the customers? I mean, it’s clear that 5 years is a long time and the market needs will have changed in that time. But I often ponder whether the failure of such products was less about time to market and more about their basis. Could it be that these products, conceived without proper validation or user-centric design, were doomed from the start, regardless of the development methodology used?