Notion has conquered millions of users since its launch and at Reboot we have also succumbed to its charms. From the beginning we use it for internal management of projects, tasks, meetings and knowledge. Virtually anything that needs to be written is in Notion.
However, we felt that despite documenting and monitoring each project in Notion internally, we were not involving the client in this process and we continued to resort to chains of emails, messages or meetings every time we wanted to make a product decision.
At Reboot we are great advocates of asynchronous work. To create good products you need a state of focus that is impossible to reach if we constantly interrupt the team with meetings. For this reason we decided to create a project dashboard in Notion to which we give access to the client and which allows us to have a fluid and constant conversation without falling into meeting fever
At Notion we have a "Projects" directory where we create a page for each new client we work with. Within this we have a private part for internal use and the dashboard shared with the client.
The structure we follow is:
- Briefing: here we detail what the project consists of, the goals and the services included.
- Design: as all our projects include design work, here we document references, images, links and any material that can help us.
- Stakeholders: list of all the people involved in the project with contact details and their role
- Meeting notes: all the meetings we have are documented with the agenda, the issues that have arisen and the main conclusions of each meeting
- Documentation: documentation related to the project, such as the list of functionalities, services to be used, among others.
- Accounts: all accounts of the services that are used in the project.
- Proposal, Contract and Invoices: these do not require further explanation, they are all legal documents, invoices and proposals.
- Project Dashboard: this is the dashboard shared with the client where product decisions are shared, feedback from each phase is managed and tasks are monitored.
The project dashboard allows the client to know at all times what is happening, what tasks are completed, which ones are being prioritized and what product decisions have been made.
To do this we invite the main stakeholders of the project with full editing permissions to the dashboard. In this way they can collaborate with us on tasks, add comments or create new topics if they need to touch on a specific topic.
Let's see in detail how the Dashboard works.
This is where we do project management. Tasks are classified into Not started, In progress and Completed. Each task has a detail where it is specified what is going to be done and the client can add comments if they consider it.
Although the client has permissions to create and edit tasks, we try to prevent this. As project executors, our responsibility is to define and specify the work to be carried out and, although the client is welcome to suggest new tasks, these must first go through the team.
This is probably the most important part of the dashboard. We create a new thread for each deliverable that we share with the client and that requires approval. In this way, we not only attach the link to the Figma or material in question, but also provide sufficient context so that it is understood what it is about and what we expect from the client.
Thus, all the feedback that is generated on the deliverable in question is ordered, documented and contextualized, something that is impossible if we use long email chains.
On the other hand, we also use threads to create what we call "Product decisions". Those of us who work in product know that no matter how much definition we have, there will always be things that will change as we begin to build. Perhaps the API does not have all the options we thought or we should change a user flow to adapt it to the new situation.
In any of these situations we create a "Product decision" where we explain the context (what we have discovered) and the solution (why we think this is the best solution). When we have enough information and context to make the best decision, we do not involve the client and simply serve as documentation so that they can review it later and have context of the entire process.
As always, the goal is not to generate a new meeting for every fork we come across along the way. The client can asynchronously review what is being worked on and what decisions are being made and, if convenient, only then do we schedule a meeting to discuss it.
At Library we have all the resources that can help the client to become familiar with our tools and processes. For example, we have a very simple guide on how to use Figma to review materials or leave comments. We also have another one on how to manage feedback in Notion so that everything is organized and accessible.
We're still getting started, so our library of resources will likely grow as we spot areas that need further clarification. It is not about overloading the client with hundreds of documents that he must read to work with us, but rather giving him a place where he can go at any time if he has any questions. Of course, we are also there to solve it.
Finally, we have a calendar where we write down the meetings and important events of the project. We mainly use Google Calendar to manage meetings, since it syncs wonderfully with Google Meet, which is the video calling tool we use. However, we like to replicate the meeting calendar in Notion so that the client can have a clearer vision of when we will meet and the date of the important deadlines.
At the moment, we have been operating with this new system for a few months, so it is still too early to draw conclusions. There is still a lot of reluctance - voluntary or involuntary - to abandon the use of the mail for absolutely everything. Of course, we believe that there are better ways to manage product development that provide greater understanding and transparency to the entire process.
We will update you with the successes -or failures- of this new asynchronous management model.