Product managers serve many constituencies – customers, partners, development, operations, marketing, sales, support, finance, etc. While they would like to be considered to be the CEO of their product, they’re not. Product managers inherit constraints that are set by the CEO or other executives in the company. A core challenge for product managers is to use their influence to optimize how all parts of the organization work to achieve the product and company’s goals. A key way to grow influence is empathy. Empathy is a critical product management skill. Having product managers and product owners build a project to enhance their product backlog prioritization calculations using a low code platform might be a good way to build empathy. Sometimes a little dogfooding goes a long way.
Empathy Is A Critical Product Management Skill
A key way for product managers to build influence is empathy. As pointed out by ProductCraft:
Empathy in product management means being able to slow down enough to listen and observe, humble enough to learn and change, and able to not only know what someone is dealing with but to feel and understand it with them.
Why Empathy Is Critical to Success as a Product Manager
While most product managers have a technical background, they usually are not former developers, QA engineers, or Operations experts. Yet the success of these groups is directly tied to how well product managers do their jobs. Do they understand the product vision? Do the user stories and backlog items make sense? Are the acceptance criteria reasonable and relevant? Does the prioritization of backlog items make sense?
It’s Time for a Little Product Management Dogfooding
One of the best ways for product managers to build empathy with their Agile teams is to ‘walk a mile in their shoes Product leaders should consider an internal project where their product managers and product owners build and deploy a small application using today’s low code tools like https://appian.com/, https://www.outsystems.com/, or https://www.mendix.com/. The team should go through the entire product life cycle:
- Conduct Product Discovery activities
- Build a Product Vision
- Document User Stories
- Decompose User Stories into Product Backlog Items
- Prioritize Product Backlog
- Conduct Sprint Planning Sessions
- Execute Sprints
- Conduct Retrospective Ceremonies
- Deploy to Production
- Monitor Production Performance
- Groom the Backlog
- Rinse & Repeat
The team should follow their own product management methodology. They should produce the same deliverables that they do for their products. A little dogfooding can go a long way to helping product managers build empathy with their constituents.
This is not a project that can be completed in a week. It is something that could span months. Today’s low code solutions, however, can significantly accelerate the process. Low code solutions can help make up for a lack of product manager technical skills. The product team should seek guidance and help from their development, QA, and operations counterparts. Collaboration on a project like this can help build strong, authentic relationships.
Low code solutions allow product teams to quickly define deliverables like web pages, process flows, databases, and even integrations to other systems. The tools can then generate the application and deploy it to a production environment like Amazon Web Services. The majority of these deliverables can be defined using wizards or other graphical techniques. Some coding may be required for complex business logic, but mostly product managers can build and deploy applications by themselves. They can become citizen developers. Here is a short 2-minute video demo of one of the low code platforms – Outsystems.
The Enhanced Backlog Prioritization Project
Project Overview
A good project for this empathy exercise would be a tool to enhance your current approach to prioritizing backlog items. The priority in which items are added to Sprints is always contentious. Product has one set of priorities, development another, operations, sales, support, and executive management have their own priorities. The goal of the project will be to build a SaaS tool that
- Extracts backlog items from your Agile tool (Jira, Azure DevOps, GitHub, etc.),
- Provides a new prioritization technique that matches your company’s prioritization method
- Allows you to visualize and experiment with priority changes
- Exports the new priority values back to your Agile tool
The tool should run in the cloud on your company’s current cloud provider (AWS, Google Cloud, Oracle Cloud, Microsft Azure, etc.) The team should use your current QA tech stack, as well as your CI/CD and systems management technologies.
The tool should be your version of the Ducalis product but tuned to your company’s particular needs. And free.
Depending on their backgrounds, product managers should be able to execute the project on their own. They may need some support from developers, QA engineers, database admins, and operations engineers as they work through the project. The kind of help these resources can offer provides an excellent opportunity for product managers to build empathy with their constituencies. They will see firsthand how their deliverables like product visions, user stories, and acceptance criteria help or hinder the mission of getting an application built and deployed.
Product Discovery
The project should start by having the product managers conduct their normal product discovery processes. The team should conduct primary research like interviews or focus group sessions with every part of the organization that is impacted by backlog prioritization decisions – developers, QA, sales, marketing, operations, and even executive management. What aspects of the current prioritization process are working well? How have prioritization decisions led to bad outcomes in the past? What should be improved in the future?
The outcome of the product discovery process should be a definition of the market problems that need to be solved, and what the scale of potential benefits could be if they were solved.
Product Vision
Next, the product managers should develop a product vision for the Enhanced Backlog Prioritization product. Here’s where the dogfooding starts. They should use the standard product vision format they use in their day-to-day work. Every company has its own methodology for product management. A product vision should address:
- What’s the target group?
- What are the customer needs?
- What is and will be the product and its Unique Selling Propositions?
- What are the business goals?
Product managers will be able to see how effective their product vision is as they work through the project.
Themes, Epics, & User Stories
Next, the product managers should define the themes, epics, and user stories for the Enhanced Backlog Prioritization product. They should be documented using whatever tools and technologies they use on a daily basis.
The user stories should be prioritized based on your company’s existing prioritization scheme. Again this is another opportunity to build empathy. The team will also be able to test the validity and comprehensiveness of their user stories.
Decompose User Stories into Product Backlog Items
Next, product managers should decompose the user stories into product backlog items. They should be documented in your backlog management tool like Jira. At this point, the product managers take on multiple roles. PBIs are usually developed by the Scrum team that includes product owners, developers, QA resources, Ops resources, etc. For the Enhanced Backlog Prioritization project, the product managers will be playing all of these roles. While they might be supplemented on occasion by actual developers or QA engineers, the product managers will be the Scrum team. At this point, they will literally be eating their own dog food.
An important aspect of defining the product backlog items is acceptance criteria. Acceptance criteria define the clear and complete conditions that a backlog item has to meet in order to be implemented, tested, and completed by the Scrum team. Acceptance criteria are often a source of friction between product management and Scrum teams. The Enhanced Backlog Prioritization project gives product managers the opportunity to see how their approach to acceptance criteria impacts the Scrum team in a very direct manner.
The backlog items should be prioritized using the existing prioritization method.
Sprint Planning
The next step is to start the Sprint cycle. Some companies’ approach to Agile calls for release planning or if you are a SAFe shop product increment planning. For the purposes of the Enhanced Backlog Prioritization project, you can assume there will be one release or product increment.
The Sprint duration should be equivalent to your current Sprint cycle. A challenge with the Enhanced Backlog Prioritization project is that it is usually a part-time assignment. Product managers still have day jobs. The duration of the Sprint will depend on how much time the team can devote to the project. One scenario is three days every two weeks. The Sprint duration could then be approximately one calendar month. It all depends on how leadership wants to prioritize the Enhanced Backlog Prioritization project.
Again the team should use your standard approach to Sprint Planning. The Sprint goal should be developed and agreed to. Backlog items should be selected and sized.
A key aspect of Sprint Planning involves your company’s Definition of Done (DoD). For some companies, DoD means that all unit, integration, system, and user acceptance tests are completed. Other companies extend it to deployment in pre-production. Whatever your DoD is, it will impact how many backlog items can be completed in a given Sprint.
Sprints
Next, the team should start executing the Sprints. They should conduct standups every day the team is working. Progress and burndowns should be tracked using your company’s standard tools (Jira, Azure DevOps, etc.)
The learning curve of the low code tool you choose will impact the team’s productivity and velocity. Other required tools, like QA automation, CI/CD tools will also have a big impact. Product managers are usually not former developers. This is where collaboration with developers, QA engineers, and Operations engineers will help. Low code tools can simplify a lot of this work, but they are low code solutions, not no code. Remember, the goal of this project is to build product management empathy. A key way to build empathy is to walk a mile in their shoes.
Retrospectives
At the conclusion of each Sprint, a Retrospective ceremony should be held. A retrospective is intended to reveal facts or feelings which have measurable effects on the team’s performance, and to construct ideas for improvement based on these observations. It will not be useful if it devolves into a verbal joust or a whining session.
Retrospectives provide a great opportunity for product managers to assess and identify improvements to their standard product management deliverables. How effective was the product vision in guiding the team? Were the user stories and product backlog item definitions complete and helpful? Were the acceptance criteria reasonable? There is nothing like having to eat your own dog food.
Deploy to Production
Next, the application should be deployed to production. Most low code solutions can automate a significant part of this process. It may take some effort and coordination with the Operations team to set up the production environment initially.
Getting insight into the mechanics of production deployment is a great experience for product managers. Often, their only experience is dealing with production deployment failures. Again, this is another opportunity to build empathy.
Monitor Production Performance
The team should use your company’s standard tools to monitor production performance. Is the product usage what you expected? Are there spikes or dips that you did not anticipate? Are the page loading times acceptable? Are there any unplanned outages? Are the production costs of the cloud environment okay? Seeing what the Ops team and others do on a daily basis will give product managers insight into the capabilities and limitations of their current system management tech stack.
Groom the Backlog
Every month during the initial build and after the initial production launch, product managers should groom the backlog. They should use the same process and tools they use in their day job. Have any requirements changed? Does the priority of specific backlog items need to be adjusted? For fun, the product leader should throw a curveball every now and then. They should arbitrarily mandate the acceleration of a specific backlog item. It is always interesting to see how Agile teams react to arbitrary decisions that are mandated by executive stakeholders.
Rinse. Repeat
Developing product management empathy is not a one-time event. It takes time, patience, and repetition. Most product management organizations cannot afford to dedicate their entire team to a project like the Enhanced Backlog Prioritization project. You should consider starting with a small cohort of three or four people. You can then repeat the project with another cohort. Keep repeating until the entire organization has had their ‘turn in the barrel.’Consider an abbreviated version of the Enhanced Backlog Prioritization as a tool to onboard new members of the team.
Recap
Product managers and product owners cannot direct what should be done for a product, they have to use their influence. Regrettably, they are not the CEO of their product. Empathy with Development, QA, Operations, and even Executives can go a long way to building influence in an organization. A little dogfooding may be a great way to build influence. A project to build a new solution to improve the prioritization of backlog items using a low code platform may be a solution product organizations could consider.
If you would like more information or help on helping product managers eat their own dog food, drop me an email at john.mecke@developmentcorporate.com.
Also published on Medium.