The Product Leader’s Playbook: Elevating Quality Through Team Dynamics
In my previous article, I wrote about how to handle the different communication styles between business and tech. Now I want to share some ways in which you can strengthen the relationships with the team and improve product quality at the same time.
In my current organization, our vision is to be the life-long career companion of hundreds of millions of users around the world. Achieving this requires not only innovative ideas but also translating them into great user experiences.
A common challenge is when quality issues start popping up and getting in the way of building great features. You may find yourself squashing one bug only to find three along the way. Attaining the product vision becomes increasingly harder. You may think you need better developers... However, the root cause of a lot of these issues is where you’d last think of looking: You. How can this be?
User Stories
Let’s start at the beginning. You translated your product vision into a strategic roadmap. Everybody’s excited and ready to go. Now you are writing user stories, but how much thought are you putting into them?
If you think you need to write only ‘as a user, I want to… so that I can…’, and then the team is ready to develop an amazing product, you are in for a rude awakening. Expecting someone to build you the house of your dreams without explaining what that means to you is likely to end in a costly disaster. With digital products, we need to be clear and collaboration is key. I remember being shocked when the notifications on a notification screen were not displayed as the newest on top. It seemed obvious, but I didn’t specify it.
In my early days as a PO, I believed that detailed stories would limit developers’ creativity. I quickly learned that clarity promotes, rather than limits, creativity.
I’ve had many conversations about this with colleagues and friends who work in software development. They point out that when the business need is clear, devs can write better code that is secure, scalable, reliable, and bug-free. This is key in order to ensure a great user experience.
How can you write great user stories? It depends on the nature of your product and it’s important to discuss it with your team. From my work developing native mobile apps, I recommend having these items:
- Start with why. For this, you can use the usual format ‘as a user…’
- Include known blockers. There shouldn’t be any. This is for you to remember them and solve them before adding the story to the sprint.
- Include designs. In my case, these are links to Figma.
- Include API documentation. Your mileage may vary, but in my product these are essential. These are links to Confluence pages.
- Include detailed acceptance criteria. Emphasis on ‘detailed’. This is where you describe what you expect of the product.
- Attach any other supporting documents. Flowcharts, examples, etc.
Writing stories also requires time and concentration. Schedule focus time on your calendar. Lastly, facilitate the refinement session. Everything is negotiable. Invite the discussion and expect to edit the acceptance criteria during the session. Devs will build upon your foundation and that’s great! This is what makes the product even better.
How will this benefit the quality?
You need to translate your vision into actionable steps for the team to follow. When you wing it, the quality decreases and your product’s success is jeopardized. We’re working with an Agile mindset, and if changes are needed, we will adapt, but that doesn’t mean we do things carelessly.
My team appreciates how complete the stories I prepare are. During refinements, we make them even better. Devs point out that reducing guesswork allows them to build a robust product. Our top-rated apps and great client feedback are proof that this is true.
Beware of context-switching
The next way you may be inadvertently impacting the quality of your product is by yanking developers into multiple meetings every day or asking them questions constantly. Imagine a doctor performing brain surgery and, at the same time, there’s a riot happening next to them. That’s unlikely to turn out well. There are well-known detrimental effects of context-switching and it takes an average of 25 minutes to resume a task after being interrupted.
It’s easy to assume that since developers built the application, they have all the answers readily available about how everything works or why something doesn’t. One developer I work with told me that interruptions often entail more steps than are immediately visible: diving into the codebase, logging into the environment, reproducing issues, etc. This is time-consuming and disrupts the flow of work.
In my early days as a PO, I didn’t understand the focus needed to write code and I found it frustrating when devs asked me for time to think about a certain feature. Can’t they do it now? I soon realized that improvised code doesn’t translate into a great product.
When I joined my current team, I realized we had too many meetings. Almost 2–4 hours per day of meetings. While it is important to give devs context and for them to understand business problems, meetings are not where work gets done. We also had constant issues reported for our apps. We had to do some firefighting with hotfixes in order to solve critical issues. Clearly, something was off. I advocated for our team to reduce the number of meetings and we agreed to implement ‘no-meeting Thursday’.
This not only applies to developers, as a PO, I juggle multiple tasks, including doing discovery work and meeting with stakeholders, which makes me susceptible to the negative effects of context-switching. When I don’t prioritize time for deep work, I notice that the quality of my work decreases. This is why I choose my meetings wisely, disable notifications, and schedule quiet time in my calendar.
How will this benefit the quality?
When developers have time to concentrate and avoid context-switching, they can write better code and build a stronger product. They will feel happier because they have time to do what they love. This boosts their productivity. It’s a virtuous cycle.
Newly joined devs are consistently impressed by our intentional approach to meetings. Everybody likes Thursdays without meetings because it allows them to work for long stretches of time uninterrupted. Protect their time and yours. Prioritize to optimize productivity. Adjust as necessary.
Use retrospectives effectively
My favorite scrum ceremony is the retrospective. The purpose of this meeting is to improve the way of work and to promote continuous improvement in all aspects of the product. The whole team comes together and we discuss what worked and what didn’t during the sprint.
In order to encourage devs to speak up about what needs to be improved, I bring self-reflections to the conversation. Together we can find a solution.
Approach retrospectives with an open mind: Reflect on potential improvements, blockers you might have overlooked, and any misaligned stakeholder expectations.
In one case, I pointed out that our refinements were not very productive, because I didn’t know exactly how to split the stories (break down functionality into small pieces). The devs offered to meet with me separately so we could decide the best way to split the stories. This worked wonderfully and now I feel comfortable asking them for help whenever a new feature requires more pre-work.
How will this benefit the quality?
Feedback and continuous improvement are great ways to improve quality and trust in any team. Devs are not out to get you. They come up with great ideas to improve the product and point out risks getting in the way of achieving the vision. Value these ideas and suggestions, and act upon them.
Retros are also a great place to celebrate successes. Be generous with your recognition of the team, for wins big and small. The positive effect will compound.
Summary
As a product leader, you have a direct impact on quality without writing code. Ultimately, quality is a team sport. You can avoid a failed product launch as experienced by the infamous launch of the HealthCare.gov website, where devs were not given a coherent plan, and jumped from issue to issue. In contrast, Spotify is a company that actively tries to reduce context-switching for developers. They saw a 27% increase in premium subscribers this year, now at a stunning 220 million paid users. Clearly, they are doing something right.
Set up the team for success by preparing great user stories, minimizing context-switching, and being open to feedback. Together you can create a great team atmosphere where ideas thrive, which will help you achieve your vision and build a great product users love.
In my next article, I will highlight how to expand the collaborative environment to other important roles such as design, research, and key stakeholders across the organization.
