Documentation
Write a lot. You never know when it might come useful.
For starters, this newsletter is taking a new direction. So far we had written this as an “insiders” newsletter, to let who we think are friends of Babbage know what is happening in the company.
Now, having almost closed our angel round, we have “real insiders”, who are our investors. And then we need a company blog. And so we are repurposing this space as our company blog, and opening it up for subscriptions (we’ve got a handful more than what we added, so far).
Random Documents
Recently I was going through some random file on my computer, that I had last edited in April 2024. This was a very long R notebook, where I had done a bunch of data analyses, and then suddenly the notebook had pivoted into some Babbage related stuff. While analysing some data, I had suddenly got a bunch of thoughts on how we would get the system we are building at Babbage to analyse data, and I had written copious notes on that.
Suddenly panicking that these notes are languishing in a place where nobody can see them, I quickly copied them over verbatim into one Google Doc, and shared it with everyone in the company.
A day or two later, Manu discovered another similar document, this time a spreadsheet on Google Sheets, where I had again documented some of the things that we had wanted to do. This was again written back in March or April 2024, and then lying forgotten.
At some level, they are fortuitous discoveries. Then again, looking at them now, I realise they encapsulate some of our thoughts from back in the day, which we have completely forgotten now. And if we had not bothered documenting those thoughts when we did, there is a finite chance that they would have been forgotten!
To give readers some historical context, we started Babbage sometime in December 2023 (when I finished my stint at Delhivery, and Manu wrapped up some consulting assignments). For the first six months, we did no “production work”, instead we sat in one room in a coworking space close to Bilekahalli, thinking and talking in terms of the details of what we were going to build.
And we wrote.
While we were cooped up in a room then, it was clear right from the beginning that we would be a “remote first” company, and that meant that we would need to document extensively. So in that period, we produced artifacts such as a “70 page product document” (which has since gone through several avatars), and random documents such as the ones we found last week.
Thinking time
In some sense, those early months when we spent time just thinking rather than building are valuable, in that we could think without being constrained by implementation details. Now, this may not be how most startup founders think, since there is usually an emphasis on getting things done and “always be shipping”, but the beauty of the thinking time was the lack of constraints.
It is doubly important that we spent our thinking time also writing, since that means that a lot of the thoughts that we thought then that didn’t immediately make it to the first version of the product could reside somewhere. Looking back, given how much is happening in the company now, there is very little mindspace or bandwidth for this kind of thinking, and so I’m glad that we managed to write it down back in the day when we thought.
On PRDs
Recently, Lenny Ratchitsky interviewed Mihika Kapoor of Figma, on “how to ship like a startup”.
The first point she makes here, which I instantly resonated with, is to do with PRDs (product requirement documents). She says:
🤨 BigCo status quo: A PM’s job is to write detailed PRDs to kick off projects and keep teams aligned.
🏃 Startup mindset: Speed and experimentation matter more than documentation. Anyone with an idea should be empowered to explore it through prototypes.
And this is doubly true in analytics and data science, where you don’t know how you are going to solve a problem until more than halfway into the process of solving it.
I remember getting into many skirmishes with the product team at my previous company (actually a lot of my time in that company got wasted skirmishing with the product teams), and one of the issues was my refusal to write documentation before solving any problem. I would write it after solving it.
In any case, last week I found Lenny’s post shared on LinkedIn and quickly reshared with my opinions.
And in the comments there, one thing that came out was that PRDs or not, the important thing for a company is documentation. And I was thinking about that when Manu surfaced that old Google Sheet that I’d written last year.
I think for our company we need to modify one of Amazon’s leadership principles and make it read “write a lot”.