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 navigationAttendees
Product and Engineering: Joseph, Melanie
Support: Brent B., Brent C., CarlDiscussion
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.
Keep reading with a 7-day free trial
Subscribe to Joseph Gefroh to keep reading this post and get 7 days of free access to the full post archives.