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.