Structuring a product discovery knowledge base (pt. 4/6)

Alex Cringle
Product Coalition
Published in
5 min readJun 30, 2020

--

Available on Unsplash

This article is part of a wider guide on how to establish a product discovery framework in your organization.

Most companies have the intention of being customer-focused from the start. In the early days of a company, it’s easier for the majority of colleagues to be informed about what problems are arising with their customers, what problems need solving, and for everybody to be aligned on these points.

Challenges start to happen when a company hits that hyper-growth mode and the employee count sky-rockets. New roles get created and layers begin to form between employees and the end-customer. This is where having a structured product discovery knowledge base comes in handy.

This disconnect between employee and customer might be alright for specific roles in the company, but is it OK for people who are responsible for representing the customer? Designing and building products for the customer? Or selling and marketing to potential customers?

Establishing a product discovery infrastructure that scales with the growth of the company bridges the gap between people seeking information about customers and those creating it.

For colleagues to be informed about insights that are being generated from product discovery practices within the organization, the structure needs to be:

  1. Accessible
  2. Organized
  3. Validated

Make your insights easy to access

One of the most useful things for me as a product manager, especially during the first few weeks of joining an organization, is to learn more about the company and its customers.

When it comes to customer insights, who they are, what their experiences are like with the product, what issues they face, and anything else I can get my hands on helps me massively in getting up to speed and solving problems. Unfortunately, it is often tough to get this information easily and requires lots of digging around different parts of the company.

From the other side, as an established member of a team, I’ve also had a great experience building up a knowledge base of customer insights and being able to be the one that points new joiners to it. It’s great to see how fast they get up to speed with the problems being solved by the organization and why.

Generally, it’s extremely useful for the rest of the company to be able to review the latest insights, how they were produced, and how they were validated.

A simple way to do this is to use the filing or information system your organization has. In my case, it’s usually a shared Google Drive, but it’ll work just as well with other systems, such as Confluence.

Example hierarchy for your knowledgebase structure

Categorize for easy navigation

Begin by making a top-level folder and labeling it User Research or something like that.

The sub-structure should be designed to get people the information they want to see as efficiently as possible. I like to break it down into three categories:

  • Learnings
  • Guidelines
  • Feedback by channel

Learnings

Put all of the learnings from past discovery initiatives into this category. This excludes information such as live web analytics. There should ideally be separate dashboards hosted in your business intelligence tools for this but if some of this quantitative information was used throughout the process it should be reflected here as well.

As time goes on, you can create sub-folders based on timeframes such as quarters or years. It depends on how much content you produce and how you want to manage it.

Taking the example of an initiative ‘’Insights about new target audience X’’, you can break it down into 3 sub-components:

  • Outputs: final learnings that were presented, test results, primary and secondary research
  • Inputs: copies of interview notes, audio recordings, user profiles, secondary research
  • Expenses: trust me — you and your finance team will thank me later!

Guidelines for all

This category of the structure is where you warehouse information relating to how things work in discovery land. This is as important as the learnings because it informs people about the processes that the organization follows to create insights, which indirectly builds trust with stakeholders.

When people have a question about how something is analyzed or conducted, they can be directed here. It also guides other people conducting discovery.

Examples of guidelines:

  • Interview note-taking tips
  • Conducting interview techniques
  • Validation processes
  • Analytics exercises
  • User profile building
  • Research methodologies
  • Tools your company uses

Governance is your friend

Believe it or not, governance plays an important role. Security teams have governance. Compliance teams have governance. So should product discovery.

Here’s some examples of governance content that are worth maintaining.

  • Which tools the team uses — sometimes your team can’t use specific third-party vendors for compliance reasons
  • How interviewee data should be stored and processed — especially for organizations that are regulated by GDPR or strict regional data policies
  • Policies — including types of questions you can’t/shouldn’t ask, or information you can’t share with customers
  • Process for getting incentives and budgets signed off
  • Process for recruiting interviewees and communicating with customers
  • How to align with other teams — especially important for B2B companies involving relationship managers

Having these sections — with content — means your team has been putting in the effort that will create a lasting structure.

Keeping the house in order

When it’s time to present your insights for future product prioritization, marketing, or any other purpose, the team has a higher degree of confidence in these insights when you have clear validation and documentation of your results.

When creating a report, you would link your ideas and statements to specific research via an appendix. This validation builds trust with your audience.

Manage your research findings in the same way.

Storing the inputs is the first step. But, you don’t want your archive ending up like the inside of my downloads folder.

Keep it organized, so you don’t waste time later on trying to figure out where a specific insight is saved for a presentation you need to put together later. Maintain an appendix in each project folder to audit where different information is used.

It’s also a great way to showcase all of the work the team has been doing and how it has evolved over time.

Up next — Funneling and standardizing feedback.

Questions? Feedback? Get in touch.

Access the rest of the articles in this series at www.alexcringle.com

--

--