Document Like a Starfleet Captain: Mastering Product Discovery Reports
At the beginning of every episode of Star Trek: Strange New Worlds, the Captain does a voiceover:
Space, the final frontier. These are the voyages of the Starship Enterprise. Its five-year mission: to explore strange new worlds, to seek out new life and new civilizations, to boldly go where no one has gone before.
That sounds amazing, doesn’t it?
Most of the time, our days aren’t so exciting. But there are a few things that we have in common with the Enterprise crew: we’re setting out to learn new things, and - like them - we need to document what we’ve learned.
Learning new things is hard enough. There are plenty of obstacles in our way at most companies. Again, like our favourite Starfleet crew members, we have to figure out when to just follow orders and when to bend them to get the actual job done, properly.
Finding the time to document what we’ve learned, to share it, and to consume what other people have shared - that’s often considered to be an afterthought. It’s not, though - your Discovery activity is not complete until you’ve done this. It’s not just a tick-box exercise, though; if you don’t do it, you’re missing all of the benefits of the research activity.
There are two ways to approach this - there’s what you do after each session, and what you share when you’re ready to make a decision.
After each chat, you’ll want to create a Discovery Session Report:
Actually, you need to start before any interview - fill out a template with the following information:
Write up a short brief that indicates your Hypothesis or Research Objective: What you want to find out from this session
The person’s name, position and company. Their LinkedIn profile is a good thing to include, as is a photo - it makes them come alive to anyone who’s reading this after
The interview date
Then, after your chat, you can jot down:
A few key findings that you learned
Any decisions you made as a result of this chat… but decisions are usually made after a number of interviews. This section will often reflect that. If that’s the case, it’s fair to say: ‘This indicates a preference for X, which is (in line with/contrary to) our current hypothesis. Decision will be made after we complete #Z interviews; this was #Y of #Z.’
Any key quotes that might interest the people you’re going to share this with.
And the final step: share it! This can be as simple as pasting it in a Slack channel. I’d recommend creating a Miro/Mural board or slide deck that includes all of the interviews you’ve done - it’s a great way for other people to get up to speed with the research you’ve done, and shows how much work you’ve put in.
Note: these steps are critical, yet they’re the steps that are most often skipped. Research that isn’t synthesized and shared may as well not have been done.
Why this is important: When making decisions, data trumps opinions. Unless you can share and cite the research that’s been done, all of your work is no better than an opinion. Sharing your research along the way goes a long way to creating a culture of empathy for your users, helping your developers and partners to get more involved in solving the problems, rather than just working to Jira tickets. Finally, it can generate better conversations - earlier - with people who have a vested interest in the area you’re working on.
Who this is for:
You and your direct team.
When to do it:
It should be written up quickly, in a debrief session immediately after an interview (if at all possible).
What this is for:
To give the people around you a TL;DR/at-a-glance understanding of what you learned in a session
To help them understand that you are talking to people on a regular basis
That you base your decisions on evidence
And to generate conversations with people who might have information to offer.
Why this works:
People are busy. Unless you share easily-consumable information on a regular basis, they have no idea what - or if! - you’re working on.
Give them something that’s short, punchy and relevant.
When you’ve completed enough sessions to make a decision, there’s a second stage: creating a Learnings Report:
This is a very similar document, but summarises the information from all of the interviews & activities you’ve done into a single page. This should include:
The start & stop dates of this activity
Who participated - names, positions and companies. Logos are a great way to reinforce this, too.
The Hypothesis that was being researched
A few short bullet points of what was learned
A key Quote or two
And the decision that was made
Who this is for:
Anyone involved in, or affected by, a decision your team needs to make.
That means stakeholders, partners & colleagues, and users/customers (where appropriate).
When to do it:
As soon as you have enough information to make a decision and need to share it.
For stakeholders and governance boards, this should come early enough so that it’s not a surprise to anyone involved in making or ratifying a decision.
For partners and colleagues, as soon as the decision has been made.
For users/customers, when appropriate to influence decisions that they need to make.
What this is for:
To influence discussions with people who need to ratify or approve a decision.
To inform partners & colleagues when a decision has been made, as well as the context for that decision.
To generate appropriate discussion and feedback on a decision.
To allow others to make their own appropriate decisions and plans based on the consequences of this decision.
Why this works:
Many decisions made by others feel arbitrary, especially if they are not what the affected people had hoped for or planned against. Understanding context alleviates that - or generates a higher-quality discussion when needed.
This is an easy template to circulate and re-use - it can be shared in Slack or email; and can be dropped into regular update decks for your stakeholders and partners.
Get the templates here:
You’ll also be opted in to receive infrequent email updates.