Communication for product managers is more than just the ability to speak and write well. Good communication generates buy-in for ideas with clear reasoning, expression, and progress. A great product manager is able to express the strategic value of an idea to upper management, to partners, and to the development team.

Upward buy-in comes from excellent upward communication to product leadership and senior management. This is especially important for product managers who start to work on bigger projects with greater visibility. If the product has high business impact, then executives will want a robust overall strategy and plan. If the product utilizes a large amount of resources, then executives will want to know that the prioritization is correct and will have some appropriate return. The more important the product, the more crucial it is for the product manager to have excellent upward communication. 

How to communicate upward is highly dependent on the company and the style of its executive leadership. Every company and person operates differently. Be cognizant of what works in your company by assessing how previous initiatives were done. If you are in a company with senior product managers, ask them for advice and history. If you are the only product manager at your company, be observant of what does and does not work. Usually this boils down to what matters most at the company. A company that obsesses over customer satisfaction will be different from a company that is focused on gaining market share. A company that has a growing recurring revenue stream will behave differently from a company that needs to make its next fundraising target. None of these situations are better than any other - only different. To be most effective, a product manager should seek to develop communication that is specific to the situation. 

A roadmap should give the executive an understanding of what will be accomplished in the product within a given time frame. Roadmaps typically detail a plan for a 6-12 month duration with time splits dependent on how the company organizes planning (eg. quarterly or monthly). The roadmap should contain high level features with a clear mapping to the value, metrics, and goals of the overall product. The roadmap should provide visibility into what the team is doing and an embedded reasoning for the work. 

An executive reading a roadmap should be able to clearly understand each feature, why it's there, when it will get accomplished, and how it helps the company's goals. If it's not obvious why a feature is on the roadmap, then refinement is needed. The simplest roadmap is a table that contains a clear summary of planned efforts. A good roadmap should be able to answer the following questions:

What high level milestones are there in the next 6-12 months?

How will these milestones add value to the user and to the company?

When will these milestones be accomplished?

It's generally good practice to keep the roadmap document itself simple. You want just enough information to convey what the executive cares about. If a roadmap has way too many informational elements, it will become hard to read and you'll most likely end up having to create an "executive summary" version anyway. Roadmaps are living documents that should be updated consistently based on where you are in relation to plan.

The product strategy is a document that is typically reserved for a large product objective. If you're in a position to define a new product or spearhead a big initiative, you will likely need to create this asset. A product strategy is typically presented to an executive group for approval, which includes both asking for their support and agreement to sponsor necessary resourcing. 

The format for a product strategy document varies greatly by company. In some companies, the product strategy document must be in a detailed essay format under a specific number of pages and following a standardized structure. In other companies, the process can be comparatively informal with the document mostly being a pitch presentation and a walkthrough of the product prototype. 

Regardless of the format, the objective is the same: you want executive buy-in with the plan. This means the document should be able to explain your product well, provide sound reasoning for the features, and build confidence that your plan will work. While the components will vary, a typical strategy document will provide answers to the following executive questions:

What is the problem and who are the users who experience it?

Why is this problem important to the user and the business?

What is the solution? What does it look like? How will it solve the problem?

The answers to these questions are developed during the product thinking process you underwent to discover and solve a problem for value. The document is a summary of the learnings, presented in a cohesive narrative that explains the importance of the problem and the opportunity at hand. In a way, it is a bit like a product pitch where you are asking for investment from your executives to fund and approve a project. A product manager presenting a product strategy will typically have a lot of supporting materials ready in an appendix should detailed questions come up around roadmap, resourcing, cost, distribution, product prototype, etc.

Inward buy-in is created with excellent communication to your development team. The development team is anyone who works with you to actually build the product. It often consists of engineers and designers, but may also include project managers and other product managers. 

Inward communication assets are specifically focused on communicating what needs to be done. They are designed for purposes of efficiency and are meant to contribute toward the goal of ultimately delivering the value that is promised. Inward communication assets are about clarity and comprehension more so than any other asset type. 

The PRD is written for the development team. It should be clear and easy for the team to comprehend. To be able to provide the right level of clarity and comprehension, you must have enough technical knowledge for your product area to communicate at the operational level. If you do not understand how a product is built or designed, it will be extremely hard to articulate features and functionality correctly. The bare minimum level of competency is somewhere around “relative hobbyist”. This means relative to your team, who are professionals, you are a hobbyist. You can talk shop, but you don’t operate at a professional level.

 A successful PRD is easily understood by the team so that they can provide accurate feedback on the cost of the build. An unsuccessful one is only understood by the product manager who wrote it. It is essential that you determine if the development team actually understands the PRD before splitting up work. In the worse case scenario, you assume that the development team understands and they implement a feature incorrectly. This is costly to undo, difficult to explain, and frustrating for everyone involved because it means repeat work and a potential delivery delay. 

To prevent this from happening, always make sure that the development team really understands the PRD and get feedback from individual team members. The active feedback will also be useful in improving the PRD. You may receive feedback that some features are unclear so you will need to sharpen them up. Or you may find that a certain feature as you defined it will be too hard to implement, and you may need to define it differently. 

There is no specific format for a PRD. It should be clear and concise, but detailed enough to get the salient points across. The preferred format is whatever format best helps the development team understand what to do. Generally a PRD will contain an outline of the problem statement, an overview of the solution, the specific functionality required, and a link to the prototype. 

How specific you need to be depends greatly on your relationship with your development team and the developers themselves. If your relationship is somewhat tenuous or if the developers are junior and don't have experience in shipping products, then it will be beneficial to be more specific in your requirements. By the same token, if the relationship is extremely strong and the developers are experienced, a simple PRD can easily do the job. 

Sometimes product managers can get caught up creating requirements because they feel the need to express exactly what they want. However, it's important to remember that the real product is the one that the engineers will build, not the document it's specified on. Keep your audience in mind when writing it so that it can be easily understood and executed on.

The backlog serves as a centralized store for items that are not prioritized in the current development cycle. The backlog communicates to the development team and stakeholders what there is to potentially do in the future. It is the product manager's responsibility to periodically groom the backlog by going through all the items and making determinations on what to prioritize. 

An item in the backlog will typically have the following characteristics:

Priority: the priority or impact of the item

How you set up a backlog is entirely dependent on your development process. Most product companies use some flavor of agile development with the specific implementation varying across teams. In most agile development setups, the actual task board is jointly owned by the development manager and the product manager. The backlog, on the other hand, is largely the product manager's responsibility because it requires assessment and prioritization. Design your backlog based on what works best with the team's development style and allows you to make prioritization decisions appropriately. 

Product Knacks

Generating buy-in

Communication is Key

Register for complete access