Labels

6 Easy Ways to Lead Product Owners and Drive Meaningful MVPs

It isn't easy to put governance and guardrails on product managers and product owners. You trust them to engage customers and prospects across segments, capture needs from users of competitive products, and understand strategic requirements of internal stakeholders. You task them to develop product visions that deliver value and convenience to end users. You ask them to engage designers to develop winning customer experiences and you expect them to collaborate with technologists to seek out feasible solutions.

And then they sometimes come out with an MVP that is totally unrealistic to implement. In my last post, I shared 10 critical mistakes products owners make when developing MVPs and suggested that many of these mistakes occur because of inexperienced product owners or when there isn't any form of governance or guardrails in place to manage them.

Organizations investing in digital transformation programs that include customer facing application development need to think long term. Open investing in new products is important, but over engineering features, underinvesting in technical debt, or developing applications misaligned with the technology platform and architecture strategy will likely drive a new generation of legacy applications.

Driving Product Owners to Meaningful MVPs

For this post, let me share six ways you can put some basic governance on product owners. Three of these help drive team alignment and the other three are operating metrics.

Product owner and team alignment

Develop impact assessments of features developed - As product owners develop features, make sure they have mechanisms to measure their impact. Measuring impact is easier to do in ecommerce where you can capture customer journeys and sales, but it may take some creativity to understand in workflow applications. Even when measuring impact isn't a perfect science it can still lead to fruitful dialogs with product owners on the features they sponsored, the overall cost of the feature and the impacts they made with end users.

Bound product timelines by a defined release management strategy - A product owner often thinks of maximizing the value being delivered (often in features) for a target product release date that can be several months out from the start date. But the engineering team should already have standardized a release management strategy and the combined team should break down a product release into several engineering releases. Why? Well for one thing, the engineering team should be optimizing their cadence, velocity, and working practices to these release patterns so it's far more likely that the product owner will get a higher velocity and product quality by leveraging them. Second, the product owner should use these engineering releases as alpha or beta releases and test impacts with end users. It's a discipline that forces product owners to make sure high priority features work well before they prioritize secondary needs.

Review go to market strategies for the prioritized features - The question here is whether the product owner has thought through how to market and operationalize the feature. To do this, it's a good idea to have a session where the product owner reviews a high level rollout plan with the implementation teams and where questions are encouraged. Asking for the development of features without plans, or when rollout plans are too big or complex are strong signs that the product owner is asking for too much. Similarly, the team may contribute new ideas to either simplify or enhance the user experience. Lastly, it's a good idea to find out why the product owner prioritized the features, what customers or end users will benefit from it, and what value proposition or need it addresses. All of these questions are designed to help narrow down the feature set to the ones most valuable.

Product owner backlog metrics

Driving Digital -

Chapter 2: Agile Transformation

Chapter 6: Digital Products

Account for technical debt and support issues - If you're giving product owners authority to prioritize 100% of a team's velocity (or multiple teams) then that may be a critical mistake. Teams should also be committing part of their velocity to address technical debt and support issues. I look for a rough allocation of 50% dedicated to technical debt and support issues and 50% to new capabilities. Even more powerful is when the priorities of technical debt issues are managed by the technical lead or architect, and support issues by an operational lead. They can then be held accountable to provide their own impact assessments (see point 1).

Challenge and limit the number of large stories - If you're estimating agile stories with story points then that provides a measure of both effort and complexity. Asking teams to deliver on a large number of high-point stories is a risk; either the product owner is asking the team to build features of high complexity, or the team is struggling understanding requirements, or the team is learning how to keep implementations simple within the selected technology platforms. Regardless of the reason, it's a good idea to question product owners and teams that have a larger number of high point stories scheduled for a release.

Ensure there is a reasonably defined backlog - If product owners are finalizing stories just before the next sprint's commitment, then it can be challenging for teams to estimate and deliver on expected requirements. If you leverage my estimating methodologies (Chapter 2 of Driving Digital) , then I recommend the product owner have a backlog of at least two sprints of fully written stories (upcoming sprint plus one) and an additional two sprints of story stubs.

Who should provide oversight on product owners?

With some guidelines and governance, organizations need to consider who should oversee them. If there's a PMO, then providing this oversight is a natural extension of their responsibilities. In smaller organizations, CTO / CIO that have product responsibilities can provide the oversight. Otherwise, these oversights can be implemented in practices (for 1-3) and via metrics captured in tools (for 4-6).