Product Management Skills - Know how to synthesize

Product managers must know how to communicate information for maximum receptivity and alignment.

A skillset every product manager should have is the ability to synthesize.

Synthesize - combine (a number of things) into a coherent whole.

Product Managers get exposed to a wide variety of information. They take in feedback through dozens of different avenues: conversations, side comments, research, analysis, metrics, interviews, intuition.

While Product Managers should share their original sources, they must have the ability to construct a cohesive narrative out of all of those different sources.

A Product Manager who just info-dumps without filtering and combining the results together isn’t doing their job. Anyone can take notes. Anyone can present a stream of consciousness and have others read it.

If a Product Manager stops there, they are abdicating a key responsibility: storytelling.

---

How to synthesize

If you’re crafting a narrative, add a structure.

• Problem, Solution, Value

• Situation, Action, Result

• Intent, Rationale, Detail

• etc.

Pick the appropriate structure. For example, for Intent, Rationale, Detail, you can do these steps below:

First - identify what it is you want your communication to achieve.

• Are you making a recommendation?

• Are you making a decision?

• Are you soliciting information?

• Are you sharing information?

Second - be explicit and state it, in no uncertain terms. Put that at the top of whatever it is you are communicating.

• “I am making a recommendation to do <X>.”

• “I have decided to do <Y>”

• “I am asking for information or answers to <X> topic or questions”

• “I am raising awareness of this information for consideration into <Y> discussion.”

Third - give the rationale. This is where you summarize your findings.

The reasons are below:

• Dozens of user interviews (link to repository) have indicated <X> sentiment.

• Our product analytics have shown a <Y>% increase since <Z> occurred.

• Specific competitors like <A>, <B>, and <C> have all explored this space.

Fourth - show the details. This is where you can show your work.

User interviews

• We conducted <X> user interviews.

• Interview with top 5% of customers showed <X> positive assessment.

  • “We absolutely love <Y>.“

Analytics

• This Amplitude dashboard (link) shows usage at <X>% since launch, highlighting increasing adoption and demand.

Competitor behavior

• <R> competitor recently hired <A>, who’s background is in this space.

• <Z> competitor recently announced joining a business group focused on bringing <B> to market

---

What should you synthesize?

Pretty much everything.

• User interviews

• Meeting notes

• Requirements

• Specifications

• Problem statements

• Decision logs

• Release notes

• etc.

Remember - synthesizing something doesn’t mean you don’t link to further details. It just means you paint a clear picture with broad strokes before starting to focus on the specific details. You want people to see the forest before focusing too much on the trees. Link back to the specific details, especially if they are important.

---

A contrived example of an unsynthesized user interview

Suppose you received this set of notes from your Product Manager:

support interview

Attendees - joseph, melanie, brent, brent, carl

started meeting

talk about new problem

lots of problems, finding ticket bad, can’t find ticket, lots issues

search for ticket

daily report

filter list

build it

melanie doesn’t like it

The problems

The above is useless because it is a ton of detail with more questions than answers. It lacks organization, which leaves questions unanswered and makes it harder to follow:

• What was the meeting about?

• What problems were discussed?

• Why this problem?

• What didn’t Melanie like?

• What should we build, and why?

• What are the other options?

You could still parse it out to figure it out, but you shouldn’t have to fill in those blanks. Even if it was verbatim and had full details, Product Managers are not transcribers. We need to provide more value than that to be useful.

An alternative

Imagine the same meeting, but with the below notes instead:

Interview with Support - 2/11/2019
We decided to create a new Filter on the Support Ticket tool that will filter the list by the ticket status. This will help ease support time burden in locating a ticket. We considered other alternatives like searching or a recurring report, but these had drawbacks.

Meeting notes
Intent
discuss challenge with support ticket navigation

Attendees
Product and Engineering: Joseph, Melanie
Support: Brent B., Brent C., Carl

Discussion
Support ticket navigation

• Problem - unable to find ticket

  • Wastes significant time going through pages of tickets

  • Reported to happen 10x per day per agent

• Solutions proposed

  • Search for ticket status

    • Requires cross-team interaction

  • Daily report of tickets by status

    • Melanie doesn’t like it - technical feasibility concerns

  • Filter list by status

    • Easier to do, can be done with single team

    • DECISION - Decided to do this

Decisions:

• Create Filter list by status

Even if not perfect, this is a much clearer set of notes. The synthesis at the top also helps frame the intent of the message to act on.

---

Tips

Don’t start with details. People need to know what is expected of them. Otherwise, it can derail a conversation or lead people down a line of thinking that wasn’t the intent.

Understand the content. Some Product Managers don’t actually understand what they are working on, but attempt to communicate it anyways. This usually results in fantastic blowups as the situation devolves. Don’t be afraid to ask questions if you don’t understand. Make sure you do understand what’s being said and what’s happening - people will quickly find out if you’re just making up stuff.

Be organized and consistent. Know how to write well. Use headers, lists, typography changes (bold, italics, etc.), section breaks, tables, etc. to communicate.

Know your audience. Is your audience a group that likes numbers and metrics? Add them. Is your audience more about user sentiment and impact to reputation? Highlight it. Is your audience more about comprehensive considerations? Highlight the risk areas you’ve explored and addressed. Know what your audience cares about, and ensure your synthesis considers it. Know what they don’t care about, and save the time and energy.

Don’t be too long. Nobody wants to read 50 pages to get to the point.

Be as long as you need to be. Don’t be too short, either. If there’s key callouts you want to make, or particular pieces of evidence you want to highlight, you should do so, provided the information is not duplicative of points already sufficiently made.

Link to the details. Some people are keenly interested in the details. You don’t want to mix up or muddle your message with over-detail. Instead, link to supplemental materials or add footnotes where details might matter.

Be medium-appropriate. Don’t paste a 1,000 line message in a chat. Don’t write a short-hand message with typos on Confluence. Understand the characteristics and expectations of the communication medium you are using, and stick to it.

• Documentation stores should have formal, clear, concise written text with long-lived content.

• Instant messages should be 1-3 sentence summaries with links to documentation.

Sync content across mediums. If you’re making a decision and you’re communicating it in one medium, make sure it reflects in another medium. For example, if you make a key decision on a Slack thread, be sure to update your decision log on Confluence immediately.

Be correct. When you synthesize, you lose a bit of message and communication fidelity. Make sure that your message is still accurate, or else you may be unreliable delivering incorrect information that would change a decision.

Get feedback. Getting someone to look over your synthesis and give you feedback can be nerve-wracking or even uncomfortable, but extremely valuable learning opportunity. I’ve seen many Product Managers get stuck at a low quality because they dismiss the feedback they get or don’t ask for it, assuming everyone likes what they are doing.

---

A failure to synthesize

I worked with a Product Manager a long time ago that had extreme difficulty synthesizing information.

They did great at talking to users and getting tons of information from them. But, when it came time to communicate that to the broader team, they gave word vomit, stream-of-consciousness notes instead of clear, concise statements.

When they did a user interview, they shared unfiltered, disorganized notes. When they wrote a problem statement, they blurted out every single thing they knew without a cohesive narrative.

Nobody could make heads or tails of what was being asked, what the intent was, why it was happening, or what the details were. The 10+ page documents that were shared had great information here and there, but could have easily been reduced to 1-3 key sentences. The team, being busy, rarely read the poor quality, unclear documents.

Eventually, the team had enough and just started ignoring the Product Manager and did their own thing. When the Product Manager complained to upper leadership, they couldn’t help because they didn’t understand what the Product Manager was saying, either.

As the relationship between the Product Manager and the team soured, so too did the quality of information back to the Product Manager regarding feasibility, progress, or other insights. The Product Manager started to lose accurate ground-truth visibility into the product they were responsible for, which in turn negative affected their communications to others even further as the information was now starting to become inaccurate on top of being disorganized and unclear.

Eventually, that Product Manager was side-lined. Nothing they said was ever trusted or had any influence simply because they couldn’t effectively communicate it. They eventually were shifted out of that role and left the company.