The Thing I Noticed About My Writing Folder

I was cleaning out my computer files last week when I stumbled across a folder labeled “Blog Post – Decision Making” from eight months ago. Inside were seventeen different versions of the same introductory paragraph. Seventeen. Each one slightly different, each one representing a moment where I thought I’d finally cracked the code, only to return the next day and start fresh.

The published version, the one that eventually made it onto my blog, was actually version fourteen. Not the last attempt, not the most polished, but the one that finally felt right. Looking at those files made me realize something I’d never put into words before: the magic isn’t in getting it right the first time. The magic is in being willing to get it wrong sixteen times.

What Those Failed Drafts Actually Taught Me

Version three was too academic. Version seven tried too hard to be funny. Version eleven was so stripped down it lost all personality. But here’s what caught me off guard: each terrible draft taught me something specific about what I was actually trying to say. The overly academic one showed me I was hiding behind jargon because I wasn’t confident in my point. The try-hard funny one revealed I was more nervous about boring people than I was committed to helping them.

My friend Sarah, who’s a ceramicist, once told me about her “learning pots.” These are the bowls and mugs that come out lopsided, too thick, or with glazes that run in ugly ways. She keeps them on a shelf in her studio, not as decoration, but as reference points. “Every wonky bowl teaches me something my successful ones can’t,” she said. “The failures show me exactly where my hands weren’t steady or where I rushed the process.”

Those seventeen paragraph attempts were my learning pots. Each one was a small experiment in tone, structure, and clarity. The academic version taught me to trust my own voice. The overly casual one showed me where I needed more precision. The versions that felt forced revealed the difference between trying to impress and trying to connect.

Why the Messy Middle Matters More Than the Pretty Beginning

We love stories about overnight successes and first-draft masterpieces, but they’re mostly fiction. What we don’t see is the writer who threw away forty pages before finding their opening line, or the designer who created sixty-three different logo concepts before landing on the perfect one. We see the highlight reel, not the contact sheet with all the blurry shots and awkward poses.

I started keeping track of my iterations after that folder discovery. For my last client project, I created four completely different homepage concepts before presenting anything. The first one was safe and boring. The second was creative but confusing. The third was clear but generic. The fourth one combined the clarity of the third with the personality of the second while avoiding the blandness of the first, and became the foundation for something actually good.

The messy middle is where the real work happens. It’s where you discover what you’re actually trying to build, say, or solve. That discovery only comes through making something, looking at it honestly, then making it again. You can’t think your way to the right answer. You have to work your way there.

The Practice of Getting It Wrong on Purpose

Now I deliberately plan for bad first drafts. When I start a new piece of writing, I set a timer for fifteen minutes and write the worst possible version I can imagine. Not just mediocre, actively terrible. Purple prose, clichés, the works. It’s liberating to give myself permission to be awful, and it usually shakes loose something unexpected.

My developer friend Marcus does something similar with code. He calls it “coding like a caveman,” writing the most straightforward, inelegant solution possible just to get something working. “Once I can see the problem solved badly,” he told me, “I can usually see how to solve it well.” The ugly version becomes a scaffold that supports the construction of something better.

This isn’t about lowering standards. It’s about recognizing that quality emerges from quantity of attempts, not from the pressure to nail it immediately. When you remove the pressure to be perfect on the first try, you create space for genuine experimentation. And experimentation is where breakthroughs happen.

What Good Iteration Actually Looks Like

Good iteration isn’t random. It’s systematic. When I went back through those seventeen paragraph versions, I could see patterns in what I was testing: different opening hooks, various levels of formality, multiple ways to frame the central idea. Each version was an experiment with a specific variable.

The chef at my neighborhood restaurant told me he spent three months perfecting his ramen broth, making tiny adjustments to cooking time, ingredient ratios, and seasoning balance. “I wasn’t changing everything at once,” he explained. “I’d adjust the cooking time by thirty minutes, or increase the miso by half a teaspoon, then taste and evaluate. Change too many things at once and you don’t know what’s working.”

This is the discipline of iteration: making purposeful changes, evaluating results, and building on what works while discarding what doesn’t. It requires patience and a willingness to sit with imperfection long enough to understand what it’s teaching you. Most importantly, it requires seeing each attempt not as a potential failure, but as data that brings you closer to what you’re really trying to create.

The Conversation Your Work Has With Itself

Those seventeen versions weren’t just drafts, they were a conversation. Version five responded to the problems in version four. Version twelve built on the insights from version nine while avoiding the pitfalls of version ten. Each iteration was both a critique of what came before and a hypothesis about what might work better.

This is why keeping your drafts matters, even the terrible ones. They create a trail of decisions and discoveries that you can follow backward when you get stuck. They remind you of problems you’ve already solved and approaches you’ve already tested. They become a record of your thinking, not just your output.

What patterns do you notice in your own iterations? What does your work teach you about itself when you give it room to evolve through multiple attempts? The answers might surprise you.

The Illustration That Never Happened

Last January, I pitched an illustrated guide to urban foraging that would have been gorgeous. I had the botanical accuracy mapped out, the visual hierarchy sketched, even a distribution plan through local nature centers. The client loved it. I spent three weeks developing concepts that felt genuinely innovative. Then I discovered someone had published almost the exact same guide six months earlier.

This wasn’t about plagiarism or parallel thinking. This was about the uncomfortable truth that sits at the heart of creative work: most of what we think is “creative” is actually skilled labor applied to well-established patterns. The real creativity happens in the tiny spaces between the predictable parts.

The Architecture of Making Things

After fifteen years of freelance design work, I can break down any project into roughly the same components. There’s the initial excitement phase where everything feels possible. Then comes the research grind, which always takes longer than expected. The first draft inevitably disappoints. The revision cycle feels endless until suddenly it doesn’t. Finally, there’s the delivery and the weird emptiness that follows.

What changes isn’t the structure, it’s how I navigate each phase. When I started, I fought the predictable parts. I wanted every project to reinvent the wheel. Now I lean into the framework. The creative magic happens within constraints, not despite them. Last month, I designed a conference poster using a grid system I’ve used dozens of times before. The innovation was in how I pushed against specific grid intersections to create unexpected visual tension.

The craft isn’t in avoiding the formula. It’s in executing the formula so well that something surprising emerges from familiar elements. This year taught me that creativity is more like jazz improvisation than abstract expressionism. You need to know the standards cold before you can meaningfully deviate from them.

The Myth of the Breakthrough Moment

Instagram would have you believe that creative work happens in lightning strikes of inspiration. The reality looks more like my August project: a rebrand for a local bakery that required forty-seven logo iterations. Not because the client was difficult, but because good work emerges from systematic exploration of bad ideas.

Logo thirty-one was when something clicked. It wasn’t a breakthrough, it was the result of methodically working through every obvious solution until I found something that felt inevitable in hindsight. The “aha” moment was really an “of course” moment. The breakthrough was the cumulative effect of showing up every day and pushing through the versions that didn’t work.

I’ve stopped waiting for inspiration. Instead, I’ve built systems that create conditions where good work can happen. Tuesday mornings are for rough concept development. Thursday afternoons are for refinement. I work in my kitchen because the terrible lighting forces me to rely on structure over surface appeal. These aren’t creative decisions, they’re operational decisions that enable creativity.

What Actually Gets Made

The gap between the project in your head and the project that gets delivered is where creative work actually lives. That urban foraging guide I couldn’t make? I ended up creating a series of plant identification cards for a local elementary school instead. Same botanical knowledge, completely different format, audience, and purpose.

This year, I tracked every project pivot, scope change, and last-minute revision. The pattern was clear: the final deliverable bore little resemblance to the initial brief in roughly eighty percent of cases. This isn’t failure, it’s the natural evolution of ideas meeting reality. The skill isn’t in sticking to the original vision. It’s in recognizing when the work is telling you to go in a different direction.

My best projects this year happened when I stopped trying to control the process and started listening to what wanted to emerge. The conference poster I mentioned earlier started as a brochure design. A brand identity project became a complete digital strategy overhaul. A simple website redesign turned into a fundamental business model shift for the client. The creative work was in staying flexible enough to follow where the project actually needed to go.

The Unglamorous Middle

Nobody talks about the three-week stretch in October when I couldn’t figure out the typography hierarchy for a client presentation. Not because it was technically challenging, but because I was overthinking every decision. I spent days adjusting kerning by single units. I reorganized my font library twice. I researched the historical context of serif vs. sans-serif choices for financial services companies.

This wasn’t perfectionism, it was creative paralysis disguised as thoroughness. The solution came when I admitted I was stuck and asked a colleague to look at it with fresh eyes. She pointed out that I was trying to solve a strategic problem with aesthetic adjustments. The typography wasn’t the issue. The information hierarchy was unclear from the start.

Creative work includes these periods of spinning your wheels. The skill is learning to recognize when you’re stuck versus when you’re working through something complex. Sometimes the most creative decision is to stop, step back, and ask whether you’re solving the right problem. That October project taught me that creative block often signals a mismatch between the solution you’re pursuing and the problem that actually needs solving.

What This Year Actually Taught Me

I started this year thinking that creative maturity meant having fewer failed experiments. I’m ending it with a folder labeled “Interesting Failures” that’s larger than my portfolio folder. The difference is that I now see failed experiments as data rather than disappointment. Each one narrows the range of what might work next time.

Creative work isn’t about constant innovation. It’s about building enough skill and taste to recognize the difference between something that’s genuinely fresh and something that’s merely different. It’s about developing enough confidence in your process to let projects evolve beyond your initial expectations. Most importantly, it’s about accepting that the work itself will teach you what it wants to become, but only if you show up consistently enough to hear it.

What patterns are you noticing in your own creative work this year? What projects taught you something you weren’t expecting to learn?

The Spreadsheet That Made Me Question Everything

I opened my Q3 review document last week and stared at a peculiar pattern. Three out of five goals were marked “completed,” but I felt more frustrated than accomplished. The problem wasn’t that I’d failed—it was that I’d succeeded at the wrong things.

Take my goal to “publish 12 blog posts this quarter.” I hit 14 posts, technically crushing it. But when I looked closer, half of those posts were shallow, rushed pieces that added nothing meaningful to my thinking or my readers’ lives. I’d optimized for a number instead of impact, and the spreadsheet couldn’t capture that distinction.

This disconnect between achievement and satisfaction sent me down a rabbit hole of rethinking how I approach quarterly planning. What I discovered changed not just my goal-setting process, but my entire relationship with measuring progress.

The Two-Layer System I’m Testing Now

After that wake-up call, I started experimenting with what I’m calling “outcome goals” and “process experiments.” Outcome goals are the traditional measurable targets. Launch the course, hit revenue milestones, complete the manuscript. Process experiments are the behavioral changes I want to test. Write for 30 minutes before checking email, have one deep conversation with a reader each week, or prototype ideas before committing to them fully.

The magic happens when these layers interact. For Q4, my outcome goal is to redesign my newsletter format. The process experiment is to interview three readers before making any design decisions and to ship a rough prototype within two weeks instead of perfecting it for months. The outcome gives me direction. The experiment forces me to work differently.

What I love about this approach is that even if the outcome goal shifts, maybe the newsletter redesign reveals I should focus on my podcast instead, the process experiment still teaches me something valuable about how I work. I’m building better habits while pursuing concrete targets.

The Weekly Check-In That Actually Changed My Behavior

Monthly reviews used to feel like awkward performance evaluations with myself. Too much time had passed to remember the real reasons behind my decisions. Weekly check-ins solved this, but only after I figured out the right questions to ask.

Every Friday afternoon, I spend 15 minutes with three prompts: What worked this week that I want to repeat? What felt hard in a way that suggests I’m learning something new? What felt hard in a way that suggests I’m fighting against reality? The first question captures wins, the second identifies growth edges, and the third catches me when I’m being stubborn about the wrong things.

Two weeks ago, this process helped me realize I was spending enormous energy trying to make video content work because I thought I “should” be on YouTube. The resistance wasn’t teaching me anything, it was just draining me. I dropped video experiments and doubled down on writing, which immediately felt like swimming downstream instead of up.

When Goals Collide With Life

Here’s what most goal-setting advice misses: life doesn’t pause for your quarterly planning. In August, my dad had a health scare that required three weeks of hospital visits and family coordination. My neat Q3 timeline exploded, and I had to choose what really mattered.

The outcome goals mostly got delayed or scaled back. But the process experiments proved their worth. My habit of writing before email meant I captured thoughts during stressful mornings in hospital waiting rooms. Those fragments became some of my most honest writing later. The practice of interviewing readers gave me permission to reach out for support when I needed it most.

This taught me that resilient goal-setting isn’t about creating bulletproof plans, it’s about building systems that adapt when plans inevitably break. The outcome goals provide direction, but the process experiments create the foundation that holds when everything else shifts.

My Messy Q4 Experiment

I’m sharing my actual Q4 goals not because they’re perfect, but because seeing someone else’s real planning might spark ideas for your own. Outcome goal: Launch a small cohort course on creative project management by December 15th. Process experiments: Interview five potential students before building anything, ship a rough outline within two weeks for feedback, and limit course creation to 10 hours per week maximum.

I’m already nervous about the timeline, and I suspect the course content will look nothing like what I imagine right now. But that’s exactly why I’m documenting this process. I want to capture what actually happens when plans meet reality, not just the polished success story afterward.

What I’m most curious about is whether limiting myself to 10 hours per week will force better decisions or just create artificial pressure. Will interviewing students first prevent me from building something nobody wants, or will it introduce so many perspectives that I get paralyzed by options? I genuinely don’t know, and that uncertainty is exactly what makes this worth trying.

The real question isn’t whether these goals will work perfectly, it’s what they’ll teach me about building things people actually want while maintaining the creative energy for the long game. What experiments are you running with your own planning? What’s working, what’s failing, and what are you learning along the way?

The Book That Made Me Stop Pretending I Knew Things

I was sitting in a meeting last year, nodding along as someone explained a complex process I absolutely did not understand. Sound familiar? That moment of panic when you realize you’ve been skating by on surface-level knowledge for way too long. Then I read “Thinking, Fast and Slow” by Daniel Kahneman, and everything clicked into place about why I kept doing this to myself.

Kahneman breaks down how our brains have two systems: the fast, automatic one that jumps to conclusions, and the slow, deliberate one that actually thinks things through. Reading this was like getting the user manual for my own brain. I finally understood why I’d confidently estimate a project would take two weeks when it obviously needed six. Why I’d assume I understood a concept after reading one article about it. The book is dense and sometimes feels like homework, but it completely changed how I approach learning anything new.

If you’re someone who catches yourself nodding along in conversations while internally screaming “I have no idea what they’re talking about,” this book will help. It won’t make you smarter, but it will make you honest about what you actually know versus what you think you know. That’s worth the 400-page investment.

The Business Book That Isn’t Really About Business

“The Hard Thing About Hard Things” by Ben Horowitz sounds like another Silicon Valley ego trip, and honestly, parts of it are. But buried in the war stories about managing companies is the most practical advice I’ve ever read about making decisions under pressure. Horowitz doesn’t give you a framework or methodology. Instead, he shows you what it looks like to make impossible choices with incomplete information.

The chapter about firing executives hit me hard because I was dealing with a similar situation on a much smaller scale. A freelancer I’d been working with for months wasn’t delivering, but they were also going through personal struggles. Horowitz’s approach helped me understand that being kind doesn’t mean avoiding difficult conversations. Sometimes the kindest thing is clarity, even when it’s uncomfortable.

This book works for anyone who has to make decisions that affect other people, whether you’re running a company or just trying to figure out how to give feedback to a teammate. Horowitz strips away the motivational nonsense and shows you what leadership actually looks like when things go wrong. Spoiler alert: it’s messy and you’ll probably mess up anyway.

The Creativity Manual I Wish I’d Had Ten Years Ago

“Big Magic” by Elizabeth Gilbert gets dismissed as fluffy self-help, which is unfortunate because it’s actually a practical guide to working with ideas. Gilbert’s premise is that ideas are living things that visit us, and our job is to show up consistently so we’re ready when they arrive. This sounds mystical until you realize it’s just a different way of talking about disciplined creative practice.

The section about fear fundamentally changed how I approach creative projects. Gilbert argues that fear will always be there, so instead of trying to eliminate it, you acknowledge it and bring it along for the ride. I started a podcast last year that I’d been putting off for months because I was terrified it would be terrible. Gilbert’s approach helped me reframe the fear as evidence that the project mattered to me, not as a reason to avoid it.

If you’re someone who has creative projects that never seem to get finished because they’re never “quite ready,” Gilbert will help you understand that readiness is a myth. The work is what makes you ready, not the other way around. She gives you permission to create imperfect things, which turns out to be the only way to create anything at all.

The Psychology Book That Explains Everyone You Know

“Mindset” by Carol Dweck should be required reading for anyone who has ever felt stuck. Dweck’s research on fixed versus growth mindsets explains why some people bounce back from failure while others get derailed by it. The fixed mindset believes abilities are static. The growth mindset believes abilities can be developed. Simple concept, profound implications.

I used to avoid challenges that might make me look stupid, which meant I stayed in my comfort zone way longer than was healthy. After reading Dweck, I started reframing failures as data instead of verdicts. That podcast I mentioned? The first ten episodes were objectively bad. Old me would have quit. Growth mindset me saw them as practice rounds and kept going.

What makes this book valuable is how Dweck shows you the mindset patterns in action across different contexts. The examples from education, sports, and business help you recognize your own fixed mindset triggers. If you’re someone who gets paralyzed by the possibility of failure or who takes criticism as a personal attack, this book will give you a different way to interpret those experiences.

The Strategy Guide That’s Actually About Life

“Good Strategy Bad Strategy” by Richard Rumelt is technically a business book, but it’s really about clear thinking. Rumelt defines good strategy as facing your challenges honestly and coordinating actions to address them. Bad strategy is everything else: wishful thinking, buzzwords, and goals without plans. The distinction seems obvious until you realize how much bad strategy surrounds us.

Reading this book made me realize I’d been treating my career like bad strategy. I had vague goals about “building an audience” and “improving my skills” without any coherent plan for how those things connected. Rumelt’s framework forced me to get specific about what I was actually trying to achieve and why certain activities would move me toward that goal.

This book is for anyone who feels busy but not productive, who has lots of goals but no clear sense of how they fit together. Rumelt will make you uncomfortable because he’ll force you to admit when you’re just hoping things work out instead of actively making them work out. But that discomfort leads to clarity, and clarity leads to better decisions.

These five books didn’t just give me new information. They changed how I process information, how I approach problems, and how I think about thinking itself. Which books have done that for you? I’m always looking for recommendations from people who’ve actually applied what they’ve read, not just collected insights they’ll never use.

The Great System Collapse of March 2023

I spent six months building what I thought was the perfect productivity system. Color-coded calendars synced across three devices. A task management setup that would make David Allen weep with joy. Automated workflows that felt like magic when they worked. Then one Tuesday in March, I found myself sitting in a coffee shop, paralyzed by my own creation. I had seventeen different ways to track a simple phone call, and I couldn’t figure out which one to use.

That’s when I realized I’d fallen into the classic trap: building a productivity system so complex that managing the system became more work than the actual work. Sound familiar? I’m guessing it does, because I’ve talked to dozens of people who’ve been there. The irony is brutal. We create these elaborate frameworks to make our lives easier, then spend more time maintaining them than we ever spent being disorganized.

Starting Over: The One-Notebook Rebellion

After my digital productivity meltdown, I did something that felt almost rebellious: I bought a single, plain notebook. Not a fancy system, not a specialized planner. Just a regular composition book from the drugstore. For two weeks, everything went in there. Meeting notes, random thoughts, grocery lists, project ideas, phone numbers I needed to remember. It was messy and imperfect, and it worked better than anything I’d used in months.

This wasn’t about going analog forever. It was about rediscovering what productivity actually felt like without the overhead of system management. I started noticing patterns in how I naturally wanted to capture information. When I wrote things down by hand, I automatically grouped related ideas together. I drew arrows between connected thoughts. I used different handwriting styles for different types of information without thinking about it. My brain was already organizing information in ways my digital systems had been fighting against.

The notebook phase taught me something important: your productivity system should work with your natural thinking patterns, not replace them with someone else’s idea of optimal organization. Every guru and methodology assumes certain things about how your brain works. But what if your brain works differently?

The Minimum Viable System

After a month with just the notebook, I started adding back digital tools one at a time. But this time, each tool had to pass a simple test: did it make something genuinely easier, or was I adding it because it seemed like something a productive person should use? The difference between these two motivations is enormous, and I’d been blind to it for years.

My rebuilt system ended up looking nothing like the productivity porn I’d been consuming online. Instead of a comprehensive task management app, I use a simple text file that lives on my desktop. Instead of elaborate project tracking, I have a weekly planning session where I write three priorities on a sticky note. Instead of time-blocking my entire calendar, I protect two-hour chunks for deep work and let everything else flow around them.

The sticky note thing probably sounds absurd if you’re used to sophisticated systems. But here’s what I learned: constraints force clarity. When you can only write three things on a sticky note, you get very honest about what actually matters this week. I’ve tried this with people who swear by complex project management software, and many of them are shocked by how much clearer their priorities become when forced into this tiny format.

The Design Principles I Actually Follow

Building a personal productivity system is like designing a custom tool. You wouldn’t use someone else’s hammer if your hands were a different size, but somehow we expect generic productivity methods to fit our unique work styles and life circumstances. Through multiple failed attempts, I’ve identified a few principles that actually seem to work for sustainable systems.

First principle: optimize for recovery, not peak performance. Most productivity advice assumes you’ll maintain consistent energy and focus indefinitely. But real life includes sick days, family emergencies, creative blocks, and plain old exhaustion. The systems that survive are the ones that work even when you’re running on fumes. This means building in slack, keeping things simple enough to maintain when you’re not at your best, and designing restart procedures for when you inevitably fall off track.

Second principle: make the invisible visible, but don’t make everything visible. I keep a running list of projects that are waiting for other people, because otherwise I completely forget about them until someone asks for an update. But I don’t track every email or minor task because that creates noise that drowns out what actually needs attention. The trick is identifying the specific things your brain tends to drop and building gentle reminders for just those items.

What I’m Still Figuring Out

Even after rebuilding from scratch, my system isn’t perfect. I still struggle with the boundary between work projects and personal projects. Should they live in the same place or separate ones? I’ve tried both approaches multiple times and haven’t found a clear winner. Right now they’re mixed together, which works well for seeing the full picture of my commitments but makes it harder to focus on just one area.

I’m also experimenting with seasonal adjustments. The system that works during busy project seasons doesn’t always work during quieter periods when I have more space for reflection and planning. This feels important but I haven’t cracked the code yet. Maybe the answer isn’t finding one perfect system but accepting that productivity needs change with life circumstances.

The biggest lesson from this whole messy process has been that designing a personal productivity system is an ongoing conversation with yourself about how you actually work, not how you think you should work. It requires the same kind of honest self-observation that any good design process demands. What are your actual patterns? Where do things consistently break down? What feels effortless versus what requires constant willpower to maintain?

I’m curious about your own experiments with this stuff. What have you tried that completely failed? What tiny change made a surprisingly big difference? The best productivity insights I’ve gotten have come from comparing notes with people who are willing to share their messy first drafts, not just their highlight reels.

The App That Went Nowhere

I spent three months last summer building a meal planning app that I was absolutely convinced would revolutionize how busy families organize their weekly dinners. I had wireframes, user personas, a detailed feature roadmap, and even a catchy name: FeedPlan. The app would suggest recipes based on dietary preferences, generate shopping lists, and send helpful cooking reminders. I could practically see the App Store reviews pouring in.

Exactly seven people downloaded it in the first month. Three of them were my family members, and one was me testing it on a different phone. The project died quietly in September when I couldn’t justify paying another month of hosting fees for something that had generated zero revenue and helped virtually no one. But here’s the thing about spectacular project failures: they’re often more educational than the successes that make it onto your portfolio.

Why I Actually Recommend Failing Publicly

Most people treat project failures like embarrassing family secrets, but I think that’s backwards. Failed projects are goldmines of insight, especially the ones that fail for reasons you didn’t anticipate. My meal planning app didn’t fail because of bad code or poor design. It failed because I built something that solved a problem I assumed people had, without actually talking to anyone about whether they wanted it solved.

I spent weeks perfecting the algorithm that would suggest recipes based on pantry ingredients, but I never once asked a real parent whether they actually wanted an app to tell them what to cook. Turns out, most families already have their dinner routines figured out, and the ones who don’t usually want inspiration, not automation. The failure taught me more about product development than any successful side project ever has.

If you’re someone who tends to abandon projects when they don’t immediately work out, I want to recommend embracing the full lifecycle of failure instead. Document what went wrong. Share the lessons publicly. Build a track record of learning from mistakes rather than hiding them. The people worth working with will respect your willingness to examine your own failures honestly.

The Anatomy of a Productive Failure

Not all failures are created equal. Some failures happen because you got lazy or gave up too early. Those are frustrating but not particularly instructive. The failures worth studying are the ones where you did everything you thought you were supposed to do, and it still didn’t work. Those failures reveal the gaps between your assumptions and reality.

With FeedPlan, I followed all the startup advice I’d absorbed from podcasts and blog posts. I validated the problem by reading Reddit threads about dinner planning struggles. I built a minimum viable product instead of trying to launch with every possible feature. I even did some basic market research by browsing competing apps. But I skipped the most important step: actually talking to potential users before building anything.

The productive failure framework I’ve developed since then has three questions: What did I assume was true that turned out to be false? What did I optimize for that didn’t actually matter? And what warning signs did I ignore along the way? For FeedPlan, the answers were brutally clear. I assumed people wanted algorithmic meal suggestions when they really wanted inspiration. I optimized for feature completeness when I should have optimized for user research. And I ignored the warning sign that none of my friends seemed excited when I described the app to them.

How to Extract Maximum Learning from Dead Projects

The week after I shut down FeedPlan’s servers, I did something I’d never done before: I wrote a detailed failure autopsy. Not for public consumption, just for myself. I documented every decision that led to the project’s demise, starting with the initial inspiration and ending with the final user analytics. The process was uncomfortable but incredibly clarifying.

I realized that my project selection process was fundamentally flawed. I was choosing projects based on what seemed technically interesting to build, not what would be genuinely useful to real people. I was also terrible at killing projects early when they showed warning signs. I had data showing low user engagement after week two, but I kept optimizing the wrong things instead of stepping back to question whether anyone actually wanted what I was building.

Now I keep a failure journal where I document not just what went wrong, but what I learned about my own blind spots and working patterns. Some of my most valuable insights have come from projects that never saw the light of day. Like the productivity system I built for myself that was so complicated I stopped using it after a week, which taught me that complexity is often the enemy of adoption, even when you’re your own user.

The Best Failures to Learn From

If you’re looking to fail productively, I recommend choosing projects that force you to work outside your comfort zone. Safe failures, where you’re just applying skills you already have to familiar problems, won’t teach you much. The failures that change how you think are the ones that challenge your assumptions about how things work.

For technical people, this might mean attempting projects that require you to understand user psychology or marketing. For creative types, it might mean projects that force you to grapple with data and analytics. The goal isn’t to become an expert in everything, but to develop enough perspective to recognize your own knowledge gaps before they sink a project.

I also recommend setting failure timelines from the beginning. Give yourself permission to kill a project after a specific timeframe or milestone if it’s not showing signs of life. Three months was actually perfect for FeedPlan because it was long enough to build something real and test it with users, but short enough that I didn’t waste a year on something that wasn’t working.

Which failed projects are sitting in your abandoned folder right now? What would happen if you spent an hour writing down everything they taught you about your own assumptions and working patterns? Sometimes the projects we’re most embarrassed about are the ones with the most to teach us.