The Dashboard That Lived in My Head
Six months ago, I was convinced I’d solved productivity forever. I had wireframes covering my desk, a feature list that went on for pages, and the kind of tunnel vision that makes you skip lunch three days running. The product was going to be a dashboard that connected all your work tools—Slack, email, project management, calendar—into one beautiful interface. Think mission control for knowledge workers.
Nobody wanted it. Not my beta testers. Not the colleagues I’d pestered for feedback. Not even me, once I actually tried using it for a week. The thing I’d spent four months building solved a problem that existed only in my head. My process notebook from that time is brutal to read. Page after page of feature creep and zero validation.
What My Notes Actually Captured
I keep what I call a process notebook for every project. Not a polished journal, just messy notes about what’s working and what isn’t. Looking back at the dashboard project, the warning signs were everywhere. Week two: “Maybe I should add calendar integration.” Week four: “What if it could also handle invoicing?” Week six: “People seem confused when I explain this.”
The problem wasn’t technical. I can code, I can design, I can ship things. The problem was that I never wrote down a single entry that said “I talked to someone who has this exact problem.” Every note was about features, never about people. My process was recording my assumptions, not testing them.
The most painful entry came three weeks in: “Sarah said it sounds cool but she’s happy with her current setup.” I wrote that down and kept building anyway. That’s the entry that taught me process notebooks only work if you actually listen to what you’re writing.
The Three Questions That Might Have Saved Me
Now every project starts with three questions written on the first page of a new notebook. Question one: Who has this problem right now? Not “who might have this problem” or “who should have this problem.” Who is currently frustrated enough to cobble together a solution or pay money to make it go away?
Question two: How are they solving it today? This isn’t market research speak. I mean literally: what’s the janky workaround they’re using? What’s the Excel sheet they’re embarrassed about? What’s the process they’ve explained to three different people this week because it’s so convoluted?
Question three: What would make them drop their current solution? Not what would be nice to have. What would be so much better that they’d go through the hassle of switching, learning something new, changing their habits? This question is where most of my project ideas go to die, and that’s exactly the point.
The Weird Thing About Recording Failure
Writing down failures feels wrong when you’re in the middle of them. Your brain wants to solve, not record. But my process notebook for the dashboard project became more valuable than any successful project journal I’ve kept. It’s a field guide to my own blind spots.
I’ve noticed three patterns in my failed projects. First, I start solution-first instead of problem-first. Second, I mistake my own enthusiasm for market validation. Third, I get precious about features instead of ruthless about core value. These patterns only became visible because I wrote them down while they were happening.
The dashboard project taught me that writing things down isn’t just for successful processes. It’s especially important for the messy, uncertain parts. The moments when you’re not sure if you’re solving the right problem. The conversations that leave you more confused than when you started. The prototype that works perfectly but feels wrong somehow.
What Lives in My Current Notebook
Right now I’m working on a completely different kind of project. A tool for tracking reading progress that connects to your note-taking system. My current notebook looks nothing like the dashboard one. Instead of feature lists, it’s full of conversations. “Mike mentioned he loses track of which books he’s read when he’s trying to remember where he learned something.” “Lisa said she wants to connect her highlights to her writing but the export process is annoying.”
Every entry starts with a person, not a feature. When I write “add tag filtering,” it’s followed by “because James said he wants to find all his books about productivity quickly.” The notebook forces me to trace every decision back to a human problem.
I’m also writing down the failures as they happen. Last week I built a prototype that let you connect your Kindle highlights to your notes automatically. Sounded perfect. But when I tested it, the import process was confusing and the highlights felt disconnected from my actual thinking. I wrote that down immediately, while the frustration was fresh. Future me will thank present me for not romanticizing the dead ends.
This project might fail too. The difference is I’ll know why, and I’ll have a record of the thinking that led me there. Failure isn’t the opposite of learning. It’s one of the best ways to learn, as long as you’re paying attention to what’s actually happening instead of what you wish was happening.