How we survived pandemic by scaling Knowledge Management System with Notion
About four months ago, we embarked on a quest to build an internal Product & Design Team wiki-cum-workspace on Notion.
1 year into lockdown, 2x the team size, 3 key principles
The month was April 2021. It was a year since Jakarta was effectively locked down due to the COVID-19 pandemic. For one whole year, most of our team members had not stepped foot in the office. By this time, everyone had more or less settled into their WFH routine and adjustments in the business process had been put in place. At the same time, this time around, the team had been growing (has been, and will continue to grow) quite rapidly. And with this growth comes more complex work with more layers of coordination. These two factors, extended remote working and rapid team scaling, have made us rethink how we should best manage knowledge flow within the team.
Notion was initially used by designers and researchers as a notebook and archive for research; it would be filled with pages on research plans, user testing notes, and insights documentation. The team gradually wrote best practices, standard procedures, and miscellaneous work docs on the platform as well. The Notion pages were filled with information that was not categorized previously in Atlassian and the Google Suite, both of which were used for more structured deliverables. We found that Notion features like the page architecture, database relations, and integrations with multiple services were very helpful in documenting and communicating much of our work. Thus, we decided to work on Notion to build an internal knowledge management system.
When we started, we discussed extensively on what we want to accomplish by revamping the Notion workspace. From that, we thought of three key principles to be embodied in the system as we define how we might design the architecture of the new Product team Notion space:
- Visibility
- Flexibility
- Convenience
And so the quest begins…
1. Picking it up, or: the initial conversations
“How did it pick up?” We started discussing with colleagues and leads to scope out what exactly their pain points are and gain creators are. We dived into the workflows of Product Managers, Product Designers, and other team members in their day to day work and planning.
“What was the initial output?” To kick off, we then continued to define the general use cases of the system and brainstormed a high-level idea for the page map. We defined the use cases based on one’s journey as an employee (onboarding, day-to-day, planning, managing people):
- As a new Product team member, I want to gain context on work quickly and efficiently.
- As a Product team member, I want to have a space to track and document my work flexibly.
- As a Product team lead, I want to track progress and ensure alignment between different squads clearly.
“How did we come up with the high-level idea?” In defining the initial idea we wanted to explore, we considered several options, and it boiled down to two top-level organizing units:
a) grouping the top pages based on quarter, or
b) grouping it based on durable squads.
After a session of rapidly sketching up a rough page map, we decided to go forward with groups as the highest order in the workspace, along with a product homepage and a page for Head of Product workstreams. We went on with the groups-and-squads model because it is durable and reflects the arrangement of the team in general.
“What do we pick up now?” We decided to focus on creating the group and squad pages first, instead of document templates and the product home page. More or less, the work is divided into two phases: Phase 1, restructuring, and Phase 2, templating. By restructuring, we mean to create the skeleton of the system, keeping in mind the interactions and making sure it can cater the use cases previously defined. In “templatizing”, we refer to the templates of the documents that are to be stored in Notion. This includes the different research docs, best practices, how-tos, and other types of documents that we may not think of yet.
2. Building the database
“Why did we come up with the idea to use a database?” We saw that there’s a need to make the repository centralized and synchronized between pages across groups and squads (i.e., if the cross-squad initiative page is updated by one squad, it should also reflect in the workspace of the other). With some desktop research and hours looking into keywords like “Notion workspace best practices”, “Best Notion group workspace”, and “How Notion uses Notion”, from blogs to video tutorials, we tried to apply the database with a buckets-bolts-bytes system to our Workspace. In essence, this approach stands on two pillars: a centralized master database and contextual dashboards for viewing.
“How did we make it?” We started by structuring the buckets, bolts, and bytes in Product. The buckets are the high-level categories used to group work units, and in this case we are using our existing groups and squads. Bolts are things that measure progress, which for us are primarily the projects and initiatives we run. Bytes, in this framework, are basically resources; the documents and deliverables for all our projects. Overall, we defined the different tables in this database based on two factors, aligned with the buckets-bolts-bytes framework: first, hierarchy, i.e. which items are a part of which items, and second, similarity, i.e. whether the items would have the same key attributes.
These buckets, bolts, and bytes make up the Product DB, and are connected through a series of relations and rollup functions. On the workspaces, they are simply called and shown using customizable views.
“What was the database like?”
3. Designing the pages
“Why did we come up with the idea to use group and squad pages?” As mentioned in the beginning, we wanted to align the page map with the team’s main unit of operation for practical reasons. Unsurprisingly, after discussions with Product team members, the most practical way to do it is by squads, which are for the most part durable (team members would be in one squad for a long time).
“How did we make it?” We observed how Product team members work today. As with the case of autonomous product squads, there is no one standard workflow set in stone for everyone; different teams do things differently, even though the deliverables are more or less the same. This means that first, we had to take note of the similarities and differences between the squads and roles in terms of how they work, including the discovery-delivery cadence, the software used for different tasks, and the people they mostly work with outside of the Product team. From this, we tried to make a platform that is flexible enough to be used conveniently by everyone, but still structured enough for everyone to navigate each other’s work in brief. Then we brainstormed the layout of the pages themselves: which information should be put first, what shortcuts need to be made, what free text spaces are needed, which view should be default, and so on.
“What did it end up like?” In the final version of the page, we divided the page into a two main sections:
- The body, which makes most of the content of the page. This part consists of: a free-text squad brief, a shortcut view to OKRs, initiatives table, recent documents, and a taskboard.
- The sidebar, which is highly customizable, intended for the squad to put the most relevant shortcuts to other pages and quick links to documentation outside the Notion platform.
4. Rolling it out and getting the team to use it
“How did we roll it out?” A well-designed KMS won’t be well-adopted without a good roll-out process. We started with a launch session to introduce the structure and database concept with our internal Product and Design team. Then we held another session called roadshows to “train” the team and make sure they know how to use the new system.
In that session, we provide the team a quick view on how we design the database and what are the informations that we provide in this KMS. By understanding how data is stored in the DB of KMS, the team can customize the information needed in their workspace by pulling some information from the table and doing a filter and sort there. Along with this introduction Here we also gauge their practical concerns when using it.
“What were the initial responses?” We took some feedback from the team after the roll-out sessions. Some of them find it useful to have centralized documentation with the other squads. In particular, they can find out easily who are the recently-contacted users for a testing session in another squad without needing to ask them and go through the other team notes. However, some of them also find that it’s still quite hard to understand where to put what. Since we introduce the concept of DB and workspaces, they feel that they need to have more understanding so that it doesn’t break up the structure that we already made for this project.
Next steps
Based on the feedback from the rollout session, we compiled and did a prioritization session to decide when to do what. We measured the impact if we didn’t do something and what we would get if we did something. Based on that discussion, we plan to fix phase 1 first before moving to the next phase. We think that we have to make sure the team starts using the KMS first before we provide the template since they won’t even use the template if they don’t use the system to begin with.
The immediate next step is to fix the structure. Today, we only put the main document that we think the team will use in their day-to-day work. However, each team has their own approach to do their work. In this case, we are going to give them all of the documents related to their squad and let them pick and choose based on their needs, but still in a way that if the people from the other squad look at this, they can still find it in an easy way.
On the other hand, we initially had a brief idea on what to do in phase 2 of this project, which is the templating phase where we want to provide a kind of basic form of an empty document with placeholders and the description + questions to trigger the users on what or how to write on a specific section. So the plan is to enhance the phase 1 version then after that we can move to the phase 2 with a more established foundation.
For phase 2, we will use the same approach to learn and hear the issues encountered from the team before we move to brainstorm the ideas on what to build. Reimagining this KMS has a quite similar approach as building a product, it’s a never ending process but we want to keep this in a very small to small iteration so that we can get feedback earlier and learn faster. We believe that releasing the product to the users is the best way to learn in the real scenario.
This article was co-written with Ivan Abdurrahman
