Agile Coachimine või Tootejuhtimise Coachimine

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?

Sellest järeldub, et investeeritakse eelkõige uute funktsioonide ja toodete kiirele väljatöötamisele, aga mitte rooli ja piduritesse - tagamisse, et meeskonnad ei liiguks mitte ainult kiiresti, vaid ka õiges suunas, tehes häid (andmepõhiseid) otsuseid ja luues tooteid ning funktsioone, mis toovad päriselt nii klientidele kui äritegevusele kasu.

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:

  • Valideerimine, et lahendatav probleem on tõesti probleem ja kui suur see on. Selleks võite kasutada internetis saadaval olevaid andmeid ning korraldada uuringuid ja vajadusel intervjuusid. On oluline ka selles etapis hinnata probleemi lahendamise väärtust - küsides küsimusi nagu 'kas see toob lisatulu, säästab aega või suurendab kliendirahulolu?
  • 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.
  • Turu ja õigusmaastiku mõistmine - See hõlmab tagamist, et teie toode vastab asjakohastele seadustele ja määrustele, mis on iga tootejuhi põhivastutus.
  • Lahenduse välja mõtlemine ja valideerimine. Minu hiljutine lemmik skoobi defineerimiseks põhineb Jobs to be Done tööriistal. Soovitud tulemuste avaldused, mis on kombineeritud lõppkasutajate olulisuse ja rahulolu hinnangutega, aitavad hästi välja joonistada vajaliku skoobi ja teie tulevase väärtuspakkumise kohustuslikud aspektid. See lähenemine lihtsustab ajurünnakuid ja aitab hoida fookust kasutajapõhistel lahendustel.
  • Prioriseerimine ja teekaardistamine - Discovery etapis kogutud teadmiste abil muutub ka prioriseerimine ja teekaardistamine lihtsamaks. Lihtsate, kuid tõhusate meetodite kasutamine nagu MoSCoW, RICE, väärtus vs. kulud või Story Mapping muudab prioriseerimise andmepõhiseks ja tõhusaks. Teekaardid seevastu hakkavad andma paremat ülevaadet sellest, mis üldises plaanis toimub, ega ole enam killustunud nimekiri ideedest, mis on strateegilisest vaatepunktist raskesti mõistetav. Muide, mulle väga meeldib Productboard (productboard.com) teekaardistamise ja prioriseerimise jaoks.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.
  • Prototüüpimine ja UX-testimine - prototüüp (UI disainide klikitav makett, mis täpselt kujutab teie tulevast digitaalset toodet) on enne arendust viimane ja parim viis teha üks lõplik test, et välja selgitada, kas teie probleemi, lahenduse väärtuspakkumise ja kasutatavuse eeldused on päriselt ka paigas või on veel vaja lihvida. See on samal ajal esimene kord, kui on võimalik näha ja kogeda kogu lahendust ühel ekraanil, muutes selle kasutajatele mõistetavaks andmaks põhjalikku tagasisidet. Mida realistlikum (ilma programmeerimiseta) on prototüüp, seda parem. Figma on minu eelistatud tööriist koos disainerite väikese abiga, kuid InVision oli aastaid mu lemmik, sest see on lihtsalt nii lihtne kasutada.
  • Arenduseks ettevalmistamine - siin on väljakutse lahendus jagada Taskideks, selgitades eesmärke piisava detailsusega, aga samal selgesti mõistetavalt.
  • Toote turuletoomise ettevalmistamine - kas lasete toote välja beetatestina väikesele kasutajate grupile ja kogute tagasisidet enne, kui kõik seda kasutada saavad? Gmail oli beetaversioonis umbes 5 aastat, et tagada töökindlus. Või kas teete näiteks vaikse lansseerimise, et meeskonnal oleks aega vigu parandada, või ootab turuletoomise järel kohe turunduskampaania? Kuidas riske maandada?

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 practises. 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.

Investeerige oma tootejuhtimise meeskondade coachimisse, et tunda ära valusaimad probleemid ja unistada parematest lahendustest. Ma luban, et see tasub end ära.