I’ve been focusing these ‘sprint in the life’ posts on one of the projects that I work on as a product owner. I am part of two other sprint teams as well, and we as a company have several other projects going on simultaneously that other product owners are involved with. The team of product owners met earlier this week – something we do once a week – to talk about the different projects we are working on. In addition to these meetings, I also meet once each sprint with the development leads across the several projects that I work on to talk about this set of projects. These different gatherings are relatively informal with little to the agenda beyond getting together to talk. But there are several key reasons why we hold these different cross-team meetings and why their value seems only to be increasing over time.
- Understand dependencies and time-lines. With multiple projects spanning our company product portfolio, we need to keep track of the release plans and development time-lines of each of the products so that we can coordinate our plans. If three different software products each plan to update the way reports are generated next year, then it makes sense to discuss how this work might be shared across the teams and to make sure we plan together our release strategy for the feature set. Before we began having regular cross-team conversations, there were occasions when one team built out one version of a particular functionality only to have another team work on a different version of the same thing without knowing about the first project. Increased understanding is especially important in our multi-tenant SaaS architecture because of the ways that our products all reference the same infrastructure and platform. Understanding the respective time-lines and inter-dependencies of our diverse product plans allows us to collaborate much better – which leads to the second reason for these meetings.
- Learn and leverage together. As we work on our specific products, each of the product owners is learning new things – about our client base, about the market into which we are selling, about the internal and external needs that our products might address, and about how to more effectively fulfill the role of product owner. Meeting together allows us to share what we are learning and thinking about, hopefully strengthening our entire product management organization. We can share the insights we have gained and the struggles we have endured, talk about the issues our product teams are facing, and learn from each other’s mistakes and successes. I regularly benefit from what others on this team share as they point out flaws or blind spots in my perspective. These meetings allow us to leverage what we are learning across our product teams instead of forcing each team to go through the same set of mistakes.
- A third key reason for these regular gatherings is for us to plan our cross-team resource needs. In our firm we have an incredibly strong and diverse technology team made up of designers, web developers, quantitative analysts, modelers, database experts, testers, and architects. We also partner with other companies on some of our software development projects, further expanding our talent pool. We have senior developers with years of solid experience, and we have newer developers eager to learn and grow. However, with all of the products that we are developing and with our aggressive product plans, one thing we do not have is any extra development capacity. When we conduct quarterly prioritization meetings to determine how best to invest in technology growth, we always face the constraint that we have fewer ‘resources’ than we would like across our technology team and so we have to figure out the best way to deploy the talented people we have across our various projects. This planning happens at many different levels, but one important though informal locus for this planning is our cross-team conversations. Here we discuss our product plans apart from the political jockeying that sometimes seems to cloud more formal sessions. Our trust in each other and our regular interactions allows us to be flexible and understanding, knowing that we all want each of the company’s products to have the best chance for success. Fortunately, we are a ‘feedback rich’ culture, in which lots of cross-team conversations are encouraged and there is relatively little turf guarding in which departments don’t want to share their insights with others. As our firm continues learning about the best ways to allocate development resources across projects, these informal cross-team meetings allow the product owners most directly involved with the development teams to both shape and respond to the official planning that happens elsewhere.
Please allow me a brief digression here to share a personal preference. Although I used this term above, I am not a fan of calling human beings ‘resources’ to be allocated. We are teammates, partners, coworkers, and often friends working together with a passion for creating great products that thrill the users who buy them. Our developers are not interchangeable commodities easily replaced or replicated but uniquely talented and motivated individuals who do their best work when they are fully engaged as members of a team. I think this is part of what the following Agile principle is driving at, and it certainly colors the way I interact with the teams I serve as product owner: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Back now to the rest of this blog entry…
There is debate in the wider product management community about how many products a single product owner ought to be working on. The many tasks of a product owner certainly make this role a full-time job in my opinion, and I regularly feel that there is more I could and should be doing to feed the development pipeline for the sprint teams that I work with. At least for now, our company has some product owners responsible for multiple products (like me), some working on only one product (although these folks sometimes have other duties beyond their product owner roles), and some products with no dedicated product owners. As we sort this all out, I think we will continue to find that some level of cross-team interaction provides vital information that individual product teams benefit from. The value of the learning and planning that can happen across teams will, I expect, keep these formal and informal meetings valuable even as we put more structure around the way we do product management as a firm. Of course, in truth it’s not that simple.