Zettelkasten for Indie Devs and Product Managers

I finally figured it out. I’m not an academic, I build apps. So, I wondered how I could apply Zettelkasten to my work.

I’m not just coding, I’m also receiving constructive user feedback. This is usually about bug reports and feature suggestions. However, sometimes I get flooded by emails and messages. There are more good features than time to build and every feature needs some serious thinking and planning. So, my role I cover here is a mix of developer and product manager.

I was using Jira, a project management software to collect, manage and plan feature ideas and bug reports. But it quickly grew to over 1000 items. It’s mostly useless now.

Then I started my Zettelkasten and I’m not opening Jira any more.

What is Zettelkasten?

German for ‘slip-box’. It’s a simple, but powerful note-taking system allowing you to build a second brain. The Zettelkasten was invented by Niklas Luhmann, a highly productive German sociologist. He published more than 70 books and 400 scholarly articles and attributed his productivity to his notes. His slip-box contained more than 90,000 notes.

Intentionally, the Zettelkasten fits and complements our imperfect and biased brains and I think that’s how it ‘just works’. Many good productivity principles are baked in.

Here is how I translate it to my work

In Luhmann’s work, Zettelkasten was used in an academic environment. Here is how I translate the academic Zettelkasten to a ‘Product Development’ Zettelkasten. On the left is Luhmann’s version and on the right mine:

1. Input: Reading books and academic articles = Feedback emails
2. Capture: Literature notes on books = Feedback notes
3. File notes and link: Permanent Zettelkasten notes are the same for me, short, atomic ideas for features, clarifications, question, interconnected where it makes sense.
4. Interim Output: Manuscript for an article or book = Feature specification document
5. Final Output: Final Draft for an article or book = Written code implementing a feature

The process is largely the same

Every morning, when I read my emails, I take quick notes about the content and copy/paste the link to the original email (Gmail link in my case). My notes are very short and written in my words. Sometimes the title of the note is all I need, other times I elaborate a good idea or clue I found in the email. These notes are only temporary. I store them into an inbox folder at first (as recommended by GTD), waiting to be processed later.

It’s critical to write all notes in your words and as short as possible, don’t copy and paste the content. It’s unlikely you read the full email again and often a waste of time. But just in case, you got the link.

Then, on the next morning, I process all accumulated inbox notes at once. By splitting the capturing from the processing process, your brain doesn’t have to switch contexts and you can work with less effort.

In that process I take the inbox note, quickly evaluate if it adds anything valuable to my system and either delete it or elaborate, then file it. If I decide there is something useful in it, I create a permanent slip-box note which contains a single, atomic idea. Again it’s written in my words. I look into my network of existing notes (sometimes using the search function) to find other notes which have the same context and link them together to a chain of thoughts with branches (not unlike GitHub).

During that process your brain often starts to have more ideas, so I create more permanent notes as good ideas come to me.

How is this useful?

After some time, you build a dense network of ideas. Clusters emerge. In my case, around feature ideas. If a particular feature has many connected notes, my understanding on that feature is probably very mature. I can browse through the notes (since they have clickable links) and create a draft for a specification document.

Without the Zettelkasten you would have to brainstorm and rely on your fragile memory to write that spec or worse, dig up the emails and read them again, out of context. So, naturally you spend much more time and miss important details.

And finally, you write well thought through code out of that specification document. The details are based on actual user feedback have matured over time.

Where I’m now

Today, I have 909 notes and I have used this system for a few months. I created several slip-box folders: features, bugs, general and business. Notes can be still interconnected between the folders, it’s just easier to find related end-points this way. In general you shouldn’t restrict yourself to specific topics though.