Good product data is an essential part of any modern software company’s operation. It ain’t just for product analytics anymore. Marketing needs it to effectively target prospects and users. Sales needs it to understand which trial accounts are worthy of attention. Customer success needs it to help them identify issues and opportunities. Operations needs it to help support forecasting. This data is the lifeblood of software business.
But one of the biggest challenges with regard to this data (beyond getting the product/engineering team actually track the data) is communicating what is being tracked — and what it is all called — to the teams that need it.
“What’s the event for X?”
“Do we track when someone saves a Y?”
“How do we know the name when a user creates a Z?”
“What do we call our subscription plans again?”
These are questions that haunt product teams on a regular basis. And the last thing they want to do is search through Github or an engineering ticketing system (Jira, etc) to find these answers.
What’s worse, however, is when the team DOESN’T ask these questions. When they don’t know what is tracked — what’s available for them to use. And this happens a lot. You can spend a lot of time tracking this product data, but it goes to waste because the people who need it don’t understand it.
It’s really important to have a “public” product schema so that everyone on the team can be on the same page with your product data.
Over the last several months, we have moved our knowledge base to Notion. One of the last pieces we brought over was our product data schema (we used to track it in Github, then we moved it to a Dropbox Paper doc). This has been super helpful for us, so we decided to create a template that anyone can use. You can grab it here 👇
We built this doc to serve two purposes:
I know it’s not easy to combine these two goals in a single doc, but it is working well for us. Obviously, this doc doesn’t replace an engineering system, but when we need to implement new data, we simply reference this doc in the engineering ticket. It has worked really well for us.
This template has a bunch of columns (which Notion calls “properties”) that serve as the basis of the information we need to know about each piece of data. Here is a quick explanation of each one:
Obviously, you can add/subtract anything else that makes sense for your team.
In general I’ve become a fan of Notion. It took me a while, but our relationship has definitely grown stronger over time the past 3–5 months. Little-by-little, we have moved most of our knowledge base here (and more). I find the Notion docs to be very versatile for all of our needs — I really like having docs that allow us to use text and embedded tables/boards (core Notion offering). This alone makes it possible to build a document that can serve multiple purposes and keeping people on the same page. It is not easy to find something that can serve as a meeting place for engineering and go-to-market teams alike.
Some more specifics on my love affair with this doc:
Obviously, this isn’t a perfect solution. Spreadsheets/tables are generally a bit clunky and cumbersome for users. Notion tables are far more friendly than other options, but they still can be clunky. For example, I don’t love how the table hangs off the edge of the page and requires a bunch of awkward scrolling. But that’s being picky.
This doc also doesn’t do a good job of listing out each individual trait or property that we track. We may create a supplemental document or table for this. Need to figure this one out. As of now, our teams can search for a property/trait and get the information they need — it’s just not idea.
Finally, this is also a document that is manually created and updated. It is not an application that can update automatically based on changes in the code (or Segment) or carry any real time data from the product. That would be nice 🙂
The template is free for you to use in your instance of Notion. We’d love to hear how it is working for you and what adaptations you make to it to make it even more valuable. Happy tracking!
The SaaS business model has long challenged the need for the traditional software salesperson. The SaaS model – and more recently the push toward Product-Led Growth with its free trial and frictionless upgrade path – has called for the death of sales.