Unless you’re the sole PM in your company – it’s probably just a matter of time before you’re tasked with designing a feature or a product that spans across multiple teams and not just yours.

Most often such features or products require some fundamental changes to how things work across the board and your associated engineering team doesn’t have the authorization and/or knowledge to make the changes in some of the modules which are involved in the project.

 

For example – let’s say your team is responsible for the mobile app of the company, and it was decided that the app now needs to support in-app purchases. That’s a new business model that wasn’t supported before. Supporting this new capability requires changes across the whole chain – starting the UX and the UI of the app and ending on the server side with the billing modules.

 

Another example – imagine that you are responsible for an ad server that delivers ads to various platforms. Now imagine that the company has decided to support video ads as well. This requires introducing the new format across the board, including how it looks, how it behaves, how it’s measured and all the financial aspects around it.

 

There are plenty of other examples – but let’s proceed with these two for a second.

 

How should I approach this?

Ownership

Well, the first real question relates to ownership. Who is the owner of this project? 

In the first example about the mobile app – assuming this app is just a part of a bigger platform that provides various services, then it makes sense that you, the product manager of the mobile app, will be the owner of this feature, since in-app purchases are usually only relevant to mobile apps.

 

As for the second example – the first thing to understand is how strategic video ads are for your company. Video can be a big thing on its own and therefore it could be that the company has hired a dedicated product manager to manage all video-related initiatives in the company. In that case – most likely that this new PM will be the owner of this project. With a lack of one – then it will probably be you (in our example) since you own that platform that is serving the ads.

 

As you can see – the question of ownership is not clear and cut and the decision may change based on the overall functions in the companies, and may also be taken based on personas. For example – a product manager with strong project management skills may ‘win’ the ownership of a project even though according to the division of responsibilities it should have belonged to someone else.

 

There are two important things to care about here:

• To make sure there is an owner

• To understand whether it’s you or not

 

The question of ownership is very important. There must be a clear known owner to any cross-team projects. With a lack of one – this project will most probably be delayed and will cause a lot of frustration while being worked on.

Thus, even if you don’t believe it’s you who should be the owner – it’s very important that you insist that there will be one.

 

Wait, what does it mean to be the ‘owner’?

Essentially, it means it’s your responsibility to make sure the feature is built properly and being delivered on time. Yes, it involves utilizing your project management skills and on top of all – be accountable for the results (whether it made it on time and whether it delivered its theoretical business value).

 

Project management? Why not simply get a project manager to assist the owner?

I always say that every product manager is also a project manager to some extent. Yes, project manager is an occupation by itself, but an average company will have around 0-3 project managers on a full time basis. From my experience it’s a resource of high demand and therefore full time project managers are mainly reserved for large and/or complex projects. 

For you it means that you’ll need to possess some project management capabilities if you want to be good at what you do, because a full time project manager won’t be available for you most of the time.

 

Ok… should I strive to be the owner then?

There are two main scenarios where you should strive to be the owner of a cross-team feature/product:

1. It’s the right thing to do. Meaning – the great majority of the work/technical ownership lies within your group or the main value of this project is tied to your product .
2. You want to prove your value to your organization. If you wish to adopt this scenario you need to make sure of two things: First – that the ‘natural’ owner doesn’t want this (because they are too busy or just don’t want to deal with it for whatever reason) and second – you truly believe you can deliver given your other commitments, available time and domain expertise. Don’t go there if one of these conditions is not fulfilled.

Ok, my team is part of a big new feature release, but I’m not the owner. How should I play it?

This is quite simple:

Be cooperative and be smart.

By being cooperative I mean that you should do what you can to assist the owner in their mission. It means reviewing all product specifications, providing constructive feedback, pinpointing potential pitfalls, and most important – securing the time (sprints) to work on this, so your delivery would be on time.

Of course, depending on the feature’s size – it might be fair to ask to discuss this as part of the next quarterly planning. Otherwise – it may cause your team to miss their own quarterly commitments in case your team didn’t count for it in advance.

By being smart I mean that you should:

1. Get the requirements as soon as possible. Discuss, understand and accommodate them in your plans whether explicitly asked to do so or not.
2. Try to come up with the most cost-effective way to implement your part and suggest it up front, before a specific implementation is forced on your team. If you can keep things decoupled (by providing an API for example) – suggest it. Avoid cross-team dependencies unless there is no other way. Try to see yourself as a subcontractor if possible.
3. Avoid ego wars as much as you can. Depending on the personality of the other product manager, and especially if they are not very experienced with managing cross-team projects – they may try to ‘boss’ you around. Agree to that, unless the communication becomes non-respectful. I don’t mean you should work on something you don’t believe in. I mean that you should try to bear the attitude as much as you can and choose your wars carefully. For example – if the owner believes that the best way to execute on the feature is for you to develop a small component, but you don’t think it’s required – bring it up, but don’t insist on this, unless it’s crucial. Just make sure all decisions are documented as well as everyone’s feedback. 

 

The main thing to remember is that it’s not ‘your party’. And you’re only invited as a participant. So try to be supportive as much as you can, unless you truly believe that things are becoming unprofessional and too costly.

 

The time has come – I am the owner of a big new feature, and I require the cooperation of other teams. How should I play it?

There is one guideline you need to remember when starting to lead such a project. I touched it briefly before:

Never underestimate the power of the human ego.

People can do some bad stuff when they are driven by ego. I’m positive you have some examples of your own. In our context – the other product managers may de-prioritize the work on your features, fail to deliver crucial feedback in a timely manner or just ignore your requests if they feel that you’re stepping into their territory too aggressively. 

Since you need the other teams’ cooperation and you can’t pull it off without their help, it’s important to ensure that you are being respectful in all communication and avoid triggering their ego at all costs.

The main key to achieve that is to invite the other product managers to be part of the process and manage potential risks via 1-1 meeting rather than in a group. Don’t ‘surprise’ them with new requirements and changes. Explain the constraints and ask them for feedback.

The more they feel they are part of the process and not just being ‘let know’ when they are needed – the more you’ll experience a constructive & supportive environment.

 

Assuming you work according to this guideline – all that’s left is to execute based on some best project management practices. Here, let me help you take this a step by step:

1. Let everyone know about this project as soon as possible. Even before you have a concrete list of requirements. As soon as you know that this is happening – talk to the various PMs and team leaders and let them know it’s coming. Let them know you would need their help and make them the ‘heroes’ (“I can’t do it without you”).
2. Finalize the requirements as the first priority. Involve the other teams in the discovery process if it makes sense, or just share with them the spec when it’s still a draft (much before the spec review). Make sure they actually read it, and if you don’t get serious feedback – set up a meeting with each relevant stakeholder (product or engineering) and give them a private walkthrough. At the end of the day – you need to minimize your dependency on them (code wise) as much as possible, and that they are not getting into a complex design for no good reason.
3. Aim for the next quarter as the time when the implementation starts. Make sure to run the spec review and finalize all materials before the quarterly planning, so the teams can provide effort estimations.
4. By now everyone who is part of this project knows it’s coming and have a vague idea of how big it is and what they are required to do. It’s the time for you to make sure they secure the time to work on this – and in the proper order. E.g. – if team A needs to provide you with something before team B can start doing their part – ensure that their planning is synced about this. This is purely project management – but as I already mentioned – most likely – if you don’t do it – nobody else will. Hence, make sure to review their quarterly plan and that your project is there, and being worked on at the right time.
5. When the actual work of the other teams begins – ask kindly to join the dailys and sprint planning of the teams and ensure that the team is working according to the plan. If the other product manager is not eager for you to join – don’t force yourself. Instead suggest a weekly sync meeting between you two.
6. From this point onwards – it’s the usual project management work. Setting up weekly progress meetings, having some version of ‘gantt’ and tracking it closely and freeing up bottlenecks. It might not be very exciting, I know, but it’s for the greater good 🙂

 

And that’s really it.

 

To summarize

Collaborating with other product managers about a feature or a product is going to happen sooner or later in your career (if it didn’t happen already).

When it happens – it’s important to determine who is the owner of this feature or product and treat it as a project.

If you are the owner – make sure to work together with your colleagues and collaborate as much as you can, and don’t let ego get in the way. 

If you managed to create a collaborative environment – all that’s left is to do proper project management. If you don’t have enough experience with this – it’s time to hone your skills. 🙂

 

That’s it for today!

If you found this post/series useful – please let me know in the comments. If you think others can benefit from it – feel free to share it with them.

 

Thank you, and until next time 🙂