Track and communicate your Product data schema with this Notion template

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.

Moving our schema to Notion

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 👇

‍

Purpose of this schema doc

We built this doc to serve two purposes:

1. To give the team a single reference point for all of our tracked product data; and
2. To help us manage the implementation of requests for additional data.

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.

How to read the schema doc

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:

• STATUS: Like I mentioned, we use this doc to track the implementation of new events/data. So we have 4 different statuses for each — Requested, In process, Live, and Depreciated.
• TYPE OF CALL: This is used to differentiate between events and trait calls.
• EVENT NAME: This is our main name column. For events, this is the actual name of the event that is triggered (with the proper formatting). We leave it blank if it’s a trait call so it isn’t confusing.
• RELATED FEATURE: This is an important “tag” which makes this a good reference doc. Many times when trying find tracked data, the feature it is related to is a typical mental taxonomy. So every data point is tagged with a specific feature (we do have a General category for those not tied to a specific feature).
• PROPERTIES: These list out any properties that are tied to a specific event.
• USER TRAITS: These are the user traits that need to be updated.
• ACCOUNT TRAITS: These are account traits that need to be updated.
• FRONT OR BACKEND: This is for the engineering team to track whether or not this is something that is tracked via the front or backend.
• GITHUB PR: For the engineering team to enter the PR where this data point was implemented — for easy, future reference.
• GO-LIVE DATE: Engineering should post the date this data point is implemented for easy, future reference.

Obviously, you can add/subtract anything else that makes sense for your team.

Things I like/love about this template

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:

• Permission management: Obviously, this is a basic feature of any shared docs, but I do think Notion’s sharing is very easy and intuitive. For us, the Product team owns this doc and is the only team that can edit the doc (add new requests, edit status, make changes, etc). Everyone else is given comment access in case someone needs to ask a question or make a note for future viewers.

• Table view plus individual cards for each element: This is where Notion tables leapfrog your typical spreadsheets/tables. Any element (row) can open up to a more detailed view (in our case, it’s the event name in each row). This allows you to enter more details about each event/trait — whether that be engineering specs or more explanation for those using the data. It’s really the magic feature here. We add a lot of information here (more than you are seeing in this template).

• Filtering/sorting: This is super important. Being able to filter/sort each row allows the user to easily find any specific group of items for which they search. For example, if they want to see all the events tracked against a specific feature, they can filter the RELATED FEATURE COLUMN and find everything they need.

• Search: Notion search on a table is pretty badass. Another thing that makes this doc a reality for us.

• Multiple Views: Another key feature of Notion is the ability to create multiple views for each set of data. For this doc, we have the main table as well as a Board (ie — a kanban board) to track the requests for new data. We also created a table that is filtered to show only new data requests — making it a bit easier for engineering team to find these requests.

What I don’t love

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 🙂

Would love your feedback

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!