Establishing a Communication Framework
At first blush, Product Management seems pretty straight forward, and in many ways it is.
You identify stakeholders, gather requirements, establish a roadmap, and ensure the final deliverable meets the product goals.
Of course, there is more to it than that, but would anyone every really consider it a hard or complex job?
I used to work in a product team that was responsible for delivering the products in the Extended Reality business unit (XR, for short: Virtual Reality and Augmented Reality combined).
So we had customers with requirements and engineering teams to build the product.
Simple, right?
No.
First, the company was not building processors for our product specifically, they were building processors that could be used in our products and other devices, and that processor was a product with its own Product Manager. This meant that our team was a “customer” to the hardware team, and our needs were balanced against the needs of the other products that the processor would be used in.
The software was also a mixed bag. We had a smaller team of engineers working directly on our software, but a much larger share of the engineers was making software for mobile phones. We needed to negotiate with that team (and their own Product Managers) to get our needs supported in their software.
Then we had the non-product teams: the Sales and Business Development teams that represented a the global customer base. Each customer has their own vision, and there are always unique requests for features and timelines to be reconciled with reality.
Above all this were the executive teams, who had the responsibility to allocate resources, handle escalations, and provide the go/no-go decisions on whether to start or continue each product.
Our team sat in the middle of this, and we had to ensure that we understood the customer needs and requests, and the engineering capabilities and constraints, and then turn that into a successful product that would gain executive approval and grow the business.
This type of situation is far more common than not.
Rarely is the full organization aligned behind a single product. So while you may be a product manager of a particular effort, your stakeholders and resources are sharing their capacity across a variety of competing activities and priorities.
So how do you make sure that your product gets built and meets the business goals?
PM Jargon word of the day: Alignment
Alignment - noun
ə-ˈlīn-mənt
1: the nirvana-state of any product development effort in which all stakeholders across all teams are aware the shared objectives and their own responsibilities at all times.
[see also: “herding cats”, “Plate-spinning”, and “running in circles”]
The biggest factor in your product’s success will be making sure that everyone involved in the development, approval, management, or sale of the product has a clear understanding of what the product is, who it is for, what it needs to do, how their part fits into the whole, and when their deliverables are needed.
This is alignment: everybody moving in the same direction for a common purpose.
As the Product Manager, no one is better positioned, or more motivated, to gain this alignment than you.
I have developed a simple framework that I follow to help ensure this alignment happens on my products.
It is a combination of meetings, tools, and leadership reviews.
Meetings
I know, I know. It’s very popular to hate meetings.
My advice? Deal with it.
Thing is, as a Product Manager, you are not the person doing the work of building the product, and you are almost certainly not the person selling the product to customers, but you need to work hand-in-glove with both of these teams. This means you need to talk to them.
I firmly believe that well-structured meetings, with clear goals and targeted invite lists, are by far the most effective way to sync with your teams.
The frequency of these meetings may vary, but I usually prefer to have weekly sync meetings with my customer-facing and development teams. Other teams, like marketing and finance may only need a bi-weekly touch-point. Executive meetings will depend on their interest and involvement, but I would not go longer than monthly.
Commonly there are multiple teams and leads in each of these domains, so this may mean that you have one meeting with each regional customer team, and one meeting with each development team.
Yes, this may mean that you personally have a lot of meetings but, if you do it right, each of these meetings will be valuable to you and the other attendees, and they will not fall into the common traps that cause people to hate meetings.
In each meeting, you will generally walk through the updates for the week from each participant.
For example, in a weekly meeting with the North America business development and sales teams, the meeting will consist of them sharing the latest feedback, updates, and concerns from the customer. In return you will share the latest updates from the development teams, and any updates to the roadmap, as appropriate.
Similarly, when you meet with the platform development team, later in the week, you will share the latest customer updates with them, and they will share their questions, roadblocks, and progress.
It is worth noting that you I place myself in between the development and customer teams, I do not want unfiltered requests or information traveling either direction in these meetings.
It is critical that the key updates and actions from these meetings are documented to provide status updates and to track action items.
This brings us to the topic of tools.
Collaboration Tools
There are a lot of tools that can be used as the touchpoint for alignment across teams. I have personally used Monday.com, Notion, but there are others.
whichever tool you choose, it should allow the following minimum functionality:
Entries and hierarchies for each major product/deliverable
Create these at the level that makes sense: by customer launch, by software version, or some other product distinction.
Include a description and major milestones
Tags/links for status and creating relationships between entries
This is to track dependencies and to roll up a current status across the entire project
In-tool communication
This is where the notes and actions from your meetings should live, and where updates can be posted.
Ideally this tool is what you use to collect and distribute information, not something that you update on top of your existing work of capturing status and providing readouts.
When you have your meetings with each team, the action items, questions, and updates you capture should be captured only in your collaboration tool.
When you share program status, it should be as a view from the tool.
You will not gain any value for the collaboration tool if various development teams are tracking and sharing status in Excel spreadsheets and Confluence, while the sales team insisting on Power Point, and you are using Monday.com.
Unfortunately, that’s probably the environment you are operating in currently, so how do you get people into the habit of using the new tool?
You go first.
It will take effort and energy, but it is up to the Product Manager to set the expectations for the execution of the product.
At the earliest stage possible, follow these steps":
Work with IT to identify the tools available and make sure that all stakeholders have appropriate access.
Then populate the tool with entries for each product and team that you need to track and provide status on, and fill out the current status to the best of your knowledge.
Once you have this in place, start using it as the basis for your meetings, and ask the teams to provide their updates in the tool.
Most likely, many of the teams will be slow to adopt, but you can encourage the use by communicating through the tool (you can usually @tag them people you need update from and it will send them an alert).
The most compelling way to drive adoption is to show the value of the tool. Be proactive in gathering notes and data, and make a bit of a show of how convenient it is for the team to have all the latest data in one central location.
Following this approach, I have been able to drive broad adoption of collaboration tools, but there have always been a few holdouts. I handled these by continuing to ask them for updates in the tool, but ultimately generating the updates myself based on my meeting with those teams until they fell in line.
In the end we had an extremely useful resource for all of the stakeholders to see updates, ask questions, and track the overall progress of the product.
Leadership Reviews
Product readouts and reviews are inescapable.
On some regular cadence, your leadership teams will want to hear from you about how you are progressing towards your goals, and to (more often than not) throw a major curveball right into the heart of your roadmap.
Luckily, there’s an app for that.
If you have been successful at bringing your various teams to heel, you already have the latest status, next steps, and open questions ready to go.
You can (and should) use the collaboration tool for this review meeting as well. The leadership comments and questions can be added into the appropriate sections for each deliverable or team and tagged as executive requests.
This way the team is immediately aware of the need and the priority, and you have an easy way to filter your view to see these requests and the responses as they come in.
I have never met a leadership team that did not love the idea of being able to see the current status of the products the team was working on, along with the customers, and milestones associated. They can even review the data independently, and ask questions directly, if appropriate.
If managed correctly, this tool can also serve as the basis for executive priority decisions, where early stage requests can be prioritized or rejected based on the merits and risks listed in the tool.
By having accurate and up-to-date information for your executive teams, you give them the best chance of making accurate prioritization and go/no-go decisions for the good of the business at large.
___
By following this communication framework, you can ensure that the diverse teams associated with your product are operating with shared real-time knowledge of the effort. Every team with skin in the game can ask and answer questions, and visually understand their role in the overall product.
Gaining alignment across your product stakeholders can be hard, but if you are diligent in your pursuit of this goal, and you dedicate yourself to the processes and tools you need, it can be achieved.
