
# The Big Idea

Being wrong is unavoidable. The real damage comes from allowing a bad assumption to shape everything you build on top of it.

## The flattering version

A few years ago, we sold smpl, the coworking software company I had built with two close friends.

An acquisition gives you a tidy ending. It becomes easy to look back at the decisions you made and imagine that they must have been good ones because, eventually, things worked out.

I know better.

When I think about smpl now, I see plenty of moments when I was wrong and dug my heels in for far too long. My teammates sometimes saw things more clearly than I did. Our customers gave us signals that I dismissed or explained away. I became attached to my own ideas, and that attachment cost us time, strained important relationships, and made our product worse.

smpl was acquired despite some of my decisions, not because of all of them.

## Cognitive debt

Technical debt accumulates when you take shortcuts today and leave the consequences for someone (read: you) to handle later. I have started to think there is a similar kind of debt that accumulates in our understanding.

Cognitive debt begins with an assumption. That assumption influences a decision, which shapes the next decision, until we have built an entire strategy on top of something that may never have been true.

The work can still look productive. Features ship, customers sign up, and the company moves forward. A good outcome may even hide the debt completely. But every untested assumption makes changing direction harder, especially once our reputation or identity becomes attached to it.

This problem feels particularly relevant in the age of AI, when chat can produce work faster than we can understand or validate it. AI _accelerates_ the problem, but it did not create it. People have always been capable of confusing confidence with understanding.

## A better way to be wrong

The scientific method offers a useful alternative: form a hypothesis, test it, observe what happens, and change your understanding when reality disagrees.

The difficult part is remembering that a hypothesis is temporary. It should never become part of your personality.

For founders and leaders, this also means creating an environment where people can challenge ideas without paying an emotional price for it. A thoughtful disagreement is valuable evidence. If someone has to fight through your ego every time they offer it, they will eventually stop trying.

I cannot know how smpl would have turned out if I had listened sooner or changed my mind more readily. Maybe the acquisition would have been larger. Maybe the journey would simply have been healthier for the three of us and better for our customers.

Either possibility would have been worth it.

## Cultivating the skill of being wrong

It is a very human tendency to not want to own up to being wrong. It can feel like an admission of failure, or weakness. But the truth is that being wrong is a necessary part of building anything new. The real failure is in refusing to acknowledge it, or worse, leaning into being wrong and refusing to change course.

One of the most useful things a leader can say is: **I was wrong about this. Here is what changed my mind, and here is what I think we should do differently.**

_This_ is leadership - if you can admit you were wrong, your squad will trust you more when you're right. They'll also be more willing to challenge you when they think you're wrong. They should also be more inclined to follow your example - even if it takes a while.

Being wrong is part of building anything new. The tiny improvement is learning to stop compounding it.


Cognitive Debt and the Cost of Staying Wrong


## The Big Idea

Becoming a great product builder means falling in love with the process of building and rebuilding.

---

I have always felt like I'm somewhere between the before photo and the after photo.

As in -- I've never felt like I'm "finished" with anything, really. The next version is just around the corner. It's just mid-process.

For a long time, I assumed that feeling meant I was behind. That at some point I would arrive at a stable, finished version of myself, or my work, and finally feel settled. But the longer I build things for a living, the more I realize that the in-between feeling is a sign that I'm on the right track.

## The Engineer's Reality

If you write software, you live in the messy middle whether you like it or not. You ship something that works well enough. Then you watch how it behaves in the wild. You discover the edge case you didn't anticipate, or the assumption that quietly shaped the entire architecture, or the part of the interface that makes perfect sense to you and none at all to anyone else.

And then you rebuild.

Here's the secret: for great products, that rebuild keeps happening, all the time, at every scale. You rewrite a sentence in a `README` because it doesn't quite communicate what you meant. You refactor a function that felt clever last week and now just feels brittle. You restructure a module. You revisit a feature that solved the wrong problem. Sometimes you rethink the product entirely. If you are unlucky or ambitious enough, you end up rethinking the company.

The rebuild is fractal. It repeats at every level. The same humility is required whether you are fixing a single line or reimagining the direction of the business.

## Failing to learn from the past is a recipe for disaster

Teams that forget this are usually the ones that get surprised. Usually this is because it's taboo to question past decisions, despite the richness of learnings you get from seeing people use a product or feature after launch. Instead, boxes are checked and the product is deemed “good enough,” and instead of learning from the product's shortcomings and revisiting first principles, the team shifts into protection mode. Architecture calcifies. The roadmap becomes incremental.

Rebuilding starts to feel risky instead of necessary.

And that is exactly when the ground shifts beneath you. The cost of building something new keeps dropping. LLMs have dramatically reduced the time between idea and implementation. Patterns that once required deep specialization can now be scaffolded quickly. A small team with good taste and the willingness to rethink fundamentals can move faster than an entrenched organization that is busy defending yesterday's decisions.

Ever open up a beloved product and have the sinking feeling that it hasn't changed in years? In the past, that meant stable product-market fit. For utilitarian tools today, it might be a warning sign that someone is about to build something better.

## Looking at your past work

We _all_ cringe when we look back at what we produced years ago. _I can't believe I wrote that!_ is a sign that you've grown. If you look at a project from two years ago and wouldn't change a thing, that is when you should worry.

The cringe is useful. It is a divining rod. It points directly at the thing that is ready to be rebuilt. Your past work is a treasure trove of opportunities for self-disruption. Take your work, make it better, and help your teammates do the same.

## If you don't rebuild, someone else will

If you aren't willing to revisit your foundations, someone else will. Not because they are smarter, but often because they are less attached to the work, or to the "we've always done it this way" mentality that quietly takes hold in teams of all sizes.

Learning to love the rebuild isn't perfectionism, it's humility and honesty. Look at your own work and admit that the current version is not sacred, and you'll be able to build better things.

So look at the thing you shipped last quarter. Find the part that makes you wince. That is where you start.

---

## More Reading

- 📖 [The Messy Middle](https://hardcover.app/books/the-messy-middle) by Scott Belsky is a great reference point for falling in love with the sisyphean product building process.
- 🎥 [Ira Glass on Good Taste](https://www.youtube.com/watch?v=E7rCOlqGVQU) - Glass has a famous quote about how _everyone_ has bad taste at first, especially when doing creative work. The nut at the core of the message is that you will do best if you _just start making stuff now_. Product building is creative work - don't sell yourself short by thinking otherwise.
- 💎 [Today is Your Day to Start](https://mikebifulco.com/newsletter/today-is-your-day-to-start) - My treatise on a similar theme. The only better time to start than now was 10 years ago.


Learn to Love the Rebuild

Failing to learn from the past is a recipe for disaster


## The Big Idea

The way you get your work done has a direct impact on how well it gets done, especially when working with teams on problems of increasing complexity. Time spent planning multiplies your productivity.

<a
  href="https://tiny.outlier.ai/yckz3zcs"
  className="text-xs lg:text-xs xl:text-xs"
>
  Brought to you by Outlier AI
</a>

The title of this post is inspired by a Frank Lloyd Wright quote that became a mantra for my team while I was working at Gymnasium:

> An architect's most useful tools are an eraser at the drafting board and a wrecking ball at the jobsite.

Planning is **everything**.

## The virtuous product cycle

Building products for real people is a really hard. Even if you've found an audience and a product idea that you're confident in, doing a _great job of building the thing_ is always going to be challenging. I had the great fortune of working at Microsoft in my first job after university, where I was able to work on some pretty incredible teams of experienced engineers.

One of the most important things I learned in that job was a framework for building products in small, iterative cycles, which I've been using ever since. It breaks down each project, milestone, and feature into a few simple phases:

<Image
  publicId="newsletters/eraser-or-wrecking-ball/product-cycle"
  alt="The virtuous product cycle"
  caption="The virtuous product cycle"
/>

### Envision - understand the problem

In the **envision** phase, you're trying to understand the problem. This is where you capture the hopes and dreams of the people who will be using your product. This is where you get your baseline requirements from, in the form of user stories, feature lists, diagrams for workflows, and other documentation.

### Plan - break it down

In the **planning** phase, your job is to break down a complex problem into smaller parts. Ideally, this is a list of small tasks that can be completed relatively quickly. I usually shoot for no longer than 1 day. It's helpful here to think about inter-dependencies between tasks, and to capture things that aren't _strictly_ code: documentation, updated test cases, API endpoints that may change, UX work that needs to be done, and so on. You'll want to capture dev tasks, too - list out everything that needs to be done to get the feature working, even if it feels pedantic.

This is a critical bit of work, especially if you're working with non-technical people: this list of tasks is your best reference point when someone asks "what's left to do?" or "why isn't this done yet?". Combined with the details you captured during the **envisioning** phase, you should have a clear picture of what you're going to build, as well as the decisions made to get there.

Most importantly - at this point, **anyone** on your team should be able to read through this list and understand the work ahead, and even pick it up and run with it if needed. It means you won't have to answer questions in JIRA while you're sitting on your next vacation.

Planning is the step that we all tend to resist; it's easy to do. Fueled by excitement of something new, this step is the most likely to be overlooked. I've absolutely done it, and more often than not it

Skipping this step is a surefire way to miss important details; it's common during planning to unearth requirements that were missed in the envisioning phase - and it's a lot easier to fix them at this stage.

### Build - get it done

This is the one we're all chomping at the bit to do: coding away furiously to make the feature come to life, and to build out all of the exciting bits that comprise it.

### Stabilize - the one where you fix the bugs

This is the pre-deployment step where you write tests, conduct QA and acceptance testing, and make sure everything is working as expected. It's a good time to check in with the team to make sure everyone is on the same page, and to make sure you're not missing anything (even if it wasn't documented before!).

This is also a good moment to prepare documentation, demo videos, and other materials that will help your launch be a success.

### Deploy

🚀 Launch it!

### Analyze

Get your feature into the hands of your users, share documentation and demos with the world, and start gathering feedback. This is a great time to use product analytics and the telemetry you have available to learn whatever you can from the way people are using your feature, and to plan the next version.

Then go back to the start: the whole cycle starts again.

It takes practice and discipline to get this right, but it's worth it.

---

## Front-end Devs: Get Paid to Critique AI-Generated Code

Outlier (by Scale AI) is hiring frontend devs to help train cutting-edge AI—no AI experience needed. Work remotely, set your own hours, and earn up to $50/hr reviewing code and UI, with weekly payouts.

Help shape the future of dev tools - [apply now](https://tiny.outlier.ai/yckz3zcs)

<a
  href="https://tiny.outlier.ai/yckz3zcs"
  target="_blank"
  rel="noopener noreferrer sponsored"
>
  <Image
    publicId="sponsors/scale-ai/contribute-sq"
    alt="Outlier by Scale AI"
    className="max-w-sm"
  />
</a>

---

## Great ideas from people smarter than me

Earlier this week, I came across [Debug with Notes](https://coolsoftware.dev/blog/debug-with-notes/), by [Tyler Williams](https://bsky.app/profile/coolsoftware.dev/post/3lqljgta5cs2j) on BlueSky. His process involves taking detailed notes while working through a bug; it's a super helpful pattern for tackling situations where you're unfamiliar with the codebase, and to give yourself a point of reference if you get pulled away from a problem before fixing it.

LeadDev has a great article on [a tech lead's guide to effective communication](https://leaddev.com/communication/tech-leads-guide-effective-communication) that I keep bookmarked. It's a great reminder that communication is a skill which can be improved with practice.

## Farewell, Gymnasium

This is normally where I'd shout out the free courses offered by the gang I used to work with at Gymnasium, but I'm sad to say that Gymnasium was shuttered at the end of May.

**If you're hiring for UX leadership, marketing or technical learning**, my former colleagues from Gymnasium are world-class. [Drop me a line](mailto:hello@mikebifulco.com), I'd love to set up an introduction.


Eraser or the Wrecking Ball? Planning is everything

Stabilize - the one where you fix the bugs

Front-end Devs: Get Paid to Critique AI-Generated Code

#leadership: 3 posts tagged

Cognitive Debt and the Cost of Staying Wrong

Learn to Love the Rebuild

Eraser or the Wrecking Ball? Planning is everything