
## The Big Idea

At some point, a successful prototype changes jobs. It stops being a fast way to prove an idea, and starts becoming the thing your business depends on.

## What happens when your prototype becomes a product?

There is endless writing on the internet about building v0. Ship the MVP. Get something into people's hands. Find your first customers. Move fast enough to learn something before you run out of time, money, or emotional fortitude.

I love that part of the work. I will probably spend the rest of my life building little v0s, because there are few feelings better than turning an idea into something real enough for someone else to touch.

But there is a quiet threshold you cross if the product starts to work.

One day, the scrappy prototype is no longer just a prototype. It is how people do their jobs. It is how your team answers questions. It is how customers get what they paid for. It is where the rules of the business live, even the rules no one remembers writing down.

That is the moment you stop being only a builder. You become an operator.

This is the first post in a series about that shift: what changes when your relationship with a tool, product, service, or SDK moves from “hello world” to “what do I need to know to keep the lights on?”

## v0 Did Its Job

Our first internal product at [Craftwork](https://www.craftwork.com) was built with Ruby on Rails, in a far off time before Claude Code existed.

Rails was good enough to get started with, and for a little while, it made velocity feel great. We could see a problem in the morning, scaffold something to address it in the afternoon, and have someone using it soon after. That kind of speed matters early on, because the job of v0 is not to build the perfect system. The job of v0 is to learn which system deserves to exist.

But I do think Rails was fundamentally the wrong choice for what we needed to become.

The scaffolding that helped us move quickly started making the product harder to shape. We found ourselves anchored in snap-decisions that were difficult to unwind. Performance became painful in the places where speed mattered most.

Hiring for Rails was harder than we wanted it to be.

And, maybe most frustratingly, it made it harder for us to take advantage of some of the best libraries on the web for building modern interfaces, especially tools like shadcnui that fit much more naturally into a TypeScript and React world.

All of this does not make Craftwork's initial software architecture a failure. It got us far enough down the driveway to discover what the real road looked like.

But once the product started to matter, the thing that got us started was no longer the thing that could help us scale.

It was time to rebuild.

## Rebuilding Without Disappearing

Rebuilding is an exciting, daunting, and scary prospect.

The work is hard. It is technical. It is full of tradeoffs. It requires patience, taste, discipline, and a willingness to live in an awkward in-between state for much longer than you want.

Here's the thing: your customers don't care that your rewrite is hard, or time consuming, or complex. They also don't need to.

"Bear with us, this is complicated" isn't a product strategy. People don't experience your architecture. They experience whether the product helps them do the thing they came to do.

It's tempting to hit `File + N`, and start from a blank slate. But that is a luxury we couldn't afford once our team and our customers were depending on the product to keep the business running.

So a big, dramatic cutover was a fantasy. We couldn't disappear into a cave, rebuild the whole product, and return with a perfect v1 while the business politely waited for us to finish.

The business was already running. People were already depending on the system. The old product could not simply be thrown away because it was inconvenient to maintain.

So we had to strangle it.

## What is the Strangler Fig Pattern?

The [Strangler Fig Pattern](https://en.wikipedia.org/wiki/Strangler_fig_pattern) is a way to replace an old system without rewriting the whole thing at once.

Instead of disappearing into a long, risky rebuild, you route one piece of behavior at a time through the new system. One workflow. One screen. One service boundary. One painful process.

The old system keeps running while the new one grows around it. Eventually, the new system handles enough responsibility that the old system can safely go away.

It's far less exciting than a clean-sheet rewrite.

However, it gave us more chances to get things right, and smaller consequences when we needed to change direction. Our team has been shipping improvements in smaller pieces, learning from them, and keeping the business moving while rebuilding the core of what the business depends on.

This _also_ means supporting the old system, and Keeping the Lights On™️ while the new system quietly takes over. The team building your product pays the tax of keeping both systems on, but also becomes more familiar with the old and the new as a result.

The Strangler Fig pattern allows everyone to do their job.

That's not just an engineering strategy. It's a product growth strategy.

## The Operator's Lesson

The most useful part of this process was treating the rebuild like product work instead of engineering housekeeping.

We watched where people struggled. We listened to what they complained about, but also what they were quietly telling us underneath the complaint. People are not always precise reporters of their own pain. Someone might say a workflow takes [too many clicks](https://mikebifulco.com/newsletter/stop-counting-clicks) when what they really mean is, “This workflow isn't working for me.”

Often times we'd discover behavioral patterns that started as a cheeky workaround and quickly became an invisible part of the system - a required step for getting things done. Peers using our tools would have no idea that the workaround was a workaround, because it had become a ritual. It was the only way to get the job done.

That is the operator's trap: the longer a broken workflow exists, the more people build little rituals around surviving it. If you only see the words of a feature request literally, you may rebuild the ritual instead of solving the problem.

## Rebuilding without the ritual

So, what do you do when the old system is broken, but people have built rituals around it?

You prototype, as cheaply as possible. We watched replays, interviewed people about their workflows, and put rough mockups in front of the team, asking them to show us how they would do their work. When something was confusing, we changed it. When something seemed obvious to us and useless to them, we changed it.

We also made [short video demos](https://mikebifulco.com/newsletter/reverse-devrel-as-core-engineering-skill) as we shipped updates. Not polished launch videos, just simple walkthroughs that said, “Here is what is changing. Here is how this works. Here is what we think this will make easier.”

That made the future less abstract. It gave people a chance to test changes and respond quickly, and it made feedback feel invited rather than tolerated.

The lesson I am taking from this is simple, but it took me a long time to learn:

**The goal of v0 is to learn fast enough to earn the right to build v1.**

Once you get there, the job changes. You are no longer proving that something can exist. You are responsible for helping it mature without breaking the business it now supports.

A good product is not a monument. It is a garden. You prune it. You graft new branches onto old roots. You remove what no longer belongs. You let the healthy parts keep growing while you carefully make room for what comes next.

That is the real work of being an operator: keeping the thing useful after it starts to matter.

---

## Some related reading

- [The Messy Middle](https://www.themessymiddle.com/) is a book by Scott Belsky about the challenges of growing a business after the initial idea has been proven.
- Microsoft has a great writeup on embracing [The Strangler Fig Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig)
- For a bit of _actual_ nature and the origins of the metaphor, check out this 5-minute explainer from ABC Science on the [Strangler Fig Tree](https://www.youtube.com/watch?v=B4XoYONdtb4).


The Strangler Fig Pattern: Rebuild Everything, without losing your mind

What happens when your prototype becomes a product?


# 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

"You are not your user" is fundamentally good advice. It's also occasionally wrong, but in a very useful way.

## You Are Not Your User

One of the first things you learn in UX is that **you are not your user**.

This is usually true, and is worth repeating because (all) people are very good at forgetting it. The more time you spend with a product, the harder it gets to see it clearly. You know where everything is. You know why the confusing part is confusing. You know the history behind that _one_ weird button label, and the customer complaint that led to that one edge case, and the Slack thread where everyone finally agreed to ship the thing as-is because it was Friday and everyone was tired.

That kind of knowledge is useful for building the product, but it's terrible for seeing the product.

It creates snow blindness. The product becomes so familiar that you stop noticing the parts that are strange, brittle, or needlessly complicated. You stop seeing the first five minutes because you've already lived the next five years.

<SponsoredSection
  imagePublicId="sponsors/tripo-ai/project-eden"
  sponsorName="Tripo AI"
  CTAtext="Start Creating with Tripo AI"
  href="https://www.tripo3d.ai/?utm_source=newsletter&utm_medium=sponsorship&utm_campaign=launchtinyimp"
>

**Explore AI-native 3D workflows for your product.**<br />
Turn your ideas into high-quality 3D assets faster, including product visualization, interior and home design, gaming, film, VR/AR, digital twins, robotics simulation, and interactive experiences.

</SponsoredSection>

This is one reason I try not to say "users" when I can avoid it. The problem isn't with the word itself - but rather that it adds a layer of euphemism between designers and the _people_ they are trying to build for. It's a small abstraction that cuts both ways; at times designers say "users" to sound smart, and in other moments "users" is a way to forget the reality that there are people on the other side of these screens.

The _person_ on the other side of the black mirror is probably busy. They may be distracted. They may be skeptical. They may be trying to get something done while their kid asks for a snack, their dog barks at the mailman, and their coffee gets cold.

If you want to build good products, you have to keep remembering to [imagine others complexly](https://en.wikipedia.org/wiki/Wikipedia:Imagine_others_complexly).

## Except When You Are

Every once in a while, though, you really are building for yourself.

That's how my project [Guithub](https://guithub.org) started.

Guithub is an online guitar tuner I recently built and published for myself ("recently" is doing a lot of work here. I've owned the domain since 2020, which means this tiny side project managed to take me roughly six years to finish!).

I play guitar and sing, and for years I played a couple times a month at bars around town. Like most guitar players, I own tuners. They're fine - "does what it says on the tin", as they say, but for the most part they're designed to be _generically_ useful for a wide range of musicians in a wide range of contexts.

Tuners have always bothered me in a few specific ways:

Tuners are built around standard guitar tuning (EADGBE). Most assume you are tuning open strings. If you put a capo on after tuning, it starts to sound a little weird the further you move up the neck. And if, hypothetically, you play a lot of songs in alternate tunings because you spent too much time listening to _Bon Iver_ or _The Tallest Man on Earth_, you end up doing more mental translation than you want to do while standing in front of people.

I also usually play with a laptop or tablet in front of me, with chord charts and lyrics - because I just don't have it all memorized.

All this to say: a tuner _built for me_ isn't complicated -- but it _is_ fairly different from the one you'll pull out of the box from your local guitar shop.

I wanted a tuner that worked the way I actually play. I wanted to open a browser, pick an instrument, pick a tuning, set a capo position, and get back to playing.

That was the whole idea.

Not a universal tuner for every musician in every context: a tuner for me.

## The Six-Year Side Project

The annoying thing about Guithub is that I understood the basic problem pretty well.

I studied computer science and mechanical engineering, so the math and physics behind a tuner are not especially mysterious. You listen to a sound, find the fundamental frequency, map that frequency to a note, and tell the musician whether they are sharp or flat.

That sounds straightforward until you try to make it work in a browser, on real devices, in real rooms, with real instruments.

Sound is messy. Instruments produce harmonics. Microphones vary wildly. Rooms are noisy. Browsers have their own constraints. And there is a big difference between understanding a Fourier transform and building a pitch detector that feels fast and reliable enough to trust.

The first version I built could identify notes reasonably well, but not well enough that I would have wanted to use it on stage. So the project sat there for years, in the extremely crowded drawer where I keep ideas that are "basically working" and therefore nowhere near done.

Then, eventually, I had the embarrassingly obvious thought that there might already be an npm package for this.

Of course there was.

With a library handling the core pitch detection, and an LLM helping me wire things together and test the important paths, I finally got past the part that had kept me stuck. That freed me up to work on the actual product.

The product was never "can I implement signal processing from scratch?"

The product was "can I tune quickly and get back to the song?"

That distinction matters. A lot of side projects get stuck because the interesting technical problem disguises itself as the product. Sometimes it is. Often it's just the thing standing between you and the product.

## The Homepage Is the Product

Because Guithub is built for the exact situation I kept running into, the homepage is the product.

There is no ceremony: go to [guithub.org](https://guithub.org), modify default settings if you need to, and get to tuning. It supports guitar, bass, banjo, and ukulele. It supports different tunings. It supports capo positions. It is meant to be useful on the device I probably already have in front of me when I am playing.

I have tried not to turn it into a fluffy product homepage, even though search engines and LLM indexers would prefer that. It's a funny tension: SEO wants explanation, but a great product experience is (in this case) just the thing itself.

For this project, I'm trying to let the tool win.

The best version of Guithub is not impressive. It's forgettable in the right way. It opens quickly, helps you tune, and lets you move on with your life.

That is what I wanted as a musician - and if that's what other guitarists want, I'll be super happy to see it.

## Build the Thing That Keeps Bothering You

This is the part where "you are not your user" gets complicated.

You should not assume everyone is like you. That's a path to misguided products, confusing defaults, and founders confidently explaining that customers are wrong for not understanding the brilliant thing they built.

But... _sometimes_ your own frustration is a useful starting point. Not because it makes you representative of the whole audience, but because it gives you access to details and compassion that are hard to fake.

You have _felt_ existing options fail you. You know which parts are merely annoying and which parts actually matter. You know the little moment where you mutter under your breath and think, "why does this work this way?"

That moment is worth paying attention to.

[Craftwork](https://craftwork.com) came from a version of this too. Finding a reliable, professional, high-quality painting company for your home should not feel like a gamble, but it often does. That frustration was specific enough to give us a place to start.

Specific frustration is not the same thing as product-market fit. It's not proof that other people care. It's not a business model. It's not distribution.

But: it _is_ a signal.

Sometimes the thing that keeps bothering you is just a thing that keeps bothering you.

Sometimes it's the first draft of something useful.

---

## Guitarists, try my sweet tuner

If you play music ([_like me!_](https://guithub.org/about)), I would love for you to try [Guithub](https://guithub.org). And if it breaks, annoys you, or gets in your way, please tell me. You can reply here or email me at [hello@mikebifulco.com](mailto:hello@mikebifulco.com).


You are not your user. Except when you are.


## The Big Idea

AI makes it easier than ever to build something that feels like it works. It does not make it easier to understand what you've built, how it works, or how it might break.

---

## Learning Feels Like Progress, Until It Doesn't

One of the most enjoyable parts of learning something new is how quickly it can feel like you're getting good at it.

You start from nothing, make a bit of progress, and then suddenly things begin to click. A few early wins stack up, and you get that dopamine boost from the feeling that you have a handle on what you're doing. If you've ever watched someone pick up a new skill for the first time, you've probably seen this happen. Beginner's luck and a handful of successful attempts can create a surprising amount of confidence.

The problem is that this confidence is often built on a very small slice of reality.

When you've been doing something for a long time, you develop an intuition for how much there is to know. Beginners do not have that perspective yet, which makes it easy to overestimate how far along they are. Eventually, if they stick with it, they run into the limits of their understanding. That moment, when things stop working as expected and the gaps become obvious, tends to be uncomfortable, but it is also where real learning begins.

This pattern is well understood as the [**Dunning-Kruger Effect**](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect). More formally, it describes the tendency of people with a small amount of experience to be overconfident in their abilities. It also captures the inverse tendency, where highly skilled people underestimate their relative competence. The effect was first identified by psychologists [David Dunning](https://en.wikipedia.org/wiki/David_Dunning) and [Justin Kruger](https://en.wikipedia.org/wiki/Justin_Kruger) in 1999.

The Dunning-Kruger Effect is a natural, typical pattern of human learning. It is **not** a sign of low intelligence. It's a lack of experience.

The issue is not confidence itself. It is confidence that has not yet been tested.

---

## AI Changes the Pace, Not the Fundamentals

When everyone has superpowered LLMs at our fingertips, the game changes. What's different now is how quickly someone can get an early sense of competence.

Rather than learn about weather patterns or signal processing or buying ads on Google (or whatever problem you're working on), you can slap a few sentences together and send it off to your LLM of choice, and in moments you can have a working prototype.

That's really cool - but it should give you at least a _little_ anxiety.

Modern AI tools make it possible to build things that would have taken weeks or months in a matter of hours. Someone who has never written code before can assemble a working application, connect it to real data, and deploy it to the internet without fully understanding how any of it works. The results are often impressive enough to reinforce the feeling that they are on the right track.

It is hard to overstate how big of a shift this is. The first program I ever wrote added three numbers together and printed the result to a terminal. It was simple, but it forced me to understand every step along the way. That constraint is largely gone now.

What has not changed is how computers behave. They still do exactly what you tell them to do, even when what you told them to do is incomplete, inconsistent, or quietly destructive. AI can help you write those instructions faster, but it does not guarantee that they're correct.

---

## Experience Is Mostly About Anticipating Failure

If you spend enough time around production systems, you start to realize that a large part of the job is not building new features, but anticipating and avoiding failure modes.

That is why experienced teams invest so much energy in things that can feel tedious at first glance. They plan before they build. They test changes in environments that are isolated from real users. They introduce safeguards like feature flags and rate limits, and they maintain the ability to roll back changes when something goes wrong. These practices exist because systems are fragile in ways that are not always obvious, especially early on.

If you are new to building software, and especially if you are learning through AI-assisted tools, there is a good chance you have not yet had the experience that makes these practices feel necessary. That is a normal part of the process. The risk comes from assuming that you can skip that part entirely, or worse, _not knowing_ that you should be doing it.

Dunning-Kruger comes for us all.

---

## The Real Risk Is Misplaced Confidence

The tools themselves are not the problem. The combination of speed and confidence is.

When you can build something quickly and it seems like it works right away, it's natural to trust it more than you should. That trust can extend further than it ought to, especially when the system begins to handle real data or real users.

Here's my April 2026 Prediction: Sometime soon, someone is going to push something into a context where the stakes are higher than their understanding of the system, and it is not going to behave the way they expect. Overconfidence will meet under-experience, and something will come crashing down. This will cause real, profound problems for a business that has been otherwise successful, and the dominos will start to fall. Will it be a fortune 500 company, a moonshot startup, a government agency, or a small business? I don't know the answer to that, but I feel confident that something will happen, and we'll all learn hard lessons from it.

It is not hard to imagine how it plays out. Ask your engineer friends about their biggest fears for failures in production: A script runs twice when it should have run once. A production database gets deleted with one little line of code. A set of permissions is broader than intended. A piece of logic that seemed harmless at small scale behaves very differently under load.

None of these scenarios are new, but the barrier to encountering them is now much lower.

---

## What This Means in Practice

If you have been doing this for a while, your role is not to discourage people from using these tools. It is to help them use them safely.

That usually means putting guardrails in place where they matter most. Limiting access to production systems, being deliberate about how credentials are managed, and creating environments where experimentation does not carry real risk all go a long way. Just as important is being open to the fact that people will be exploring vibe coding tools. That curiosity is a good thing! When exploration happens in the open, it is much easier to guide it.

If you are newer to this world, **the most useful thing you can do is adopt a deliberate skepticism** toward the tools you use and anything you build.

Assume that your system has edge cases you have not considered. Look for the places where it might break, especially under conditions that are slightly different from what you tested. Make sure you have a way to recover when something goes wrong, whether that means backups, staging environments, or simply the ability to turn something off quickly.

It is also worth writing down how your system works, at least at a high level. The decisions you make early on tend to fade from memory faster than you expect, and when something breaks, that context becomes incredibly valuable.

Perhaps most importantly, resist the urge to treat speed as the primary goal. Building quickly is useful, but building something you understand is what allows you to keep it running.

---

## Understanding the Tool Matters More Than Using It

None of this is an argument to avoid AI. These tools are genuinely useful, and they are only getting better.

But it is important to understand what they are doing. Large language models are not reasoning about your system in the way a human collaborator might. They are generating likely sequences of text based on patterns in their training data and the context you provide. That can produce very convincing output, but it does not come with guarantees.

The people who benefit most from these tools are the ones who can engage with them critically. They can ask better questions, recognize when something looks off, and take the time to verify the results before relying on them.

In practice, that means [spending more time reading and writing](https://mikebifulco.com/newsletter/next-great-engineering-skill-is-context-not-code) than you might expect. It means thinking through your systems in plain language, not just code, and being able to explain what they are doing and why.

---

## The Curve Is Still There

The underlying learning curve has not changed.

It is still easy to feel confident early on, and it is still necessary to move past that initial confidence to build something durable. AI has made the early stages faster and more rewarding, but it has not removed the need for deeper understanding.

If anything, it has made that understanding more important.


Dunning-Kruger for Vibe Coders

Learning Feels Like Progress, Until It Doesn't

AI Changes the Pace, Not the Fundamentals

Experience Is Mostly About Anticipating Failure

Understanding the Tool Matters More Than Using It


## The Big Idea

Your brain rewires itself based on what you practice. If you stop practicing hard things, you slowly lose the ability to do them.

---

Early in my career I remember sitting at a bar with two close friends, laughing about something we called **"information addiction."**

It would only take a few minutes of observation to see it: if we didn't know something, we googled it -- immediately.

Movie trivia? Google it.
Strange symptom after a long flight? Google it.
When was Sean Connery born? Google it.

At the time this felt revolutionary. As millennials, we grew in the first generation where knowledge was always within reach. Expertise wasn't something locked inside universities or trade guilds anymore. It was a few searches away.

That experience shaped a lot of how I think about my generation. The defining skill millennials developed wasn't memorization. It was learning how to learn. If you could research, synthesize, and experiment, there was almost no problem you couldn't teach yourself to solve.

But something has changed in the last few years.

The internet used to give you **information**. Now it increasingly gives you **answers** (whether or not they're correct is another story).

- Why read _Hamlet_ when an LLM can summarize it perfectly?
- Why grind through calculus when a model can solve every step instantly?
- Why learn Cantonese if a phone can translate the conversation for you?

The temptation is obvious... effort is optional now.

And human beings are very good at choosing the easier path.

I'm not immune to this either. I use LLMs all the time; they're incredible tools. They help me write code faster, summarize documents, and explore ideas in ways that would have taken much longer even a few years ago.

I've come to realize there's an important difference between **getting an answer** and **learning something**.

The difference is happening inside your brain.

## Neuroplasticity

There's a concept in neuroscience called **neuroplasticity**, which describes the brain's ability to reorganize itself based on how it's used.

In simple terms: the more you do something, the stronger the neural pathways supporting that activity become. Practice literally changes the structure of your brain. And if you stop practicing something long enough, those pathways weaken.

In other words: **use it or lose it** is a real thing.

That's why musicians practice. It's why I was fluent in Spanish after high school, but was barely conversational 15 years later. It's why someone who writes code every day develops instincts that no tutorial can fully explain.

Learning is not just absorbing information. It's building physical circuitry.

And circuitry only forms through effort.

## Some Lessons Are Best Learned the Hard Way

I can generate code with Claude or Codex. But I won't write great software unless I keep practicing and scrutinizing my code.

I can translate a paragraph of Spanish instantly with Google Translate. But I can't actually understand a conversation unless I spend years training my ear and vocabulary.

The same thing is true with music. The more often I pick up my guitar, the better my playing becomes. There's no shortcut to becoming a better musician.

Some knowledge only exists on the other side of repetition.

Which is why I've started to believe something that sounds slightly old-fashioned:

**Some lessons are best learned the hard way.**

Not because technology is bad. Not because efficiency is wrong. But because your brain still runs on the same rules it always has.

If we stop practicing difficult things, we eventually lose the ability to do them.

## A Small Suggestion

So here's my suggestion: Pick at least _one thing_ in your life that you're willing to learn the hard way.

Something where progress comes slowly. Something where you have to practice even when it's frustrating. Something where the only real path forward is repetition.

For me, it's been keeping up with music and language learning.

Neither of them can be optimized away. Both of them reward patience. And both of them sharpen a part of my brain that shortcuts can't reach. They challenge and strengthen parts of my brain that I wouldn't otherwise use, and help me have real, meaningful connections with other people in my life. They create opportunity, empathy, and human connection.

If you want to keep your wit sharp in an age of instant answers, make sure there's at least one thing you're still willing to practice the slow way.

---

## More from me this week

<Image
  publicId="newsletters/lessons-i-learned-the-hard-way/guithub"
  alt="Screenshot of the Guithub app for tuning your instrument"
  caption="I built the guitar tuner I always wanted"
/>

- Speaking of practicing music, I recently shipped the guitar tuner I always wanted - [Guithub](https://guithub.org) is a tiny little PWA for tuning your instrument on the fly. It has all the features I ever wanted: support for multiple tunings, capo positioning, as well as bass guitar, ukulele, banjo, and more. I also got to play with an aesthetic I like. If you're a musician, give it a look! Proper launch announcement coming soon.

- My interview with [Alex from Supergood](https://apisyouwonthate.com/podcast/supergood-is-building-unofficial-apis-for-everything/) for the APIs You Won't Hate podcast. Alex is a supremely thoughtful guy, and his company is building a super interesting product. Supergood is building unofficial APIs for everything - really.


Some things are best learned the hard way.

Lessons I Learned the Hard Way

Some Lessons Are Best Learned the Hard Way


## 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

Stable products still need maintenance. Defaults and shiny features quietly tax systems over time, and efficiency is a sign of craftsmanship, not penny-pinching.

## “Just Enough” Is an Ongoing Practice

At some point, my next.js website crossed a line I did not notice right away. It was stable, not changing much apart from new posts and newsletters. Traffic was healthy. And yet, I was steadily consuming more of the resources measured by **Vercel's free tier**. Nothing had broken. Nothing felt slow. But the line on the graph kept moving in the wrong direction.

That surprised me.

We often tend to think of stability as the end of something. Engineer ship something, it works, and we move on. Modern web frameworks ship with helpful defaults, and those defaults are optimized for convenience, not restraint. Prefetching everything on the page. Recomputing pages that could have been built once. Redirecting politely when a bot is clearly probing your pagination. Individually, each decision makes sense. Over time, they quietly add up.

Taking time to chase this down pulled me away from real work, the kind with deadlines and people waiting on me. I am not short on things that demand attention.

The results of a few hours of my time were exactly the doctor ordered:

<Image
  publicId="newsletters/just-enough-is-an-ongoing-practice/isr-reads"
  alt="A screenshot of the Vercel dashboard showing ISR reads before and after the changes"
  caption="ISR Reads before and after the changes"
/>

<Image
  publicId="newsletters/just-enough-is-an-ongoing-practice/fast-origin-transfer"
  alt="A screenshot of the Vercel dashboard showing Fast Origin Transfer before and after the changes"
  caption="Fast Origin Transfer before and after the changes"
/>

ISR Reads and Fast Origin Transfer both dropped dramatically, and flattened out. The site went back to living comfortably within a modest tier, even with steady traffic. What struck me was not how clever the fixes were, but how ordinary they felt in hindsight. These were not optimizations born from genius. They were the result of paying attention.

<Aside type="note">

👉 <b>Interested in the details of these changes?</b> Check out my post on [reducing Next.js bandwidth with link prefetch](https://mikebifulco.com/posts/reduce-nextjs-bandwidth-with-link-prefetch).

</Aside>

## Keeping the lights on

The larger takeaway isn't at all about ISR or Fast Origin Transfer or prefetching. I think there's a lesson in what it means for a product to be "finished".

Launches of new products and features are exciting. It is _always_ a thrill to be working on the new hotness, drawing attention from your peers and customers.

But - there is a version of craftsmanship that only shows up after spotlight moves on. Funny enough, during my time at Google and Stripe, this was called KTLO: Keeping The Lights On.

## The unsung hero of the product lifecycle

This is the craft and attention to detail that shapes the integrity of the system. Efficiency, performance, and even environmental impact rarely make it into launch announcements. They still shape the integrity of the system. It's the work that is often thankless, and invisible to end users.

Growing the skill for this kind of work is not a one-time event. It is a skill that must be cultivated over time. It is a skill that must be practiced regularly. It is a skill that must be honed over time.

This is the same idea I wrote about before as **[just enough, nothing more](https://mikebifulco.com/newsletter/reflecting-on-one-year-as-startup-cto#just-enough-and-nothing-more)**. You don't cross the finish line once. You return to it. You notice drift. You develop a sense for new signals to listen to from the systems you've built and used. You remove things that no longer serve the system. You question defaults that once seemed harmless.

A stable product is not a finished product. It is simply a product that now requires a different kind of care.

“Just enough” is not a milestone. It is an ongoing practice.


Just Enough Is an Ongoing Practice


## The Big idea

This year, my work shifted from "write code" to "orchestrate systems." That means communicating well, taking great notes, and using AI tools to enhance my thinking rather than replace it.

## The Hardware

I work on a 14" M2 MacBook Pro. I'm a big fan of the M-series chips - my M2 hasn't slowed down yet. I prefer portability over screen size since I do a lot of work from kitchen counters and coffee shops.

At my desk, I run dual 27" 4K monitors with the Mac in clamshell mode, plus a Logitech MX Keys keyboard and MX Master 3 mouse - a setup that hasn't changed in years.

I'm also getting more done on my phone than ever - currently a Pixel 10 Pro. I've been eyeing Nothing phones lately; their quirky-meets-minimal design ethos is appealing.

E-paper devices have been in and out of my bag this year. A friend gifted me a Daylight Computer, which I use for reading and notes. I also briefly had a Boox Palma 2 - a _sublime_ phone-sized e-reader I loved until its fragile screen broke. Glad I paid for the extended warranty.

## My Software Stack

The biggest change from last year? My software stack changes regularly now. I've flipped between IDEs, switched note-taking apps, and dabbled with AI tools across the spectrum - from ChatGPT and Gemini, to Copilot and Cursor and Claude Code, to fully-local models via Ollama.

The takeaway: flexibility beats loyalty. Tools are changing fast, and it's worth trying new ones to see what fits.

Here's what I'm _currently_ using:

### Claude Code

[Claude Code](https://claude.com/product/claude-code) lets me stay in the role I'm best at: planner, architect, reviewer, unblocker. I spend less time executing and more time shaping the work. Critically, it doesn't replace my judgment - it multiplies it. [I've been reviewing code for years](https://mikebifulco.com/newsletter/ai-is-your-intern-not-your-boss), and Claude keeps me reading code and providing active feedback. I'm not writing zero code, but I am writing a lot less.

### MCPs (Model Context Protocol)

MCPs are the quiet unlock. They connect Claude Code to real systems instead of isolated prompts - repos, tickets, docs, logs, all linked. This is what turns AI from a clever assistant into something that can reason alongside you.

### Obsidian

I take [**loads of notes**](https://mikebifulco.com/newsletter/unlock-productivity-with-networked-note-taking) - meetings, calls, books, friends, articles, you name it. I switched from Logseq to [Obsidian](https://obsidian.md/) this year due to an ongoing macOS bug that made Logseq painfully slow. Obsidian is fine, but it suffers from Notion's curse: it's too easy to get distracted perfecting your setup instead of using the tool.

### Raycast

[Raycast](https://www.raycast.com) replaces Spotlight on macOS. It's more than a launcher - I use it for translations (English ↔ Spanish), looking up Tailwind classes, finding Lucide icons, and dozens of other small utilities throughout my day.

### WisprFlow

[WisprFlow](https://ref.wisprflow.ai/mike-bifulco) is a voice-to-text tool that runs locally on your Mac. Talk to your computer and it turns into text. I'm a fan of multimodal input; I spent years on the Google Assistant team waiting for seamless switching between typing and talking. WisprFlow delivers that, and it understands code-speak surprisingly well. Say "users slash mike" and it outputs `users/mike`. I use it constantly now for thoughts while walking, rough designs, notes to myself, and messages to teammates.

### Linear

[Linear](https://linear.app) is still the backbone of planning for my team. It's where our shared understanding of the work plan lives. It's also where we share context with LLMs via MCPs, meaning Claude Code can read and update Linear tickets as work gets done. This helps documentation happen automatically instead of as an afterthought.

### The product stack

The way we build software at [Craftwork](https://craftwork.com) is changing too. We use TypeScript for most of our code now, steadily moving away from Ruby on Rails. The app lives in a monorepo: Next.js, React, TypeScript, OpenAPI, tRPC, and Postgres. We also rely on a handful of third-party tools: PostHog for analytics, Render for hosting, Sentry for errors, Stripe for payments, and Twilio for voice/SMS.

## The secret sauce

This is the year I started viewing my 20+ years of writing code as a replaceable commodity. Thanks to LLMs, the difference between an engineer and a 10x engineer is [no longer code](https://mikebifulco.com/newsletter/next-great-engineering-skill-is-context-not-code). It's context, collaboration, and communication, with humans and machines alike.

Many devs struggle with this. I share my tools and workflow because I find it helpful when others do the same, but ultimately the tools are worthless without the people. Bring humanity, creativity, and humility to your work. Invest in yourself.


My 2026 Developer Tech Stack


## The Big Idea

Most habits don't fall apart because people quit. They fall apart because they aren't sticky.

Cognitive science tells us that habits form when a simple loop closes: a cue triggers an action, the action produces a reward, and the brain decides the sequence is worth repeating.

As builders, we often focus on the loop inside our apps. But the most successful products understand that the loop starts long before a user ever signs up. This is The Zeroth Loop.

<SponsoredSection
  imagePublicId="sponsors/crowdstake/landing-page-builder"
  sponsorName="Crowdstake"
  CTAtext="Start Pre-Launch"
  brandColor="#0B5D9E"
  href="https://www.vpdae.com/redirect/rsv3r61v9hvqbdgc7czgbhwjhh6"
>

### Quickly turn ideas into beautiful landing pages

Launch AI-powered waitlist landing pages in minutes. Test demand, pricing, and features. Know exactly what your audience wants before building - no tech skills required.

</SponsoredSection>

<img
  src="https://www.vpdae.com/open/cf6ab0e8.gif?opens=1"
  width="1"
  height="1"
/>

## The Zeroth Loop: Before the First Use

The first encounter with a product usually happens in the wild: a landing page, a demo video, or a screenshot shared on social media.

The strongest marketing moments already contain a full behavior loop. When you watch a great 15-second demo, your brain performs a dry run. You see the cue, you recognize the action, and you anticipate the reward.

A good demo doesn't just explain features; it allows the user to experience the payoff ahead of time. By the time they click "Sign Up," the habit loop already exists in outline form. The **Zeroth Loop** has already closed.

## Where Your Products Lose Momentum

Product people tend to spend loads of time planning and building the nuts-and-bolts of how our apps work. We spend hours designing the perfect onboarding flow, the perfect settings page, the perfect error message.

Marketing people tend to think about the moments _before_ features matter - how do people find and engage with your product in the first place?

These two perspectives are hugely important, and they need to work together. Neither is optional for your product to be successful.

Builders who don't have marketing chops tend to overestimate intent. We see a signup as commitment, but often it's just curiosity. If a person's first interaction with your product doesn't produce a clear, immediate reward, the behavior never stabilizes.

When this happens, nothing _really_ breaks. The app just fades into the background. It stays installed, the tab stays open, and the user simply forgets it exists.

The habit never formed, and all your work goes to waste.

## Systems Over Memory

This is why thoughtful nudges are so important. Reminders often get a bad reputation because they're implemented poorly, but their cognitive role is simple: they reintroduce the cue before a new routine vanishes from memory.

<Image
  publicId="newsletters/zeroth-loop-they-dont-quit-they-forget/reward-cycle"
  alt="The cue-response-reward cycle"
/>

Durable habits don't rely on willpower or perfect recall; they rely on systems that bring the cue back before the natural erosion of forgetful humans takes over.

## A Tiny Improvement: Design for Three Loops

Zoom out and reframe your product journey around the first three loops:

<Image
  publicId="newsletters/zeroth-loop-they-dont-quit-they-forget/three-loops"
  alt="A three-loop diagram"
  caption="A three-loop diagram"
/>

### The Zeroth Loop (Marketing)

Does your demo or screenshot allow the user to visualize the reward? Can they "feel" the problem being solved before they even have an account?

### The First Loop (Onboarding)

Is onboarding and time-to-value fast enough to keep the user engaged? Getting people to _do something useful_ for the first time is the critical path here.

### The Second Loop (Utility)

Once they take the action, how quickly do they get evidence of success? In other words, has your tool or app actually delivered on its promise?

## The Takeaway

The reward is rarely the interface. If your app helps people optimize code, the reward isn't a "Success" toast message- it's the faster build time or the green checkmark in GitHub.

The outcome has to show up in the user's own context. That external payoff is what creates the memory: "Last time I did this, something good happened." When that happens early, repetition follows naturally. When it doesn't, no amount of UI polish can save it.

---

## More reading on habit loops

- [The Power of Habit](https://hardcover.app/books/the-power-of-habit-why-we-do-what-we-do-in-life-and-business): A clear and approachable explanation of the cue-routine-reward loop, with enough real-world examples to make it useful beyond theory.

- [Fogg Behavior Model](https://thedecisionlab.com/reference-guide/psychology/fogg-behavior-model): A practical framework for understanding why behaviors happen, and why they often don't. Especially helpful for diagnosing stalled adoption.


The Zeroth Loop: They Don't Quit, They Forget

Quickly turn ideas into beautiful landing pages

A Tiny Improvement: Design for Three Loops


## The Big Idea

What if sleeping a little better, moving a little more, and finding a sense of purpose could measurably change your life?

Not as a vibe. As a fact, supported by decades of research.

## How to live a long, happy life

When researchers study people who live the longest, most fulfilling lives, they don't find hacks or extreme discipline. They find the same small behaviors repeated quietly over time.

Thankfully, there's no magic to it. The behaviors that have emerged are simple and accessible, and -- apparently -- they work. If you're looking for a "one weird trick" panacea, you won't find it here. The fact of the matter is that when you repeat a few seemingly small behaviors over and over again, they start to add up.

## Why tiny beats dramatic

Big changes fail because they ask too much, too fast. Small habits succeed because they're easy to repeat. I love that this is backed by actual, real Behavioral science, too - the data shows that consistency is better than intensity.

A tiny habit rarely feels life-changing in the moment. But repeated often enough, it changes what a normal day looks like. Enough normal days, and the long arc follows.

## The same habits, over and over again

Across longevity research, the same few habits appear again and again:

- **Adequate rest:** Roughly seven to eight hours of quality sleep, consistently.

- **Eating lots of plants:** Meals centered on vegetables, fruits, legumes, and whole grains, with moderate portions.

- **Daily, natural movement:** Low-impact movement woven into everyday life.

- **Strong social connection:** Regular time with friends, family, or community. It's a stronger predictor of happiness than wealth.

- **A sense of purpose and optimism:** Feeling useful, connected, and oriented toward something that matters.

Over the course of a lifetime, these tiny shifts in mindset and behavior can have a massive impact on you. And to me, at least, no single one of these sounds particularly difficult to maintain.

## Little changes that snuck up on me.

For years, I have been adopting little, bitty morsels of self-improvement. They help me to grow personally, stay balanced, and manage stress.

When I started managing a team at Google during the pandemic, I adopted a [simple morning ritual](https://mikebifulco.com/newsletter/continuous-self-improvement). I do five minutes of journaling, and five minutes of meditation. Nothing elaborate. That small routine helped me manage stress and show up more consistently for my team.

I've also been doing daily language learning for years. Just a few minutes a day stretches a different part of my brain, and has satisfied my personal desire to learn something new. Even better, I'm at least _conversational_ in Spanish, and I can read a surprising amount of Japanese by now!

## The Long View

Longevity and happiness are on my mind a lot lately - I've been thinking about shaping the long arc of my life's story. I want to be as happy as possible for the small amount of time I have on earth. It's as easy as that!

I find it very encouraging that there is research behind these ideas... If small habits can reliably improve a day, it's not much of a leap to believe they can shape decades too.

As the new year approaches, maybe it's worth a complete shift in perspective: You don't need a hard reset. Instead, maybe adopt a habit that's easy enough to keep, even on bad days.

Then, maybe: another one.

## My Question for You

**When you try to build new habits, what actually works for you? How do you keep yourself honest once the motivation fades?**

Hit reply and tell me. I read every response, and I'm genuinely curious.

---

## More reading

Ready to go all-in on longevity, habits, and happiness? Here are some of the resources I found myself reading that really grabbed my attention.

- [A Harvard Study of Adult Development](https://news.harvard.edu/gazette/story/2017/04/over-nearly-80-years-harvard-study-has-been-showing-how-to-live-a-healthy-and-happy-life) shows that close relationships and social connection are stronger predictors of long, healthy lives than wealth, fame, or status.
- [Blue Zones and the Power 9 Principles](https://pmc.ncbi.nlm.nih.gov/articles/PMC6125071/) is a study on communities where people live past 100 most often. It identifies common lifestyle traits tied to longevity, like natural movement, purpose, and plant-forward diets.


Science-Backed Secrets of Long, Happy Lives


## The Big Idea

The best product ideas hide in plain sight, in your habits and everyone else's. Watch what people actually do, not what they say they want. Build for that.

Most teams start their search for ideas with a brainstorm. The trouble is that people are unreliable narrators of their own needs. We guess. We speculate. We tell ourselves a story about what might help, instead of looking at how we actually behave.

Lucky for you, a little applied science can give you a clearer way to see.

Below are three ideas rooted in behavioral psychology which can help you find opportunities through observation of your own habits and those of others.

### Revealed preference

**Revealed preference** is the idea that actions speak more clearly than opinions.

In the software world, these actions are everywhere. When developers repeat the same chores by hand, maintain a giant list of test data in a scratch file, or juggle three tools to get one thing done, they are revealing what they actually need.

[Bruno](https://www.usebruno.com/?ref=mikebifulco.com) is a clean example. It's an API tool that has gained favor as Postman added account login requirements that their users weren't asking for, while the real preference was simple: keep everything local, work fast, commit changes, share them with a team.

<Image
  publicId="newsletters/mirror-effect-cognition-behavioral-science/bruno"
  alt="A screenshot of the Bruno homepage"
  caption="Bruno's success isn't a coincidence. It's the result of paying attention to the way devs use their tools."
/>

Bruno didn't invent a new workflow. It paid attention to the one people were already trying to use.

### Habit loops

When behaviorists talk about the **Habit Loop**, they describe it as cue, routine, reward. If the routine becomes messy, people still follow it, because the reward matters.

But the mess reveals an opportunity.

Testing an API is a perfect illustration. The cue is obvious. The reward is seeing the result. What changed over time was the routine. Postman added friction. Bruno's approach added value. All Bruno did was design a routine that matched the way developers already think.

When you look closely at routines that people repeat every day, the problems usually introduce themselves.

### Jobs to Be Done

**Jobs to Be Done** reframes product building around one question: what job is someone trying to get done, and how well are their tools helping them do it?

People "hire" their tools and workflows when they get things done. Sometimes it means a stack of half solutions held together with muscle memory. When you see the duct tape, you are seeing the job that isn't being served very well.

In Bruno's case, the job was straightforward. Teams wanted an easy, dependable way to explore and share their API workflows with their teams. The job didn't change. The tools did.

## Gaze into your own mirror

This process of finding opportunities works best when you turn the lens on yourself.

Ever tried to describe your workflow to someone who has never done it before? I bet you'll find _something_ that sounds at least a little absurd that you've been doing for ages.

Look at the workflows you repeat without thinking. Look at where you slow down, or compensate, or adapt to a tool that isn't quite right. These moments are often small, but they are rarely isolated. If something bothers you, it probably bothers someone else. Enough shared friction becomes a market.

Most people think they need inspiration. What they really need is observation.

## The takeaway

You don't have to invent a brand new idea. You just have to watch behavior more closely than everyone else.

_Revealed preferences_ show you what people truly value.

_Habit loops_ show you where routines break down.

_Jobs to Be Done_ shows you why the work matters in the first place.

Everything else is just paying attention.

---

# Keep on learning, my dudes

- Everyone's favorite self-help author James Clear has a great article on the [Habit loop](https://jamesclear.com/habit-triggers) that's worth a read.
- [Jobs to be done](https://hardcover.app/books/jobs-to-be-done-theory-to-practice) is the OG tome by Clayton Christensen that broke ground on the idea of breaking down customer needs into specific "jobs" that your product can satisfy.


The Science of Spotting Hidden Product Ideas


## The Big Idea

Every message is a moment of influence. Make the nudge helpful and you'll create power users and build loyalty.

## What is Nudge Theory?

Nudge Theory is a framework for guiding user behavior through subtle, persuasive techniques. It is based on the idea that people are more likely to change their behavior if they are given a choice that is easy to make.

In other words, a little proactive messaging goes a long way.

### Why Nudge Theory Matters

There's a little bit of behavioral science at play when a product uses thoughtful nudges in its onboarding. Research in behavioral economics shows that small, well-timed cues can help people adopt new habits and tools more easily. In other words, a gentle nudge at the right moment can make all the difference.

## A concrete example: Blacksmith

That's exactly what we found with [Blacksmith](https://blacksmith.sh?utm_source=tinyimprovements&utm_medium=email&utm_campaign=nudge-theory-for-guiding-user-behavior). It promised to speed up our CI workflows for less cost, something my team at [Craftwork](https://craftwork.com) would benefit from immensely.

<Image
  publicId="newsletters/nudge-theory-for-guiding-user-behavior/blacksmith-value-prop"
  alt="A screenshot of the Blacksmith's home page value prop"
/>

Our initial onboarding was smooth - the software generated a PR to swap our CI workflows onto their infrastructure. The speed boost was immediate, and life-changing for my team.

### Thoughtful Nudges in Action

What really impressed me was what happened a day later - each day, I would receive an email with a new tip, rooted in behavioral insights, to guide us step-by-step on how to get the most value from Blacksmith.

From the first message, Blacksmith gently introduced us to one feature at a time. Each day, a new tip arrived - ensuring that the game-changing features the Blacksmith team built didn't get lost in my haste to try the product out on Day 1.

<Image
  publicId="newsletters/nudge-theory-for-guiding-user-behavior/blacksmith-drip-campaign"
  alt="A screenshot of the Blacksmith's onboarding process"
  caption="Zero code-changes required? Sign me up."
/>

They could have spent a lot of time developing a slick, highly-interactive onboarding wizard -- which I almost certainly would have skipped. Instead, a slick little drip campaign offered even more value for my team.

You better believe I tried each one.

---

## Use these powers for good

- The Wikipedia entry for [Nudge Theory](https://en.wikipedia.org/wiki/Nudge_theory) is a great primer - it may sound wishy-washy, but this is real behavioral science.
- Nudge Theory is, of course, a two-sided coin - there's a great paper on [ethical concerns with nudging](https://journals.sagepub.com/doi/10.1177/10434631231155005) that is worth a read.

So, how will you turn this knowledge into action? Whether you're building a product or trying to influence people to be better neighbors, there is a whole lot of power in the way you reach people with your messaging.


💌 Tiny Improvements

💌 Read the latest dispatch