PART 2: What do people look for in a good Product Leader, Designer, Scrum Master and Technologist.
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".
After working in a big bank for 7+ years with a variety of roles across operation, technology, design and product ownership, I took my personal learnings and also ask around people I have worked with on what they are looking for in a good product leader, a good designer, a good scrum master and a good technologist. By no means this is an exhausted list, it is only learnings I took from my perspective. The common theme and the most important factors I believe, on top of respective skills in their fields, is interpersonal relationship and genuine care and interest in others.
I will break down the topics based on the role:
1. A good product leader
There are many discussions on product manager vs product owner, I found these 2 article (The product manager vs product owner, and product owner vs product manager) pretty good explaining the roles. However, I prefer to call it product leader, who foremost cares about people: customers and the team.
A good product leader should have holistic thinking: who looks into a product development from DVF lens, pays attention to on-boarding and retention experience, besides feature development, and is non-comprisable on analytics. One would proactively look into market trend, competitor analysis, and objectively understand what is our existing product situation. And work with the team to create opportunities, build a roadmap, prioritise backlogs and shape the experience our customers are looking for.
Whether a product leader is facing externally to stakeholders or internally to the team, it's important to provide direction and context, and makes sure s/he reminds people the vision of the initiative often. When leading a team, it's important to have an open discussion with the team on roles and responsibilities, and make sure you help your team to keep their career pathway open, and help them to learn whatever interests them.
A good product leader is also not afraid to share information on constraints of the initiative, either it be funding, timing, feasibility etc. If you establish enough trust and build a good relationship with the team, open up with the team on the challenges, and don't be afraid to be vulnerable. Be genuine. People are usually keen to help. Often, constrains help team to work creatively, and I am sure the team would rather know it beforehand, instead of being frustrated and confused by the decision after they have invested significant effort.
Lastly, product development is a test and learn process. Product leader is accountable for developing a right product, and technologist is accountable for building the product right. But it's never a 100% guarantee the solution will address the problem, but it should be a good bet.
2. What makes a good design
When designing an experience, make it useful, useable, accessible, in context (real scenarios) and holistic (end to end, happy path vs unhappy path). A quick wireframe is great in conveying the concept to broad stakeholders and facilitate conversation. However, a good design consideration would go beyond a few pretty mock up screens, and start to create an experience that is tangible.
It is not the most exciting part of design, and properly not the initial idea when people get into design. However, it is where we make creativity practical.
Also, don't overlook stakeholder management. Be mindful of sign off key aspects such as legal, risk, copy and brand. Some practices have been working in our favour for smooth delivery including, initial ideation (where I mentioned in my part 1 article), design jam and design critique. We have been using Google's design sprint - crazy 8 a lot to brainstorm design solutions, and design critique to take on peer review feedback, propagate design thinking and design patterns across different projects among designers. This may sound counter-intuitive, but I found design jam and design critique works best among designers only.
A thoughtful design leader would also look into how to balance pattern scalability and channel appropriate design. Ideally customers should be able to differentiate different environments, such as when people jump out from a secured channel (such as your internet banking), to an unsecured channel (such as a website). It sets the right user experience expectation. However, you don't necessarily want to create all unique and seperate patterns for the same information that appears on website, secured channel, and native mobile devices.
The last thing I want to mention, that is relevant to almost all roles, put nicely by a great designer friend, is try to maintain fresh eyes and remind oneself users don’t always know what you know. Ignorance sometimes is bless
3. What makes a right solution
Having been working with many developers and technologist before, I have seen frustrations from technologist on unclear requirement, constant changing of requirements, and/or rework of the solution. Technologists are makers, and they want to feel proud of their produce. And it just highlights how important a team collaboration is to make a happy team.
Put aside the discussion on collaboration (if you are interested, I have written an article on collaboration), what makes a good solution is an open and flexible solution that caters for future changes, and is balanced with the level of risk and frequency of changes.
You may have heard it a few times before "we don't like to hard-code it on the front-end." Or you may have seen an overkill architecture diagram that retrieve information over multiple layers of systems to the front end, for the purpose of keeping the solution future proof. It is not simple to agree or disagree either way. But a good technologist will ask the right questions to understand how frequents a change will be made to the solution, and whether the solution is resilient enough.
Do test your solution like customerS would. The reason I want to highlight customerS instead of a customer is we are building solutions for many users, and they may all have different scenarios and experiences.
4. What makes a good scrum
There are many articles and training courses on scrum and agile, so I won't repeat here. But I will mention some learnings that resonate with me most.
Sprint Planing: For pre-delivery phase of the team, where effort is focused on discovery and define specifically, clear objectives with stretch goals as options will bring everyone quickly into the same conversation.
If there are several initiatives happening at the same time, try to create them into the same scrum board, even though not everyone is working on all the initiatives. It brings the visibility of the tasks, and help the team to understand team capacity and dependency (if some people are working across initiatives). It also reminds people to check whether they have missed any important tasks by referencing other initiatives.
I found that break down the objectives with the team to understand the tasks in the sprint works better, because the team can see the inter-relationship and dependencies between tickets, and the big picture. Then it would make sense to self-allocate and align tasks to target dates.
A practice I would try to avoid is firstly define the team capacity based on days of availability, then ask the team to write the tasks that fit into their dates. I found it doesn't help working towards the sprint goal, and people either over-commit (because they know all the stuffs needs to be done for the sprint goal, but have no control of when it gets done), or lost the aspiration (because the deliverables based on the capacity won't match with the sprint goals).
For development ready phase, where effort is focused on story elaboration and estimation, a good way to find out the right amount of points is to ask what's the biggest tasks they've done before, and what's the smallest tasks they've done before, and work out the consensus of the score for this particular story (recommending using Fibonacci number)
Stand up: Yes we should keep some big discussions offline. But do allow people to take time to discuss the issues, especially it may impact other people's work. As a scrum master, working with people is more important than checking on the tasks.
Rush people to talk about what they have done yesterday, what they are doing today and what blockers they have, raises 2 issues. 1 is people don't have time to talk about the blockers specifically, and don't know who is going to resolve it (if they said it's a blocker, it means they need some help, scrum master), it also takes longer for people to regroup afterwards. 2 whether a ticket is done yesterday or not (if it's not because of a blocker) is not going to fundamentally change the outcome at the end of the sprint. It may well just be the nature of that particular work, or the velocity in a cycle of a week, The more important question is what in relation it has to other tickets and the sprint goal. Are we on track as a team towards the goal? Make sure individually we all listen up what others have to say, and how each of our tickets contributes to the sprint goal.
Stand up should be more than a status update, it is a great chance to discuss topics briefly when everyone is at the spot.
Retro: When retro is done right, it is so beneficial, and believe it or not, some hard conversations at retro create the opportunity to bond as a team. It is natural sometimes to feel down, but recognising the feeling is the 1st step to work on it, instead of pretending it to be fine, or trying to politely reframe the issues into positives.
Make sure retro is run fun and safe. Only when people feel safe, they will start talking about issues beyond the symptom, they will talk about their feelings, concerns and fears. Then we can take some actions that is going to work. Don't create a position that scrum master or PO is different to the team members. When there is a power struggle, when people don't feel they are equal, people won't be able to open up, fearing they are not good enough, fearing they will be interrogated and criticised. When people do open up, please please make sure scrum master and everyone who can help take the actions.
Some ideas to run a good retro (from my past experience and learning from seasoned scrum masters):
This may sound backwards: at the sprint 0, it's the critical time for team bonding, and ice breaking. Take time to know each other, take time to talk about personal wishes, aspirations, and what they want to get out of the project. And ask them to imagine what they would have achieved or learnt by the end of the cycle. At the end of the cycle, review the "crystal ball" to see the differences.
The other idea, instead of using "start, stop, continue", do a creative version of this. Draw a sailing boat, and ask people what's in their head wind, what's dragging their anchors down, and how are they sailing so far. Then categorise and prioritise topics for group discussion based on the votes, so we as a team can have deep level conversations.
If you know any good ideas to run a fun retro, please comment below to let me know!
Market Place/Showcase:
Artefact at the market place/showcase:
Customer research findings: either it be quantitative or qualitative research findings, summarise the insights to a coherent stories, and bring your stakeholders closer to the customer side. If you have customer interview verbatim or recordings, it helps people to resonate with their pain points.
Roadmap and visions: it's about a story, so vision statement and roadmap is a very powerful artefact to share with people. One of the thing we did is to create lego characters for our squads that are working on different yet inter-related part of the roadmap, with purpose-fitting character name, so people come to our room knows who we are and what we are working at.
UX flow and prototypes: sometimes, a futuristic idea is better conveyed via a prototype or a video. But be mindful of the time consumed to delivery the icing on top of the cake, and not take a big chunk of the team's time who are making the cake.
Delivered output: showing the audience what has been built and shipped to the market is one of the most exciting time that worth a good celebration. On top of the usual artefact, which you can proudly ask people to try the new product (either be open a website to check a new page, or on mobile app to check a new feature), there is another under-utilised artefact to tell development story: burn out chart. Burn out chart used right is a good tool to tell a story from development point of view. But don't overdo it as a reporting tool. Think of it as a quantitative data tool, it also helps discussion with product owners on time, budget, and scope discussions.
Purpose and output of Market place/showcase:
Market place (at casual setting) and showcase (at formal setting) are great opportunities to collect feedback from the audience and share your vision and purpose with broad set of stakeholders. A lot of case I have seen people treat this opportunity for 1 purpose only: sale! Yes it felt good, and yes audience were impressed with the presentation, probably learnt a few tricks on pitch and presentation as well.
However I think it is a wasteful use of the opportunities, when the purpose of show case is only for sale. With that mindset, people tend to exaggerate what they have done, over-promise what comes up, boast their egos and encourage unhealthy competition.
A mature team would take this chance and carefully thought through the format to collect feedback (set up a few talking points, share sharpies and post-notes around), be objective of the progress, share the lesson learnt (including what they have learnt from failure, what they would do differently next time) and focus more on the process instead of the outcome. And that's where a market place/showcase bring value to the organisation.
What role do you play in developing a product? And what do you look for in those key players?
Read my learning journal: PART 1: 9 learnings on the process of developing a product from discovery phase to delivery phase
Read my learning journal : PART 3: My personal growth, and how I took feedback in.
Back to my main index page: "What I have learnt about product management, agile, and personal development at a big bank"