top of page
  • Writer's picture

Learning 9: Engage with your stakeholders

This article is part of my learning journal. If you are interested to read them all, jump to my main index page "What I have learnt about product management, agile, and personal development at a big bank".

PART 1: 9 learnings on the process of developing a product from discovery phase to delivery phase

Learning 1: The mindset of DVF, and take ownership to explore DVF, at scale.

Learning 2: Understand your problem statement, and create a clear and long lasting vision

Learning 3: Trust the experts and empower the team

Learning 4: Know the rules before you break the rules (understand current state of your solution)

Learning 5: Clear roles and responsibilities = Clear accountabilities and actions

Learning 6: Make use of your cross-functional talents, make it real team collaboration

Learning 7: Create an actionable roadmap. Convert the experience into coherent user stories. Focus on less, to deliver more

Learning 8: Tactical solution vs Strategic solution, whichever you chose, make sure it's shared understanding

Learning 9: Engage with your stakeholders


This may sound simpler than it actually is. Stakeholder engagement is not simply keeping stakeholders posted of what you are doing, but also help them understand why you are doing this and bring them to your side, and care about your purpose.

Sometimes, we have been telling different stakeholders at different occasions of what we are doing. We kind of assumed at another setting people already know where we are at. And this is where we may experience more push back than it needs to be.

There is no cookie cutter for stakeholder engagement, but I will share what has worked for me. Both in learning 2 and 3 specifically I have mentioned about workshops with different groups of people to bring their knowledge in. On top of a well facilitated workshop, another thing I have been doing and found it beneficial for the conversations with my stakeholders is to create a initiative template that covers:

  • Objective/reason of doing this initiative

  • Customer research insights on the pain points

  • Viability metrics

  • High level end to end customer experience (even though this initiative is part of the whole experience)

  • Detailed user flows and UI for this initiative (usually links to Zeplin so developers can refer to it precisely)

  • Architecture diagram

  • Solution design diagram

  • Work sequencing (including architecture, design, solution, build, test, and launch)

The above points are the collective wish list I had, and not all of them were implemented in my workflow. I have to say I found it useful for big and complex initiatives that involve multiple channels and a variety of stakeholders. As this is a working document, sometimes it won't have all the slides, but the placeholder ensures us to compile all the information required, and it also reminds the purpose of the initiative at any point of time.

To cut the time of back and force on multiple discussion sessions, we usually also present 2 architecture diagrams, and up to 4 versions of design options (including UX flow and solution design) depends on the initiatives. In this way, we are able to make decision quicker on which solution we should go for, how many sprints it will take, and finalise designs at the discussion.

Any other particular stakeholder engagement tips and tricks you have seen and used? I would love to know more and get better at stakeholder engagement.

16 views0 comments
bottom of page