This is a post in a blog series on "things we learned while bootstrapping from 0 to $10M in ARR". Follow me on Linkedin for new posts.

“Documentation” doesn’t typically trigger outbursts of excitement. The image that comes to mind are dimly lit cabinets populated by shelves that are stuffed with dusty folders containing grey-ish paper that nobody wants to ever look at again.

But we are building a company that focuses on a continuous cycle of feedback and learning - and solid documentation happens to be the foundation of future learning. We also bootstrapped that company for a long time, so our learning approach needed to be scalable from day one.

That’s why - after outlining our story in the first post, and focusing on the strategic question of co-founder relationships - the third post in this bootstrapping series makes an argument for investing into scalable documentation, and not just doing this, but doing it really well, from day one.

Moon module manuals

The level of our detail of our internal documentation regularly comes up as a top contender when we ask new colleagues what surprised them most during their onboarding phase.

Our knowledge database is far from perfect - information ages surprisingly quickly and there are many parts that could be much more organized. But on the whole, our documentation probably resembles that of the extremely detailed manual of the Apollo Lunar Module (with details on propulsion, navigation, communication and what not), rather than the flimsy slide decks and creative chaos of some early stage companies.

While we didn’t rationalise this until later, solid documentation has been part of our DNA from day one. And it makes sense. Bootstrapping forced us to make learning scalable from day one.

Divide & conquer

For two years, we were a team of two. If we wanted to maximise the exposure to users, customers and partners, it was not an option to hold large discovery meetings where both of us would be present. We had to split up and share the learnings asynchronously.

We agreed on rough common formats and started to meticulously document our meetings. As a result, we still have Google documents with hundreds of pages of learnings from early customer interviews and user testing sessions.

Each morning, with a cup of fresh coffee, we would read through each other’s notes of previous days, comment, ask follow-up questions and highlight core insights. We learned more quickly, could iterate faster and avoid a couple of mistakes that we simply couldn’t afford to make.

Centralize knowledge management

Of course, building an internal knowledge base in Google docs in a growing team is somewhat akin to trying to build a sand castle with a spoon during a beach volleyball tournament - it is hard to establish structure, the pace of learning is high, and new stakeholders get involved all the time.

As the company evolved and we reached a certain team size, we therefore introduced Notion to document core processes and insights, give everything a better structure and make things more easily accessible.

Yes, the initial setup is an investment of a few days, and it does require ongoing maintenance. But it’s one of those investments that you do once and that yields continuous payouts: Every new Leapsome employee gets a personalized onboarding checklist (and dedicated Leapsome learning paths) with links to all relevant early insights for each team, helping them to become productive very quickly.

In addition, knowledge that you don’t require on a daily basis (and which you therefore don’t know by heart) is still easily accessible. So instead of having to reinvent the wheel every time when trying to find the right database field or adequate competitor talking point, you just look the knowledge that’s maintained by a core group of knowledge experts.

Things that worked well for us:

• Investing into a user-friendly database (we use Notion, and it’s great)
• Having a tooling champion (shoutout to our “Notion wizard”) that helps to optimize the setup
• Mandating that all knowledge has to live in that database (no more rogue Google docs)
• Assigning clear ownership for documentation & maintenance of different teamspaces
• Using re-usable “content blocks” where possible (reduces the maintenance overhead)
• Linking content in onboarding checklists and learning paths to enable discovery from day one

Document meetings to allow for asynchronous participation

Solid documentation also trickles down to our daily meetings - and while meeting effectiveness will be the topic of another posts, here are some highlights. We use our own platform to plan meetings and document outcomes and action items which are easily accessible to all meeting participants - and the ones that (consciously) missed the meeting.

Things that worked well for us

• Establishing clear templates for all recurring meetings (clear sections / questions)
• Making preparation mandatory - what’s not on the agenda won’t be discussed
• Adding takeaways to the meeting notes
• Allowing read-only participation (not everyone has to physically participate in the meeting)

Train your (future) digital assistants

With the recent of proliferation of generative AI tools, solid documentation will very likely bring another benefit: The option to train (future) tools based on your internal knowledge base. The more structured and detailed your internal documentation, the more precise the answers from your future digital assistants will be and the more time you will have to focus on things that really matter.

Investing into a scalable learning infrastructure has a compounding effect from the first day onwards. The sooner you think about how you can scale the learning effect from one-to-one to one-to-many, the faster you will be able to spin the flywheel of feedback and learning, and the more efficiently you will be able to deploy the limited resources you have.

‍