In the previous entry of our series ‘Product Management from the Trenches’, we explored how to enrich the backlog for better strategic vision. Today, we will build on this foundation to address how to effectively manage the bandwidth of product teams, a critical challenge for any CPO.
Initial Challenges#
When I started working as a CPO, although several teams were already working with agile methodologies, there was no clear mechanism for prioritizing and assigning initiatives. In reality, epics were assigned based on: 1) the track record of functionalities a team had developed, attempting to keep that team for further enhancements of those functionalities; 2) if it was a new functionality, it was somewhat of a round robin, considering what a product owner (PO from here on) thought the team could handle, summarizing a bit like a feature factory without much strategic thinking for the teams.
With this starting situation of already working teams and me being new, my main question to resolve was how much bandwidth was available to make product, which meant understanding what the development teams (which would soon be product teams) were doing? And if they were building the right things that needed to be built?
Let’s delve a little more into each question, regarding the first, with the enriched backlog we saw in last week’s entry, I could understand some of the initiatives but didn’t have a complete picture of what the teams were dedicating their time to. So, I decided to do a bit of genchi genbutsu, which means going directly to where things happen to better understand the processes, talk to the product owners and understand their day-to-day beyond just the prioritization session, and I realized that the POs were 1) writing all the user stories 2) providing technical assistance to the developers 3) performing operational service exploitation tasks among other things 4) they were flooded with requests from land, sea, and air: apart from the prioritized initiatives, there were a multitude of stakeholders sending them tasks, via email, WhatsApp, a corridor conversation, very informally and without much detail and they assumed (wrongly) that the PO had to take note of the order to perform the equivalent task, with the corresponding messes.
The second question has more to do with the strategy and objectives to be met by the company, that is, what percentage of the things we were doing was in the direction the company had planned? That is, how did those initiatives align with the company’s strategic objectives, with the enriched backlog we began to assign, but we did not have a high-level picture, we had a very high zoom level which did not allow us to be at the correct level of abstraction to make more strategic decisions.
Also from last week’s entry, we had mentioned that typically teams can divide day-to-day tasks into three categories:
- What I call features, allow me to add here some more detail that I didn’t include last week, when I talk about value creation, it’s a misuse of language because as a PM, in my mental model, each functionality has to serve a purpose and can be value creation, like revenue generation, improving customer engagement or just being a hygienic functionality, that is, if you don’t have it it may produce rejection in your customers, it really doesn’t add much value but you have to have it (example, user login). Similarly, a CPO must understand that each product serves a purpose but we will talk about this another day.
- repetitive operational tasks
- bugs
On the other hand, as product managers, one of our main tools are the data which allow us to make informed decisions about our roadmaps and the initiatives we undertake. I’ll discuss this in more detail in another entry, but one of the principles I try to establish in my teams is being data-driven, or as the NASA saying goes, “In God we trust, all others bring data.” In my context, since there was no product management function previously and presumably due to lack of knowledge, there wasn’t much information available to make these types of decisions beyond the tool that the development teams used to document the agile process (in this case, a ticket-based tool like Jira) whose reporting module was not very developed.
Therefore, let’s review the situation: we didn’t have much of an idea of the bandwidth that the teams had for working on products, tasks of various types came in a very unstructured way, we didn’t have access to much data, and the tools that were available had not been developed to provide good reports.
Solution Implementation#
To address this issue and again adhering to first principles without resorting to sloppy tools, what I decided to implement were three Google Forms, one for each type of task: 1) functionalities, 2) operational tasks, and 3) bugs. This simple action would allow me to achieve four objectives:
- Homogenize the input of information, improving the quality thereof and providing the necessary detail so that this information could be actionable and prioritizable.
- Curtail the influx of massive requests by adding some friction. Even though the forms were simple, the mere fact that the stakeholder had to stop and think and write down the questions we posed made them reflect on the real necessity of the functionality, thus only opening the request when it was really necessary. Sometimes a bit of friction is a good thing.
- Begin to gather data on the volume of requests to the teams to understand the bandwidth dedicated to each type of request: functionalities, operational tasks, and bugs. A note here for the more intense fans of product management, ideally, you would work with data regarding the impact of the initiatives on your strategic objectives, but we were so far from that mindset that this approach seemed a good balance, conclusion: if you can’t start by measuring outcomes and impact, start with output and iterate from there.
- Having the information homogenized and located in one place, such as the spreadsheets associated with the forms, was going to lay the foundation for creating dashboards about the task backlog to understand the direction of the teams.
Additionally to these forms, we added a small internal development, which were a couple of App Scripts that allowed transferring the information from these forms to the enriched backlog once the incoming information was qualified.
Results and Observations#
After implementing this mechanism with the Google forms, we noticed a reduction of over 50% in informal requests and increased the speed of delivery of the teams by not having to chase stakeholders to gather the information they needed to work, in addition to allowing us to adjust workloads with greater precision and strategic alignment.
Thus, if we take a partial snapshot of our product operating system so far, focusing on the problem space, we would have something like this (in other entries we will paint a picture of this entire product operating system version 1):
In the diagram, each shape represents a different aspect of our product processes. In orange are those processes derived from using the forms to qualify a request and, if it is high impact, to add it to the prioritization session for a brief discussion about it; if not high impact, it remains at the discretion of each team to decide what to do with the request, whether to reject it or proceed with it. This would gradually empower the product teams.
On the other hand, in green, I have depicted the relationship with the rest of the stakeholders with whom, as a CPO, I had recurring alignment sessions to review the needs they might have regarding the product team. Again, each of these requests was evaluated in terms of value and technological feasibility before being added to the backlog.
Conclusions#
In summary, in this entry, we have learned how important it is to know the bandwidth that your teams have to dedicate to creating value and that with small tools that allow us to introduce a point of reflection, homogenization, and structure, we will be able to build a small product compass based on the outputs of the product teams in an environment where the product mindset is still being developed.
In next week’s entry, we will see how to build dashboards using this structured information.
I hope you enjoyed the entry, tell me if you have faced these types of situations yourselves, how have you resolved them, would you have directly established measurements around the impact? Write to me to tell me!