Product Management - 9 Keys to Success
Successfully managing product development and delivery is very challenging. However, there are some key things that Product Owners/Managers can do to increase their chances of success. Many of these may seem obvious, but are often under utilized or not used at all.
Establish a clear vision and strategy.
Create a roadmap for the product.
Identify and communicate business value.
Calculate and utilize return on investment (ROI).
Identify and capture customer/business value metrics.
Ensure product is ship-able / releasable at regular increments (i.e. sprints).
Maintain 2-3 sprints of refined backlog.
Prioritize backlog to maximize value delivery.
Leverage good release planning practices.
Don’t know where to start? Conduct a self-assessment using the Agile Kaizen Dashboard to determine where you and your team are currently at with each item. Then start your continuous improvement journey one step at a time until you reach the target state.
Agile Kaizen Dashboard - Product Section
Vision/Strategy
There should be a vision for each product, and a strategy to achieve that vision. This helps align the teams and creates a shared mental model of where the product is headed. If there isn't a vision/strategy for a given product, or if its not shared with the teams and stakeholders on a recurring basis, then it’s likely that the teams will lose focus on the bigger picture and instead become task focused. This can lead to unintentional blindness resulting in products that fail to meet customer needs. This can also lead to a culture that lacks motivation, innovation, and creative thinking.
Target State: Vision and strategy created, current, and is customer focused. All team members can express the vision and strategy. Teams leverage vision/strategy in backlog creation.
Continued Improvement: Vision/Strategy created and shared, but may be out-dated or not used when creating product backlog(s).
Needs Attention: Neither created, shared, updated, or utilized within 12 months.
Roadmap
Product roadmaps should show, at a high level, at least the next 6-12 months of value (typically in the form of Epics or Features) that is currently planned to be delivered. The roadmap should be shared and visible to the teams working on the product as well as with any stakeholders. Lack of a product roadmap may result in focusing on short term gains vs long term success. It also creates a challenge from a product planning perspective and often times leads to a reactive (fire-fighting) approach rather than a proactive value add approach.
Target State: 6-12+ month roadmap that is visual, includes context, has an anchor (customer), has position (relative to customer), and has movement (evolving). Roadmap has been created, shared, visible and current.
Continued Improvement: 3-6 month roadmap created, shared, visible, current, but may be not have all 5 elements of a good map.
Needs Attention: Roadmap is less than 3 months or doesn't exist, not visible or not shared.
Business Value Communicated
Communicating business value for a product and product features helps everyone understand why they are working on the product and what value it provides to the business. Ideally, business value is discussed during backlog creation and refinement with the team so that they have greater insight into why they are building each backlog item. It may also be discussed and communicated as part of the team’s goals (i.e. Sprint Goal, Release Goal, etc.).
Target State: Business value for product is known, visible to teams and stakeholders, and is communicated regularly when discussing backlog items.
Continued Improvement: Business value is somewhat known, but may not be clear, visible or communicated regularly to teams and stakeholders.
Needs Attention: Not known, communicated, or visible.
Return on Investment (ROI)
ROI is an important measure to determine value received from investments made in the development, enhancement, and support of a product. Product Owners/Managers should leverage ROI as one of the inputs into prioritization. It is also beneficial to share with teams to help them make better trade-off decisions at the technical level.
Target State: Return on investment (cost associated with development and support of product) are known, calculated, actionable and utilized by Product Owner/Manager. Empirical data from the teams is used.
Continued Improvement: Partial ROI info (cost or revenue) is known and calculated, but may not be actionable or utilized. Empirical data from teams is not used.
Needs Attention: Not known, calculated, actionable or utilized.
Value Metrics Identified / Captured
In an ideal state, customer and business value metrics for each feature built and released should be measured. Measuring value is one of the best indicators of whether you are building the right thing for the customer. It is also a key indicator to the success/failure of a product. If value delivered is unknown or not measured, it's difficult to determine if your product is on the right track or successful.
Target State: Metrics identified, captured and shared with teams.
Continued Improvement: Metrics identified and captured, but not shared with teams.
Needs Attention: Metrics not identified, captured, or shared.
Shippable / Releasable Each Sprint
One of the primary goals when working in short increments is to get backlog items to a “done” state. This means that they meet the quality standards agreed upon by the team and Product Owner/Manager. At a minimum, teams should ensure the product is in a releasable state at the end of each sprint. Ideally, teams will leverage continuous integration and delivery DevOps practices and maintain the product in way that it is releasable at any time. Build on cadence, release on demand!
Target State: Increments of work are completed in a way that makes them shippable / releasable (if desired by Product Owner) within a 1-2 week sprint timeframe.
Continued Improvement: Increments of work are shippable / releasable only some of the time.
Needs Attention: Increments of work are not shippable / releasble most sprints.
Refined Backlog
The product backlog should have a minimum of one sprint’s worth of backlog refined (i.e. ready to be worked on by the team). This is key to maintaining a “pull system” which improves overall flow of value via the product development team. On the other hand, there shouldn’t be more than three sprint’s worth of refined backlog when working on complex products. When dealing with complexity, we want to get feedback early and often to ensure we are building the right thing. This feedback generally results in changes within the backlog priorities. Spending time refining backlog items that are greater than three sprints out produces excess inventory and potentially over-processing which are both forms of wastes. The target is to maintain 2-3 sprints of refined backlog at all times.
Target State: 2-3 sprints of refined and ready backlog.
Continued Improvement: At least 1 sprint of refined and ready backlog (not including current sprint).
Needs Attention: Less than 1 sprint of refined and ready backlog, or more than 3 sprints of refined and ready backlog (over-processing).
Backlog Prioritized by Value
Product ownership and management requires prioritizing backlog items in a manner that maximizes value delivery to the customer. Thus, the backlog should be ordered in a way that reflects the anticipated customer/business value that will be delivered with each item. If value is not determined or known, then it’s very challenging to ensure that the product development team is focused on building the right thing for the customer and/or business.
Target State: Backlog items have an associated business and/or customer value, and the backlog is ordered in a way to maximize delivery of the defined value. Value is documented at the story level and above.
Continued Improvement: Some/most backlog items have an associated business and/or customer value, and the order of the backlog somewhat reflects this. Value is documented at the Epic level and above, but not at the story level.
Needs Attention: No associated business or customer value known/documented. Backlog not prioritized based on value.
Release Planning
A release plan needs be created and maintained for the product. It should include an estimate to deliver all of the backlog items by the targeted release date. A release burndown reflects the progress towards the release plan. Product Owners/Managers often times need to make trade-off decisions based on the team’s capacity to deliver what is planned within the given timebox. New priorities may arise causing a change to be made to the plan by removing lower priority scope, changing the date, or figuring out a way to increase team capacity. If attempting to add capacity, Brooks’ Law should be taken into account.
Target State: Release plan is created and contains estimation for backlog items (i.e. using large effort estimation), release burndown is being used, team capacity is known and calculated and plan is inspected and adapted each sprint.
Continued Improvement: Release plan created but missing some of the elements stated above or not updated every sprint.
Needs Attention: Release plan does not exist.
Final Thoughts
As a Product Owner/Manager, are you utilizing these tools and techniques? If not, you might want to strongly consider incorporating them into your product management practices. There is a lot of great information and resources out there regarding each one. Check back later and you might find a deeper dive into each of these in future posts on the dailyscrum.co!