Product Management in Continuous Collaboration
There is a video I show to every product team I interact with, in which Janice Fraser conceives of how to be a product manager on a balanced team. I watched her talk the first week I joined Pivotal Labs, and it resonated with me. In it, she pushes against the trope of the “product manager as CEO,” reformulating the product manager's role to be the scales of justice. For Fraser, product managers make fast concrete, actionable decisions without adequate information. Their authority lies in making decisions as a service to the team.
I want to build on Fraser’s idea of service to address how we might practice product management within a continuous collaboration. And at the end of this piece, I’ll touch on a tension I have been feeling about my own role as a product manager.
The product manager seems best positioned to understand how to break down a potential problem or solution into small, testable pieces at the cross-section of value between business and users. The strategic thinking that goes into breaking down, sequencing parts, and determining the right measures requires time, effort, and skill. There are times when the team can facilitate their way to strategic decisions. More often, the product managers I work with do the initial work of laying out the shortest possible path for the team to get a product in the users’ hands, and define the leading indicators for success. Where product managers can bring something concrete to the team involves knowing what is valuable, what small chunks of work will move us towards delivering that value, and how to measure that delivered value.
While the product manager is primarily responsible for the strategic choices of breaking a thing into small testable/shippable pieces, we cannot forget about continuous collaboration. Each component on a balanced team delivers quality inputs, which we scrutinized with rigor, and agreed upon through systematic consensus. It does not let anyone off the hook and encourages healthy feedback that is best for the whole. There are two primary places where this occurs for a product manager: a roadmap and a backlog.
Let’s talk first about the roadmap. Once a problem or solution has started to emerge, the product manager, with the team’s consent, finds time to construct how to deliver value, balancing both the users and the business. They chart the course of small, testable units by defining the outcomes that, if achieved, would deliver that value. In this case, the outcomes should be leading indicators that suggest the team has invested in the right features to drive their core outcomes, which often lags. For example, if the team identified cost savings as a core outcome, measurable results may take months to be detected, creating a lengthy feedback loop between feature release and measurement. Therefore, the Product Manager puts forth outcomes with leading indicators as part of the roadmap to ensure the team is on the right track. They must understand what user or system residue indicates the desired activity and how they might measure it. For example, “What will be recorded in the database to suggest people are using this?” “How will people navigate through the app?” “What will our bounce rate or time on site do?” By targeting leading indicators as outcomes, we can ensure a quicker feedback loop between build, measure, and learn.
Once the tentative plan is drafted — or perhaps even during — the product manager shares the strategy with the team as a way of inviting scrutiny and maximizing transparency: “Tell me your thoughts?” “How does this feel?” “What other risks are ya’ll seeing that I have missed?” “Tell me about how these leading indicators feel?”
When we have consensus, where no one has objections (or is willing to wait and see what transpires), we can move forward until we encounter new information. The construction of this strategic document will have a tangible effect on team members’ lives. The product manager’s responsibility is to create a moment of consent and provide visibility to foster collective ownership. Additionally, aligning on how we measure success within the team promotes solidarity through alignment. So while the product manager completes the initial work, there is a continuous collaboration with all parts of the product team.
Next, take the backlog. The backlog consists of user-validated work that engineers can deliver in the next couple of weeks. The stories contained within it combine the product manager’s definition of value and acceptance criteria, the designer’s visual assets, and the engineering team’s estimation of complexity. It is an accumulation of the collective effort of the group.
Product teams grant the responsibility of maintaining and organizing the backlog to the product manager. In the backlog, the strategic choice is in determining how to move in the shortest path to get working software to its users. The product manager may add, subtract, or move things around based on new evidence. Crucially, these decisions require transparency both before taking action and after it’s complete, especially when a change may affect work in-flight or near-term.
For example, I may work with a designer and say “after digging through these XML blobs, we can more easily deliver this other data type. Let’s talk about user value.” I may turn to the engineers and say, “Heads up, the backlog is shifting because of this data situation. Let’s catch up.” If the changes to the backlog match what we discussed then no further conversations are needed. If they have changed since the conversion, I may check in to ensure transparency. Some may say this is gratuitous communication, but in a world where we build products collectively under conditions that maximize creative potential, this seems to be the level of communication needed.
As a product manager, my responsibility is to determine how to break down a problem or solution, get the team to produce something for users in the shortest responsible path, and measure the results — quality strategy delivered for the team.
We are not only liaisons or project managers or schedulers or translators. We play an active role on a product team, providing strategy within the context of continuous collaboration. But alas — it is not that straightforward if we are product managers who are attempting to create social relations of production that are fundamentally humanizing. I am going to briefly explain myself here and elaborate in a future post.
More often than not, the core outcomes we define are tied closely to the business’s ambition to make a profit. For me, this is in tension with the pursuit of maximizing creative potential outside the product team. The process of doing user research (learn), creating a tool or concept (build), and testing how well it resonates (measure), placed towards profit, feels exploitative. If we recast the above cycle, it feels like we are doing the following: extract feelings, desires, aspirations from people, abstract those intimate human conditions away into a digital tool, and exploit the market opportunity to sell that tool back to them. This process is all in the name of building “good products” that achieve outcomes (as opposed to outputs), which product teams need to maximize their creative potential and keep reproducing. As with anything we are trying to make more human, we have to experiment with how to remove this tension, which will take more than me to figure out. A solid first step, for now, is simply acknowledging its presence.