Product Teams: Thriving From the Ground Up
As I have written about previously, a product team is a heterogeneous group of individuals who self-organize—a collective unit of cross-functional people working collaboratively to maximize their creative potential while they solve a problem.
In my experience, the product team generates friction within the structures of traditional organizations. Navigating this friction from the ground can be difficult for product teams starting off or under new management. We have to educate, defend, push back, and demonstrate why product teams are a preferred mode of production. It requires convincing those in power to relinquish management by directives, instead focusing on setting a vision and letting teams operate. It requires us to push leadership to create spaces of autonomy, teaching leaders how to hold teams accountable in new ways. It asks us to be transparent about our progress and processes to model how empowering transparency can be. As we encounter new business units or leaders unfamiliar with our product team approach, we find ourselves repeating this process. In this way, the product team is antagonistic to the firm. Nevertheless, product teams are highly effective at delivering value to users (and there is little direct, worker radicalism in enterprises), so the trade-off is worth it. Most often, the product team is Socrates’s gadfly in the enterprise.
So how do we ensure product teams thrive from the ground up?
Shift from outputs to outcomes: The single most crucial task for product teams in an enterprise is to create the space to explore problems and solutions. We express outcomes in motion verbs — “increase”, “decrease”, “improve”, “reduce” — and measure them in rates or ratios. Outcomes do not assume a particular implementation, and as such, they allow the team to explore the domain. Individual product teams should demand core outcomes from their stakeholders or leadership. At their simplest, core outcomes are standard — improved efficiency, increased revenue, decreased cost, and increased profit. If stakeholders are unable or unwilling to supply core outcomes, the team should impose a core outcome on the stakeholders and start to talk to them in those terms. Establishing outcomes is so critical to a product team that they must invest time in getting this right. Do not give up on this task! Iterate on the messaging, and continue to push stakeholders in the right direction. Once they establish a core outcome the team can then explore the domain until they are ready to build a roadmap, where they articulate a set of outcomes, based on leading indicators, that align to the core outcome. From there, other output-based ceremonies, like end of sprint/iteration demos, should also be removed as they are not an effective way to monitor progress.
For example, my team and I were brought in to work with a federal client at United States Citizenship and Immigration Service(USCIS) to replace their case management system. The stakeholder came to our group with the customary set of requirements pulled from staff feedback, and we were asked to implement the features. The measure of success was binary — do the features exist or not? There was no mention of the bigger “why?” behind a new case management product, nor did it appear this person had questioned the larger goal. No technology existed today to manage the process, so they needed some. More troublesome, the team had no space to create, based on the conditions that existed in the domain. We needed to figure out a way to reframe the product around an outcome.
We started with discovery-type activities to learn the ecosystem’s context and nature and the stakeholder’s motivation for the product. As we distilled the information through an “Insights & Action Items” exercise (post forthcoming!), we started to notice a pattern in our research that pointed to user pain and bottlenecks in the flow of cases between groups. It took so much time for people to locate case files, know where a case sat within the process, or understand where to go next. We had a serious workflow problem. As a result, we tapped into core outcomes that could redefine the product direction: “cost” was not a main motivator for this organization, so we could ignore those outcomes. Fraud and integrity were not serious issues for our domain context, so we could ignore those too. Based on organizational priorities, balanced by the central user pain, we elected to focus on operational efficiency, which we could measure in “time spent doing X per case”.
Once the team determined the right outcome to define the work, we started talking to our stakeholder. “It sounds like you have inefficiencies in your process. What do you think about solving the time it takes to find a case?” We built on that suggestion by educating about the power of outcomes for product teams. We explained how the approach created space for us to help the stakeholder identify issues, prioritized by potential time savings. We would happily work towards the highest priority outcome based on potential improvements. The stakeholder accepted the approach, and we put aside the requirements to begin work on defining the areas where we could best impact our core outcome — improving efficiency. We spent three weeks exploring the areas to improve, one day-long facilitated session to prioritize, alongside our point stakeholder, and two weeks testing out ideas for potential solutions before “starting development”. During development we engaged with users weekly to test assumptions and validate our work.
In the end, we delivered an application that enabled folks to locate cases in 30 seconds while in one system — where previously, it took them 30 minutes in three systems to locate a case. The product team felt amazing about the work, as did the stakeholder.
For me this is the power of outcomes — it creates the space for the team to deliver whatever output moves the needle on a core priority. In this case, the product team needed to translate the requirements to a core outcome, with which the stakeholder could reframe their goals. The product team was then responsible for helping the stakeholder stay focused on the outcome as they measured progress. Still, it was a small price in exchange for creating the space to maximize their creativity and deliver a great product.
Maintain a consistent relationship with users: Few things are more empowering for a successful product team than forming a relationship with end-users. A sustainable “build-measure-learn” cycle is predicated on consistently engaging users, to understand their domain and evaluate your hypotheses. This knowledge also enables the team to participate in strategic business discussions, leveraging the insights they have gained from peoples’ lived experiences. The insights create an opportunity to reveal, challenge, or modify stakeholder’s assumptions, which may, in turn prevent costly decisions. Confronting assumptions can be disarming for stakeholders, who have never been challenged before, so be prepared to defend your position. The team should not get discouraged if the initial insights are not received. Stakeholders are often unable to hear what we have to say, or we are not succinct in our messaging. Be persistent when risky assumptions are being ignored, tie conversations back to user insights, and iterate on messaging and communication style.
We ran into this problem on a product with the Federal Aviation Administration (FAA). We were asked to rewrite an existing public-facing application that “the general public used” to the order of millions of requests per year. This was perfect on the surface — we appeared to have a sizable population of users to engage with to identify pain related to the existing site. As we dug into the domain we started to find that the number of requests hid the reality. The user population was smaller than it appeared: we reached out to casual passengers in our network, scoured social media for mentions, and tapped into referrals within the flying community. We found that very few members of the general public knew about the site, and those within the flying community had limited exposure, if at all. One of our central assumptions about the site seemed debunked. We then investigated the source of the requests which were generated from within the FAA, an internal app was slamming the site with requests.
We took this information back to our stakeholder, who initially dismissed our findings with rebukes that the sample sizes were too small, and we needed to look harder. Most of the team came away disappointed and confused by the stakeholder response in that conversation. A designer colleague and I reminded the team that we were in the best position to understand the users. Yes, our research methods did rely on small sample sizes, as we were in initial product discovery. That was a fair criticism. Nevertheless, with the number of requests the site generated and our stakeholder’s confidence, we should have found someone familiar with the site. We performed another round of outreach to the flying community and found the same results. Emboldened by these findings the team presented their research to the stakeholders again and were received in about the same way — dismissal. This time, when the team walked away from the meeting, they felt empowered to push back. The conversation changed from “Let’s satisfy the stakeholders’ ask” to “How can we help them understand our perspective?”
We approached the stakeholders to learn why they pushed back on the research findings. They assumed we were going to kill the project (not wrong) with the low site usage. They had stood the product team up for other reasons, like de-risking a data connection and demonstrating how this product team might work in the FAA. When we understood the underlying resistance, we could reframe the conversation around keeping the project and rewriting the application, but targeting a user group that showed interest in the application. Over several discussions, we brought the leadership team to a core outcome, aligning both groups. Without our research, hoping to connect to the end-users (or lack thereof in this case), we would have been at the whims of stakeholder requests. When we had confidence in our research, we could have strategic conversations that added value to the organization.
Understand the surroundings: Product teams are fragile. A leadership change, team turnover, or expansion to a new business unit can all threaten the conditions that make product teams successful. Product teams need to understand the dynamics within their organizations to position themselves to thrive strategically. The team should pay attention to who supports them, who is skeptical, and who is antagonistic. It is helpful to monitor understanding of why a firm chose to invest in product teams. And finally, they should learn from and share knowledge with other product teams. Sharing insights across product teams forms the foundation for a community within the organization. Additionally, communication between teams makes working together more comfortable, especially when implementing technical integrations or solving complex problems. Creating an environment where individuals from different groups feel comfortable with each other can promote space for people to drop in on other teams to work through technical challenges or pair on an integration between their applications.
We encountered this issue on a project with a sporting goods retailer, when the product team expanded out of the IT organization responsible for eCommerce. We walked into the opportunity excited to refresh their “loyalty experience” and teach a new business unit the power of the product team. When we attended our first stakeholder meeting, we were blindsided. Our new stakeholders shut us down at every turn. They had figured out the market, which goods to position, and had the split-tested survey results on hand. All they needed from “IT” was to implement their identified features. We walked away from the conversation, asking ourselves what we had gotten into.
After we took a few moments to lament our existence, we started gathering context from everyone we could in our’s and the client’s organization. We learned that the new product team was the first to engage with a stakeholder outside IT. This was an important detail to know as we considered how to position ourselves as a product team created to support their work. We learned from another designer that they worked with this group, couldn’t stand it, and arranged an internal transfer — a fact that helped us recognize we are amongst detractors. We gained insight into the new stakeholder’s organizational structure, where it was clear there was a rigid hierarchy. We also learned that the new stakeholder knew their marketing stuff and had done great research on what motivated the most loyal customers to spend a bit more. The team needed to understand the context within which we were trying to build trust with the new stakeholder and deliver value.
We decided to hold a few sessions to do some initial education on a product team, how we work, why we work in this fashion. Research being core to our approach, we wanted to test with users in stores, but they initially rejected this since they had “already done all the research”. Still, we went to the stores to test things within the digital space we were working on and did some exploratory research on customer loyalty for our education. Our user research kept being dismissed as superfluous. We tried to invite them to the stores, to our “Insights and Action Items” synthesis, to our product space — each experiment ended in failure. Our new stakeholder was not amenable to our approach as they were the “expert”. We were stuck. The reality was, we could research around the edges of the product, but our team couldn’t add anything substantive in this setting. Getting shut down was a possibility. Nevertheless, we knew any digital experience could be de-risked with in-store research, handing consumers mobile devices, and inviting them to step through our prototyped flows. We settled into a modified way of working as a product team, acknowledging the pain of working with the stakeholder and trying to deliver value. But this approach hurt team morale and was not sustainable long-term.
Our determination finally paid off when our new stakeholder left the company. Suddenly, space they were constricting opened. The context changed, so the team again attempted some of the practices that failed initially. Our user research put us in position to have a more productive conversation with the replacement. They started to join our user research synthesis sessions, enabling faster feedback loops between the product team and the stakeholders.
Most importantly, both teams gained trust from the other’s approaches, which led to our first release of a new loyalty experience. Overall, the product team needed to learn the new business unit’s context before trying to engage. Even as they made an effort to build a workable solution with the original stakeholder, nothing seemed to work. Often, recognizing the context of a situation provides the keys on how to overcome barriers. Other times, it helps you understand that a barrier might be immovable. In our case, some educational sessions crossed with a lot of luck paved the way for our success.
Practice continuous collaboration: Once we are on a product team, we need to carve out space for vulnerability, learning, and collaboration. Many people hold a stake in decisions to change the backlog priorities, adjust a design, or embark on a refactor. By leveraging continuous collaboration, we can practice a form of communication that promotes collective ownership of the decisions. We can practice mutuality within the team by taking an active interest in the ways other functions operate and appreciate the exceptional contributions they bring to the team. This reciprocity creates flexibility, allowing subsets of the team to represent the whole team in meetings. We can signal our mutuality within these contexts by letting the expert discuss issues pertinent to their domain, even if the experts are not addressed directly. When the team practices continuous collaboration, they are also in solidarity with their strategy, which acts as a buffer against executive leadership who may not fully accept product teams. Continuous collaboration empowers and insulates the team.
Every product team I work with practices continuous collaboration. I wrote a bit about the practice earlier, so I will point you there for a deeper dive.
Each of the four recommendations above attempts to move a team from operating in a traditional, top-down manner towards a high-functioning, self-directed product team. It requires energy and persistence to overcome obstacles, and there will be moments when the effort to push against the enterprise feels insurmountable. You are trying to reshape the organizational structure within which you operate — It is hard! Rest is indispensable; when you need a break, take a day off, restore your energy, and pick back up refreshed.
Even when you make a breakthrough, the gains made can be ephemeral. Introducing a new stakeholder, winning a big contract, or expanding to support a new business unit may threaten to undo the product team. There is always work to do, iteration, adjustment, and tuning to ensure the team’s stability. But carving out the space to explore a problem or solution creatively is worth the effort. And finally, those of us that have experienced working on product teams are here to support you.
In the next post, I will discuss how leaders can empower product teams within their organizations.