Every year organizations are called upon to put forth their views on the 3 year horizon, and part of the Product Management role includes participation in this planning process. While many of the strategic decisions get made at an executive level, it is your role as a Product Management leader to covey the importance of your product(s) with respect to solving for the market needs such that it is clear how it supports (and is integral to) the overall strategy.
An interesting component (and expectation) of any strategic plan is an emphasis on quality. Without it, customer satisfaction will suffer, customer attrition could become an issue, and/or customer references will be hard to come by. But should quality be considered a strategic initiative, or is it more tactical? And as Product Management leaders, what is our role in ensuring quality?
These conversations have popped up recently, and I thought it appropriate to share 3 perspectives I’ve gleaned throughout my career. Enjoy.
1 – Make sure you account for technical debt – One thing you can be sure of, there will never be a shortage of requests for new capabilities in our products. Whether they originate from customers, in response to competitive analysis, as part of market research, or because of technological advancements … they will always be there. The other thing you can be sure of is you can never deliver fast enough to satisfy all of the major stakeholders (which is why having a prioritization approach is so important).
Our role, however, is not just to prioritize enhancements and produce a compelling roadmap, but also to ensure we account for technical debt along the way. It is way too easy to utilize 100% of your resources on new features. But in doing so, you are putting future quality at risk. Consider this quote on the topic …
Doing things this way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development.
Always set aside a portion of your capacity to address technical debt … inclusive of, but not limited to: fixing bugs, addressing architecture issues or poorly implemented code, upgrading software/databases, platform consolidation, etc. The ratio of new feature development vs. technical debt is something you will need to negotiate with your engineering cohorts.
2 – Ensure you are involved, and have a contingency plan – Another thing you can be sure of, things can and will go wrong occasionally. And what I have found throughout my career is a generally good response process to bugs that happen along the way.
What I am referring to here is a natural tendency with Product Management leaders to absolve themselves when it comes to platform upgrades and/or platform consolidation. The assumption of course is the engineering team knows the technology and will put the appropriate procedures in place to avoid problems. Generally this is true, and 9 times out of 10 no problems will arise.
But the 1 time out of 10 something goes wrong, you will be called to the mat. And taking a DAK approach (deny all knowledge) will not serve you well. Have a look at my post Anticipating the Unexpected, Preparing for the Worst for more here.
3 – Having a quality mindset – The reality is as the Product Management leader, you own the product … end-to-end. So approach things with a quality mindset from the outset when user stories/user scenarios are being developed.
I really like how the conversation plays out on this post. Here are a few snippets:
true quality assurance does not start when something is ready to be tested—it starts at a product’s conception … A quality mindset must be present throughout every portion of the product development cycle: requirements gathering, design, development, deployment.
Quality derives not from having certain pairs of eyes on the product for testing once it’s close to deployment — it’s about having everyone’s eyes on the product throughout the process.
Product managers, by virtue of their role, have the broadest knowledge across all the components of the product. Even lacking specific depths such as UX design or engineering, good PMs can spot issues across all the functional disciplines.
Through all my observations as a PM, a combination of engineering excellence and product-centric requirements validation covers 90% of all of the quality assurance needs.
The conclusion relating back to the questions leading into the post? Whether you consider it part of the strategic process or more of a tactical initiative … it is something Product Management leaders cannot afford to ignore!