With team knowledge spread across many different tools, how do we find what we need? How do we even keep track of all the documents, data, and pieces of content we have for a single project? When we couldn’t find an existing solution to our own problem, we found that there were many others in the same situation.
My cofounder and I met when we both worked for one of the tech unicorns in San Francisco. As product and engineering managers, we both shared the same problem: how to stay organized and on top of all the different documents, data and pieces of knowledge spread across the variety of tools our teams were using every day.
Here is what I mean. We had PRDs, RFCs, and other documents in Google Docs; designs in Figma and UX prototypes in InVision; dashboards and reports in Tableau, Metabase, Datadog and spreadsheets; presentations in Google Slides; tasks in Asana; bugs in Jira; code and implementation comments in GitHub, documentation in Lessonly; images and creative assets in GDrive, and support tickets in Gladly and Salesforce. This was in addition to the myriad content we had in emails, calendar invites, and on Slack.
I once counted all the tools I had to use in a single day to get information and data for just one particular project, and the answer was around 10. At least once a week, this number jumped to 20. While these numbers may be higher than those of most workers, the underlying problem is the same: with our collective knowledge spread across so many different tools, how do we find what we need? How do we even keep track of all the documents, data, and pieces of content we have for a single project? How do we make sure everyone on the team knows what else is out there and can discover and use it when needed?
Let’s step back for a second. Do we really need all these tools? I get slightly annoyed every time I see a “Person X has invited you to use tool Y” email pop up in my inbox, introducing yet another tool where our knowledge can get siloed and lost forever. Engineers, in particular, are very good at finding the next “best” tool and introducing it to the tech stack, while open company cultures and modern managers make it very easy for them to do so.
But to flip this around, why not use the best tool for the job? For example, I could be using Google Slides to create flowcharts, but when things get complicated, Lucidchart is indeed more powerful, so I can create better content faster. Using specialized tools, or just tools we have already mastered, improves our productivity, so limiting our tool choices wouldn’t really make sense. Moreover, being unable to use tools we like would make us less happy, which would probably reduce our productivity as well. Realistically speaking, restricting tools is probably also easier said than done. IT administrators don’t really care that we use many tools, as long as they don’t have to support them. This means everyone can enjoy the freedom of introducing and using whatever they like, and we believe this is generally a good thing - as long as we can stay on top of all of that.
Our initial “solution” was to have all relevant documents and pages bookmarked in the browser since it was the only underlying platform all the tools shared. This worked poorly and resulted in long and hard to read lists that were not shareable.
When a new product operations person joined our team, I remember searching through my bookmarks, inbox, and drive by the project name, trying to remind myself of all the possibly useful documents we had and sharing them one by one. I didn’t even need him to look at all this content right then; I just wanted to make sure he knew it existed, in case he needed it in the future. Truth be told, I had little confidence he would be able to recall and find it in his inbox once it was actually relevant.
We also tried to bend and abuse a few other tools to do this job for us (Pocket and Raindrop, to name a few), but these tools are really not optimized to handle work documents, data, and web-based tool content. Sadly, bookmarks were still our best option, as impractical as they were. We knew exactly what we wanted; we just couldn’t find it anywhere. Based on occasional talks with our friends and other product and engineering managers, we were surprised by how much our challenge resonated with others. So one day, we decided to take a stab at building our own solution.
1. We wanted to have one place where we could see and organize all documents, designs, dashboards, updates, and artifacts that logically belonged together, regardless of the tool that hosted each of them.
2. We wanted to be able to add a new piece of content into a set quickly and conveniently, so that the overhead of the organization wouldn’t outweigh the benefits of being organized.
3. We wanted to structure the sets to match the way we actually work. For example, I wanted to be able to organize my documents by project (e.g., anything related to Drup) as well as by type (e.g., all monthly stakeholder presentations)
4. We wanted to be able to share each set with our colleagues, so they could discover relevant content that might not have been shared with them directly. No more “I didn’t even know this existed,” and no more duplicate work.
These simple but powerful product requirements defined Drup, a new web-based tool that we have been building for ourselves and everyone else who wants to improve individual productivity (and sanity!) as well as team collaboration.