Site Overlay

Sharing Quality with Product

The relationship with Product from an engineering perspective can be either fun or a complete disaster, and I was lucky enough to experience both up until today. Working around Quality, especially when focusing on feature development, can come with its own set of challenges from this perspective (remember those quality improvement tickets that always get “re-prioritized”?). You know what? You, reading this: there are quite some things that are in our own hands to make things work. I’ve seen many strong and knowledgeable Quality professionals fail at building successful relationships with Product, mostly for the following reasons:

  • Investing energy in activities that are assumed to bring improvements, but are not actually needed
  • Taking sides (Engineering vs. Product)
  • Knowing that 100% Quality it’s nuts, however still expecting that
  • Doing everything by oneself, or just inside a defined QA group
  • Forgetting that this is not a high speed race, but rather a long journey to enjoy

I’ve found myself in all of the above and it creates tension, loss of own and team morale, it questions one’s purpose, and it delays every possible positive result. Don’t fall into the same trap! Be wiser: this would be a great moment to consider a Quality Assistance model, and the following hacks can help you get started and keep your sanity level up: 

  • Make them understand that, as clients, it’s within their scope to define what quality they want their product to go out with, and to reflect that in the backlog, in the requests, in a roadmap, in the priorities they set, or in the Sprint Review Sessions.
  • Align the working model and processes with Product: whether it’s Quality Assistance or more classical approaches, it is important to be on the same page, to understand where to invest energy and  what can be achieved with the available resources. 
  • Let them draw a quality roadmap together with the team. Don’t do that for them. Instead use your knowledge and technical skills to facilitate the conversation, and bright up the conversation with ideas. Both the team and Product should understand that they actually own this plan, and it’s in their own hands to make that happen.
  • Have honest, open, constructive, human conversations about what drives your motivation, and what kind of activities make your day, and which don’t and think might be a complete waste of time. This should happen on both ends. One might be surprised that some things don’t really need a huge change management to improve. 
  • Define and follow quality metrics, and make them meaningful for the Product. This would actually empower the investment in quality. Do check out my post regarding metrics. 
  • Even with metrics, roadmap, working processes aligned, Product might still prioritize new features over stability and quality, old approaches vs. new, even when everything points out to the opposite. Let product be the driver of the quality roadmap, and let them understand that if they need to have something done, it’s on their hands to prioritize that for the team, and Quality should be helping with the tools to make those decisions in the most conscientious manner. Real and relevant information can be successfully ignored until the foreseen risks have been turned true once. 
  • The team itself is owning Quality: together with SMs, TLs, POs build a comfortable process that empowers quality, teamwork and brings the right level of confidence so Devs and Product can speak about Quality comfortably. 
  • Shape-shift, don’t hesitate to play different roles to help product achieve the roadmap. It makes things fun as well. There are many more ways to improve Quality than doing just Functional Tests: explore potential improvements in Site Reliability, Infrastructure, Processes, Performance, Visual Performance, Monitoring, etc. 
  • Start pursuing your CTO and CPO to think about a cross-functional engineering-driven team, which will not own new features, but instead help other teams which do to build them better. In a future article I’ll be writing about why organizations which are focusing on just getting features out there, might not make it in the Quality Assistance Road.

As Quality is traditionally trying to make Engineering and Product better speak their own language, being a facilitator doesn’t mean being the middle man. Acting like one will result in getting things lost in the middle, while assisting will help all parties arrive further. Which one would you rather do?