A Spark File for Product Ideas
One of the challenges of building a startup, especially in the early days, is balancing ideas and execution. While any founder will tell you they have a long list of ideas they hope to eventually deliver, the reality is that focus is everything, and building a product customers want is worth a lot more than a long list of features.
That being said, there’s always a question of where to put the ideas. Bursts of inspiration can seem brilliant in the moment and fully worthy of getting a spot in the coveted backlog. As any product manager can attest, however, a backlog full of ideas, especially ones that are only partially baked, is pretty useless. A good backlog is full of work that a team definitely wants to deliver—features, improvements, and fixes that have been validated with prospects and customers. A good backlog is a well-groomed backlog.
So, where do all those great ideas go? When we started Variance, I looked for a new method for managing this question. While on the one hand, I didn’t want to lose my thoughts about the future direction of the product, on the other hand, I wanted to ensure the backlog was filled with only work we had high certainty we wanted to deliver.
Step one in that process was clearly defining what our backlog was for. Here’s what we keep in our internal doc on how we approach issue tracking:
The backlog is for features, bugs, or chores that are things we will definitely do at some point in the future but are not up next. It is not for "ideas" that we may do, which should be kept elsewhere.
But where is “elsewhere?” Here I turned to a writer that has inspired me for a long time with not only his words and ideas but also his methods: Steven Johnson. You may have heard of Johnson from his fantastic books like Emergence and Ghost Map, but for me, the first thing I think of is a piece he wrote in 2005 about how he uses a tool called DevonThink to keep an archive of all his research. This inspired me so much that I’ve emulated my own use of Evernote around Johnson’s approach and turned it into a second brain for myself.
These archiving tools aren’t the answer to my product idea question, however. For that, I turn to another interesting method introduced to me by Johnson: the spark file. The spark file was born out of Johnson’s desire to remember. Specifically, to keep better track of hunches and half-baked ideas that need time to mature. Here’s how he describes the inspiration:
When you're just starting out on a project, when you're in that early stage where you're still trying to figure out what you want to write in the first place—at this stage, it's the frailty of memory that causes problems. This is because most good ideas (whether they're ideas for narrative structure, a particular twist in the argument, or a broader topic) come into our minds as hunches: small fragments of a larger idea, hints and intimations. Many of these ideas sit around for months or years before they coalesce into something useful, often by colliding with another hunch.
Hunches, as we’ve all seen, don’t make for useful tickets. That’s because they’re not ready yet. They need more thought, more customer conversations, more time spent examining related concepts. They need to be built up more. And so instead of trying to examine them in the moment, Johnson just sticks each nugget into a file that’s ordered chronologically. “There's no organizing principle to it, no taxonomy,” Johnson explained, “just a chronological list of semi-random ideas that I've managed to capture before I forgot them.”
But the real magic, as Johnson explains, is going back over the file every few months. “What happens when I re-read the document,” he explains, “[is] that I end up seeing new connections that hadn't occurred to me the first (or fifth) time around: the idea I had in 2008 that made almost no sense in 2008, but that turns out to be incredibly useful in 2012, because something has changed in the external world, or because some other idea has supplied the missing piece that turns the hunch into something actionable.” He describes it a bit like brainstorming with himself.
Once again inspired by Johnson’s techniques, I decided to keep my own spark file, but specific to all the product ideas that inevitably come up when you’re building a startup. I gave it a bit more format than Johnson’s file, but not much. My product spark file has a few sections, and I move things around (copy/paste) as needed:
- Done: for all the ideas that have graduated off the list and into the product
- In progress: for all the ideas that we’re actively working on
- In backlog: for the ideas that have graduated from the spark file to the backlog
- Decided against: for the ideas that we actively considered and rejected
- No idea what I was thinking: pretty clear
- Ideas: the active list
I keep my list in Bear, but Google Docs or Apple Notes or anything similar do. There’s no formatting or fancy writing, just some bare-bone bullets. Every time a new product idea pops into my head that isn’t something we are either actively working on or definitely need, I just pop it onto the bottom of the list. Once a week (Thursdays at 4pm), I review the list along with some other maintenance tasks I like to do. In my review I tack some additional notes onto ideas (I’ll often just put a // and write another thought to the same bullet), I might move some thoughts around to other buckets, and just generally try to keep things clean and clear. The advantage is I get to hold onto my thoughts as a founder without burdening the rest of the team with unfiltered ideas that may or may not be useful for our future. Similar to what Johnson says, I often find an idea that started as a small kernel has many // additions tacked onto it before it eventually makes it into the backlog.
In the end, it’s become a powerful tool and routine for me. If you’re interested, here’s a simple Google Docs template you can use for your own Spark file. Hope you find it as helpful as I have.
