Learning 5: Clear roles and responsibilities = Clear accountabilities and actions
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
We definitely encourage all hands on deck and help each other out to meet our goals. However, for example, it won't be fair to ask developers to do designers' job and vice verse. Even though people may have the skills to do all of them, it dilutes their energy and time to use their strength and deliver the best outcome for the team.
Trusting your team members is not only believe your team will use their skills to resolve the problems at hand, but also understand when the team members said it's not something they do. On one occasion, one of our designers was asked to do content mapping across channels. My personal preference is if I were the designer, I would use real data set to design UX and UI, however, taking time to cover all real contents for 20 scenarios while they all share the same UX and UI, is probably not the best use of a designer's time. Who should be doing this, you may ask? My opinion is it's business analyst's role to cover WHAT is required.
The other pitfall / mis-expectation is assuming architect/solution designer/platform engineer/developer would know everything about what has happened. Technologists are good with creating a solution to meet a need, but they don't necessarily have the history of how all things were built, and what is the business logic behind the scene. When in doubt, instead of expecting it's solely technologist's job to make it work, it's better to facilitate a discussion between process SME/product SME and technologist, and make sure a good documentation exist for future reference.
The context of the above 2 examples that require clear roles and responsibilities is in a big company with complex work, where the team is already equipped with a variety of skill sets. I do however believe in a smaller environment, when people are motivated enough, they are capable and probably feel more empowered to do more than their assigned tasks.
Read my previous learning point : Learning 4: Know the rules before you break the rules (understand current state of your solution)
Read my next learning point : Learning 6: Make use of your cross-functional talents, make it real team collaboration
Back to my main index page: "What I have learnt about product management, agile, and personal development at a big bank"