How to manage a product that depends on 40 other product managers

Posted by

Tasktop is the premier integration solution for software development teams. We connect our customer’s entire tool chain from Project Management, to Requirements, to Development and Testing. We let information flow between teams allowing our customers to build better software. We do this by building connectors to 40+ different tools – end systems (see our list here). This means we have to stay up to date with all the updates and nuances of all different types of tools… each with their own product manager, roadmap, and priorities. Imagine if your roadmap depended on 40 other roadmaps? Sounds insane, doesn’t it? Keep reading to see how we do it…

There are some important hurdles that we must overcome to successfully conduct our day-to-day lives at Tasktop. First, the fact that third parties are focusing on their own priorities first. Second, the necessity for strong partnerships with other companies, and last but not least – the need to accommodate other companies’ processes. While we must overcome these difficulties, there are also benefits in working with other product managers – an obvious one being the common understanding of the PM role helps us communicate and better understand other product managers.

Third parties focusing on their priorities. In today’s API economy, vendors (many of them our partners) will be looking to leverage the information and knowledge they have to make sure they are delivering the functionality that their customers want… and that is exactly what we expect them to do. Their management will likely be interested in using/expanding APIs to meet customer demand and, in turn, increase their revenue streams. Tasktop relies heavily on web services to communicate with repositories. And the functionality we put in our products takes advantage of the doors opened via vendor APIs. Once we get deeper into the various technologies, we discover what is available and what is not. In other words, what artifacts/attributes, special use cases and features we will be able to support. Note that “missing” for Tasktop simply means “designed differently” or “not implemented yet” in the worlds of other vendors. While some of these attributes are important in our eyes, they do not always make the top of the list for the customers of our partners, as their priorities may be different. This is where my next point becomes quite important.

Necessity for strong partnerships. Since other companies have their own customers to put first that don’t always overlap with our customers, there is a need for strong relationships with our partners to make sure that we can deal with these tricky situations. Luckily, we have built great partnerships over the years and therefore can always work together with our partners to add/modify existing APIs to better align with customer use cases, make sure to account for different release dates, and always have direct communication channels for regular, as well as urgent questions and issues. These relationships are crucial as there are a lot of times when it is necessary to not only align our internal teams within Tasktop, but also align the third party engineering teams to make sure that their APIs are ready for consumption in time for us to finish our work. It is definitely a more complex workflow that does take a lot of attention to detail and planning, however, with the partners we have acquired in the last few years, we have learned how to effectively coordinate this process. Polishing the process took a while but we know have in place structure for cadence meetings with partners, process for planning partner feature requests, as well as a way to deal with ever changing agile plans and be able to deliver features with little warning if necessary.

Need to accommodate other companies’ timelines. One of the most obvious discrepancies between companies is release timelines. Our release activities and processes do not always align with our partners’ and that poses some complications. We release quarterly every year – January, April, July, and October. Since every company is different, we have partners who release closely before our release dates or closely after. This means that our process must account for these discrepancies to make sure that whatever release we are delivering will be compatible with every version of our partners’ software and every new feature is supported in time for the partner GA dates. This requires us to put more thought into our release activities to make sure we can accommodate for these discrepancies. As an example, we always need to make sure that partner API fixes have been rolled out to customers before we release something that is dependent on these pieces on our side. And vice versa – if partners release a breaking change, we need to make sure customers have a ready service release to be able to operate without interruption before upgrading partner software.

But this particular situation has its benefits. Product and Marketing have different views/outlooks/goals.. Same for Product and Bizdev- the departments fundamentally have different drivers for their decisions and everyday operations which can sometimes make it tough to understand why the other department is making a particular decision. In my case (PM working with a bunch of other PMs), I get to work with a person who sits in the same seat in another organization. While we still have our own organization’s interests in mind, we do share a common understanding of the role and therefore quite easily understand why and how decisions are made. For example, how features are being prioritized or why certain pieces cannot be delivered in the next release- product managers all deal with the same problem of too big of a backlog and too little of resources. Since we are all in the same boat, it helps when we need to negotiate timelines and feature scope.

So here I am. As a product manager for the connectors at Tasktop, I work directly (or indirectly) with around 40 other product managers, trying to align our release plans/roadmaps to make sure that all of us deliver the most customer value. And while we share the same customers, we can have slightly different opinions on what is most important and next up for our customers. All in all, it is not a science, but an art of coordination to meet customer use cases with dependencies not only on our internal product managers and teams, but also on ones from third party companies – altogether having upwards of 40 people who can any day affect our release roadmaps.