Learning 4: Know the rules before you break the rules (understand current state of your solution)
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
One of the challenges our team have experienced a few times is not validating assumptions early enough, even though they are educated assumptions. The cost of not validating assumptions could range from not be able to complete design solutions, not be able to estimate correctly and miss out the timeline, to potentially present wrong information to customers that could lead to financial and reputation damage.
On a few occasions, we have to use our personal experience, from customer perspective to reverse engineer the current state. And that is very error prone and time consuming (to wait for the event happen in real life).
I believe 2 practices will help remediate this risk
1. Invite all relevant stakeholders to create a proper service blueprint, it will help remind you scenarios you didn't think of, and the process you didn't know about.
2. Conduct impact analysis: further to service blueprint, which highlights the areas to look into, conduct an impact analysis to understand what changes your solution is going to bring to the system, process and people. Involve the system/platform engineers, the process SME and change managers to fully assess WHAT is changed, and WHAT is the new solution.
Any other rules about designing a good experience, developing a good product you know of, and think worth to know before you break it?
Read my previous learning point : Learning 3: Trust the experts and empower the team
Read my next learning point : Learning 5: Clear roles and responsibilities = Clear accountabilities and actions
Back to my main index page: "What I have learnt about product management, agile, and personal development at a big bank"