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










The Psychology Hack Hiding in Great Products


## The Big Idea

Open source works best when we treat each other like humans - not vending machines for bug fixes.

## How We Patched a Broken Package - and What It Taught Us

Recently at [Craftwork](https://craftwork.com), we hit a snag using the [@payloadcms/storage-uploadthing](https://github.com/payloadcms/payload/tree/main/packages/storage-uploadthing) plugin for image uploads in [Payload CMS](https://payloadcms.com).

One of our engineers dug in, found the issue, and fixed it. We opened a [pull request](https://github.com/payloadcms/payload/pull/14250), hoping to help others in the same situation.

But here's the thing: We couldn't afford to wait for the PR to get merged before moving forward. Publishing a forked npm package is a common fallback - but it can be hard to maintain long-term.

In addition to creating a fork to submit a fix, we used [`pnpm patch`](https://mikebifulco.com/posts/patching-npm-dependencies-with-pnpm-patch) to apply the fix to our repo. It's clean, version-controlled, and works until the upstream package is updated.


## Maintainers Aren't the Problem

It's easy to forget that open source projects are often maintained by small teams under heavy load. At the time of writing, Payload has over 375 open pull requests. Expecting our fix to jump the line would be absurd.

This isn't about neglect or indifference. It's about capacity.

In other repos, we've seen PRs sit untouched for months, with long threads of angsty, impatient comments. I get it - but that doesn't help anyone. Especially not the maintainers.


### A Better Way to Contribute

Here's what we did instead:

- 🛠 Fixed the issue locally using `pnpm patch` (need a tutorial? I [gotchu](https://mikebifulco.com/posts/patching-npm-dependencies-with-pnpm-patch))
- 💬 Shared the patch tutorial in the GitHub PR to unblock others
- 🔁 Opened a new, cleaner PR
- 🤝 Let the maintainers off the hook - no pressure, just help

This approach makes open source better for _everyone_. It gives control back to contributors, and it gives maintainers room to breathe.

It is easy to forget that contributing to open source isn't just Pull Requests - discussion, community building, managing expectations, and creative solutions help us all build a better internet together.

I'm confident you'll get more results if you treat people with humanity - and you will [build a reputation for yourself](https://mikebifulco.com/newsletter/serendipity-isnt-an-accident) that makes people eager to help you when they can.

---

## Want to Do Open Source Better?

Read [*Working in Public*](https://hardcover.app/books/working-in-public) by Nadia Eghbal. It's the best book I've read on the culture of open source: what's broken, what's beautiful, and what's worth fixing.

Also, if you like learning by watching smart people build in public, check out:

- [cmgriffing](https://www.twitch.tv/cmgriffing) streams dev work and product experiments on both Twitch and YouTub
- [Rizel Scarlett](https://www.twitch.tv/blackgirlbytes1) does open source work, conference prep, and interviews on her channel

---

## Give without the expectation of receiving

Open source is a special kind of economy. Show up with something useful. Share what you've learned. Make it easier for the next person.

Let's be better guests in each other's repos.


Contributing to Open Source without being a Jerk

How We Patched a Broken Package - and What It Taught Us

Give without the expectation of receiving


## The Big Idea

When providing accurate context is make-or-break for your workflow, everyone needs to become a better writer.

We convinced ourselves that moving fast was the same as being smart. Shipping first. Reacting faster than anyone else. What we did not notice is that this trained an entire generation of builders to think only in the moment, never on the record.

That mindset worked when everything stayed in your own head. It breaks completely when your collaborators are machines. And it is the same thing your teammates have quietly been begging you to fix for years.

### Why this suddenly matters

- With LLMs and agents, context is not just helpful, it is _everything_.
- Developers are historically allergic to context. We want to skip the ticket and jump to the code.
- That habit is now actively expensive.
- Clear writing is fast implementation. Fuzzy writing creates hallucinations, bugs, and rework, and wastes time.
- If you get good at writing for agents, you automatically get better at writing for humans. Your teammates have been asking for this for years anyway - they're gonna love you for it.



## A simple framework for writing to agents (and humans, and future-you)

1. State the problem or goal. What is happening? What outcome matters?
2. Provide history. What have you already tried, seen, or ruled out?
3. List constraints. What absolutely must not break?
4. Point to the code. If you were starting, where would you look first? Any past examples or similar patterns?

Go back and re-read your instructions, and imagine this is the first time you're hearing about the bug or feature you're describing. Is there enough information for you to get the job done?

Iterate as needed. That's really all there is to it.

## A real example

I was getting spam signups to the Tiny Improvements mailing list. Dozens a day. Instead of stewing on it internally like I used to, I wrote up this description from my phone while on a plane:

```
I have been getting spam signups on my newsletter form for the past couple weeks - can you read through `SubscriptionForm.tsx` and help me come up with a plan to deter spam signups?

Here are some sample subscriptions from the past few weeks that are all spam:
(list of ~50 spam signups, including the addresses, first and last names used)

Based on what I'm seeing here, I think we can probably do a few things to deter spam signups:
1. make sure the honeypot field on the form is working as expected
2. Automatically reject signups where the first name is mixed case has >3 capital letters: i.e. XavcASkiox
3. Automatically reject signups where the first name has >4 consecutive consonants: i.e. mtpDQVeZaqb

For signups that _fail_ any of our spam checks, we should make it look like the subscription was a success, but don't actually subscribe the email address, and instead log the spam signup attempt to Posthog analytics for further analysis.
```

That 90 seconds of writing turned into a working fix with minimal edits, and thankfully, spam fell off a cliff.

And bonus: writing it down cleared background mental noise I did not realize I was carrying.

## Conclusion

If context is now make-or-break, writing is no longer optional - it's the difference between wasting your time and speeding up your workflow.

Write down what you're thinking about. It frees your brain, helps your team, and makes agents actually useful.

_And if you're the one sending automated spam signups to my newsletter: c'mon, dude._

---

### For more Context on Context

- [Matt Pocock's video on LLM Context](https://youtu.be/-uW5-TaVXu4) is a superb explainer on the topic, with a really helpful series of diagrams to help you visualize the concept.
- Michael Reeves shows what happens when you [corrupt the back-context](https://www.youtube.com/shorts/WP5_XJY_P0Q) of an LLM conversation. It's chaotic - and convincing.


The next great engineering skill is not coding

A simple framework for writing to agents (and humans, and future-you)


## The Big Idea

Software has always required people to think like a computer. AI flips it on its head: people expect computers to work the way they think.

That shift sounds subtle, but it’s massive. It changes what “human-centered design” really means.

## From Rules to Recall

Traditional software is deterministic: repeatable, predictable, safe.
AI is different. It’s non-deterministic - send the same input to your favorite LLM twice, and you'll get different results.

Responses vary: sometimes it feels human, sometimes it feels flat wrong.

That unpredictability makes trust fragile. But it also makes experiences feel alive -- and perhaps counterintuitively, more trustworthy.

## Memory changes everything

Think about how different this is from your experience with traditional software: LLM-powered apps let you have a custom, differentiated experience every time you use them. Your chat session today is _shaped by_ your previous conversations.

Made an update to your profile? AI can suggest how to automate or change your work  next based on your new information.

Suddenly, Gmail and Google Docs _know about each other_, and can suggest helpful actions based on your work across both.

Screens don’t sit still anymore. They grow, adapt, and remember.

## Hybrid Intelligence

People who use software to get complex work done have traditionally needed to build mastery of their tools through repetition. There are _countless_ tutorials on how to use Photoshop to do hyper-specific tasks, because Photoshop is an app that has an incredibly broad set of features, a steep learning curve, and requires deliberate practice to master.

The curve was steep, but the payoff was control and precision.

In a world where AI is the interface, that mastery is _far_ less important.

Now, new users can pull up photoshop with literally no idea of how to accomplish their goal, other than to describe the outcome. That's enough for an agent to take a swing at the task, and often get it right. When it doesn't, the user can course-correct with more natural language.

That's pretty wild - and about as far from the goals of "traditional" UX as you can get.

For novices, it's liberating, but it means AI holds more knowledge of your past than you do.

## UX’s New Job

Design used to be about helping people find the right button. UX Practitioners labor endlessly over trying to make _your next step_ obvious.

I think that's going to fundamentally change.

For AI-powered work, design work needs to focus primarily on::
- Getting work done confidently
- Validating results users may not fully understand
- Making like the system feel like a partner, not a puzzle

Human-centered design has to evolve.

## What’s next?

Autocomplete is already table stakes. Some apps already _feel_ old without it. However, thoughtlessly slapping an AI layer onto a tired interface is worse - it feels cheap.

Here's where I think we're headed:

Conversational interfaces that actually work will be the norm for most workflows. Multimodal (voice + typing + camera) input will become far more common.

Work will regularly involve conversation and collaboration with multiple agents, fine tuned to perform specific tasks in concert with one-another.

User Interfaces will evolve beyond chat-with-an-llm-flavored UX: agents building compact, atomic, and situational UIs on the fly. For example: Want to update your bio? Here's a tiny form with _just_ what you need - nothing superfluous or distracting.

When that happens, we’ll need something like a UX-lint for AI-built experiences. Guardrails for design itself, so that AI-generated UIs look consistent, feel familiar, and don't break the fundamental rules of usability.

## What it means for Product Builders

👉 I’m not certain where this ends up, But I do know this: the products that win will be the ones that anticipate this new language of human-centered design, where AI, memory, and trust define the experience.


AI and the New Language of Human-Centered Design



## The Big Idea
Good design is universal - no matter what you're building.

## Back to Basics

Dieter Rams is the legendary German industrial designer behind Braun’s iconic products from 1955 to 1997(!). His career was built around designing physical objects, from furniture to shelving to hifi systems.

Rams' designs are iconic for a reason: he had a deliberate, principled approach to building products that worked and felt good, which he eventually codified into the [Principles of Good Design](https://en.wikipedia.org/wiki/Dieter_Rams#Ten_Principles_of_Good_design).

1. Good design is innovative
2. Good design makes a product useful
3. Good design is aesthetic
4. Good design makes a product understandable
5. Good design is unobtrusive
6. Good design is honest
7. Good design is long-lasting
8. Good design is thorough down to the last detail
9. Good design is environmentally friendly
10. Good design is as little design as possible

The principles _themselves_ are written with a focus on simplicity and clarity: winnowed down to _exactly_ the essential elements of good design.

These weren’t written with Figma or React in mind. But when you’re building software, especially products people spend hours in every day, it turns out physical object rules apply just fine.

There is a reason we talk about these principles, even 60 years later. They are mantras for building products that work well, feel good, and stick around.


### Balancing the Principles

Apple has historically been the poster child for Rams-style design. Some of their most successul products have had hallmark features of Rams' principles. The original iPod takes much of its physical design from the Braun T3, a transistor radio made in 1958.

<Image
  publicId="newsletters/dieter-rams-10-principles-of-design/comparison"
  alt="Braun's T3 from 1958 looks a whole lot like the original iPod, or is it the other way around?"
/>

It's fair to say that Apple has earned their reputation for great design.

But the new direction in iOS 26 feels... different.

The new _Liquid Glass_ aesthetic looks fresh, futuristic, and bold. But it also cranks the aesthetic dial to 11 and turns everything else down. It's pretty, but at the expense of clarity.

At the IOS26 launch, apple execs praised the new design for putting _content_ at the center of the IOS. In practice, the interface draws attention to itself. Shiny, translucent buttons and frosted glass backgrounds make everything a little more difficult to focus on, and a little more distracting.

<Image
  publicId="newsletters/dieter-rams-10-principles-of-design/liquid-glass"
  alt="Screenshot of iOS 26"
/>

<span className="text-sm italic">From <a href="https://www.apple.com/newsroom/2025/06/apple-introduces-a-delightful-and-elegant-new-software-design/" target="_blank" rel="noopener noreferrer">Apple's Press Release</a> on their new design system</span>

It was so distracting that during the beta period after the announcment of the new design language, Apple [pulled back dramatically](https://9to5mac.com/2025/07/07/liquid-glass-in-ios-26-beta-3-is-much-less-dramatic-as-apple-optimizes-redesign-for-usability/) on the amount of glassy translucent elements in the interface (a great decision, in my opinion).

Even still, it’s a design that feels like it was made to impress other designers. Not to help people get things done. The new design is bold, but it’s not particularly useful. It’s aesthetic, but not unobtrusive.

And that’s the real test:
When the design is working, people don’t notice it.
When it’s not, they notice everything.

### Balance is a continuous practice

It's unlikely that Apple set out to make a less usable product. More likely, they got caught up in the excitement of a new design language and pushed it too far. In recent years, their executive suite has shifted away from product-focused, design-minded leaders -- which can be felt in moments like this.

Design work is a continuous practice of balancing the principles. It’s easy to get caught up in one aspect of design (aesthetics, innovation, etc) and lose sight of the whole.

When I reflect on products that get out of the way and let me do my work, I can see Rams' principles at play. Products like:

- [Superhuman](https://superhuman.com/ti): a beautifully designed email client that focuses on speed and clarity. _(transparency note: Superhuman is a past sponsor of Tiny Improvements)_
- [LogSeq](https://logseq.com/): a note-taking app where taking notes is the focus, rather than _organizing_ notes.
- [VS Code](https://code.visualstudio.com/): An IDE that strikes a balance between speed, usability, and extensiveness, that grows with developers as they become more sophisticated.

## In Summary

The Principles of Design still hold up, even in a world of hover states, folding screens, and haptic feedback. The tools change, but the job doesn’t: design should serve the person using it. Not impress the person who made it.

So the next time you're building something new, ask yourself:
Am I adding more design?
Or am I adding more clarity?

Rams designed with clarity. Restraint. Respect for the person using the product.

So should we.


Dieter Rams 10 Principles of Design


## The Big Idea

Design success is measured in signals that show whether people actually achieved what they came to do.

## Clicks Aren't the Problem

When it comes to design success, clicks aren't the problem - they're just a symptom you'll hear about when people are frustrated.

Last time I argued that [“too many clicks” isn't useful feedback](https://mikebifulco.com/newsletter/stop-counting-clicks).

When something works, people finish tasks, move forward, and feel confident doing their work.

When things aren't working and people are really frustrated, you'll _hear_ about it through the feedback mechanisms you make available to your end users.

There is also a meaningful gap between these two camps: when workflows are merely good enough, people won’t complain, but they also won’t thrive. This silent middle ground is where design stagnates, and where you lose the opportunity to turn reluctant users into superfans.

The opportunity for design teams is to improve user experience by collecting data, feedback, and listening to signals that can help you make your designs better.

So, what is a the right signal that your designs are working?

Here's the catch: **there's no universal checklist.**

What you measure should depend on the purpose of the feature you're building. Clearly defining success metrics and goals will help you decide what signals to measure.

## All Design Leaves Evidence

Good, bad, or otherwise, the output of your design creates signals that you can observe, quantitatively measure, and qualitatively assess in order to improved your feature on its next iteration.

A signup form, a payroll system, and a paint-color selector each have different definitions of success. You can't copy-paste metrics across projects. What matters is asking, up front: what does success look like here?

If your goal is to get high-intent leads to convert to sales, you'll likely want to measure dropoff at each step of your funnel. Make changes to your design to improve the conversion rate at each step, **and** iterate based on what you measure.

Maybe you're designing for a scenario where accuracy is paramount - like in many mechanical engineering or medical design scenarios. In this case, success might be measured by how many incorrect entries are submitted into your system.

Maybe it's speed. Maybe it's accuracy. Maybe it's trust. Whatever it is, define it clearly. Once you do, your metrics stop being vanity numbers and start being a compass. They help you see if you're heading the right way, or if it's time to adjust course.

Iteration without evidence is just guesswork. Iteration with the right signals is how you build something people actually love to use.

## The Takeaway

Don't count clicks. Decide what success means for _this_ design, then measure and observe the signals that point you toward it, and iterate from there.

---

## More on measuring design success

- While not _directly_ about design, Scott Belsky's [The Messy Middle](https://hardcover.app/books/the-messy-middle) reflects on the challenges of getting through the most ambiguous parts of any project.
- Dan Mall has a great video on [Measuring Quality in Design Systems](https://www.youtube.com/watch?v=FJ2ppNwT6Ts)
- I'm a big fan of (previous Tiny Improvement Sponsor) PostHog because they offer tools to make your product better with a massively generous free tier. Check out their [Complete Guide to Event Tracking](https://posthog.com/tutorials/event-tracking-guide) to see how you can track events and metrics in your product in a snap.


Beyond Click Counts: Finding the Right Signals for Good Design


## The Big Idea

**"Too many clicks" isn’t the problem.** It's a _signal_ that your design isn't getting the job done. Clarity, confidence, and cognitive load are the real culprits.

Your users won't notice steps they're taking if each one is obvious and friction-free. They **do** notice when they’re lost, frustrated, or overwhelmed.

## Listen to what they mean, not what they say

**“This takes too many clicks.”**

If you build software long enough, you’ll hear this from someone.

At face value, it sounds like helpful feedback. It often comes from people who aren't software designers. They may not be able to recognize and express their real frustrations with what you've built.

Thankfully, you're here to help! It's _your job_ to respond with curiosity and empathy, and figure out what they're really trying to tell you.

"Too many clicks" is a signal that your users are feeling frustrated. It typically means something like **I can't figure out how to do what I need to do.**

When you hear "too many clicks" from one of your users or constituents, don't stop there - take the time to figure out what they're really trying to tell you.


### Why Click-Counting Fails

You may have heard of the "3-Click Rule" - this is the idea that users should be able to find what they need to do in 3 clicks.

It's a notion that has stuck around for ages. It's simple, easy to remember, and easy to test.

But here's the thing: counting clicks **sucks** as a usability metric.

I'm not making this up. UX research groups far and wide have debunked this idea over and over again, including the legendary [Nielsen Norman Group](https://www.nngroup.com/articles/3-click-rule/) and [Centre Centre](https://articles.centercentre.com/three_click_rule/).

**Clicks are scapegoats.** People only notice them when they’re frustrated.

### The Real Culprit: Cognitive Load

The people using your app pay a small mental tax for everything they do while using your software.

However, not all all actions are created equally:

- Clicking is a *motor load* - the physical effort required to move a finger or cursor to a place and click is tiny.
- Scanning and reading what's the page is a **visual load** - reading isn't free, after all
- Deciding, remembering, or scanning a page to figure out what to do _is_ a big tax. That’s *cognitive load* - and it's much more expensive to your users.

<Image
  publicId="newsletters/stop-counting-clicks/cognitive-load"
  alt="There are different costs to the work your users are doing."
/>

If you shave clicks but make people think harder, you’ve made things worse. Just as well, if you need to collet 20 fields from your users, one great big form may feel more daunting than a stepper with a handful of steps and clear indications of progress.

### Better than counting clicks

Instead of obsessing over steps, measure what matters:

- **Task success:** Do people finish the job they set out to do?
- **Time on task:** Do they move through in a reasonable amount of time?
- **Error/backtracks:** Are they doing a lot of scrolling around or navigating to find what they need?
- **Satisfaction:** When all is said and done, do they feel like their work was easy?

These are meaningful measures of usability, and they get to the heart of what people are _feeling_ while they use your apps.

### What you should look for instead

When someone says “too many clicks,” dig a little deeper, and interrogate what’s really going on.

Here are some common reasons people feel like they’re clicking too much:

- The flow doesn’t match their mental model
- Labels are unclear
- Nav hierarchy is confusing
- They’re not confident in what the right next step is

Your job isn’t to delete clicks. It’s to **fix the underlying friction**.

So - stop counting clicks to fix your design, and instead, **focus on the overall experience.**

If a flow is clear, users won’t care how many taps it took. If your design is really successful, people won't notice that you did anything for them at all.

<Image
  publicId="newsletters/stop-counting-clicks/anything-at-all"
  alt="If your design is really successful, people won't notice that you did anything for them at all."
/>

---

## Don't take my word for it

There are plenty of reputable sources documenting why click counting should never be your goal. If you're looking for some more reading on the topic, check these out:

- [Nielsen Norman Group: The 3-Click Rule is False](https://www.nngroup.com/articles/three-click-rule-myth/)
- [Centre Centre: The Myth of the 3-Click Rule](https://articles.centercentre.com/three_click_rule/)
- [Indeed Design: Breaking the Myth of Big Click Energy](https://blog.indeed.com/design/breaking-the-myth-of-big-click-energy)
- [Stephanie Fox UX: The Myth of Too Many Clicks](https://stephaniefox.ca/ux-blog/too-many-clicks)
- [Web Accessibility Initiative: Tips for designing Multi-Page Forms](https://www.w3.org/WAI/tutorials/forms/multi-page/#:~:text=Where%20possible%2C%20divide%20long%20forms,who%20have%20various%20cognitive%20disabilities)


Stop Counting Clicks

Listen to what they mean, not what they say


## The Big Idea
By using a bit of math called the **optimal stopping problem**, you’ll learn exactly when to stop second-guessing yourself, and start making confident decisions, whether you’re choosing features, hiring teammates, or testing new ideas.

## Two simple rules for decision making

The **optimal stopping problem** comes from probability and decision theory. It describes how find the balance between time and quality when searching for the best option in a given set. The math behind optimal stopping is fairly complex, but the rules are simple.

For our purposes, we can use two simple rules to guide decision making:

- **Rule 1**: If you **know how many options you have**, use the first 37% of them to get a sense of the quality of your options, then choose the next item that is better than all of the previous items.
- **Rule 2**: If you **don't know how many options you have**, use the square root of the number of options you have seen so far to guide your decision.

These two rules give you a surprisingly effective way to stop overthinking and start **acting**.

## Applied science: hiring engineers

Hiring software engineers is always tricky: posting a job opening online results in a flood of applications, and you're left with the difficult task of sifting through them to find the best fit.

In practice, everyone you interview will _also_ be interviewing with other companies. This means you can't keep applicants waiting around while you interview everyone who applies. Sit on a good candidate for too long, and they'll be snapped up by another company.

It's a problem that is perfect for the 37% rule.

If you post a job and get 20 applicants in the first day, you can plan ahead. That’s where the 37% rule works best: interview the first 7 candidates just to set the bar, then hire the next person who’s better than everyone you’ve seen so far.

If you're hiring on a rolling basis, you don't know how many candidates will apply, the √N rule helps. Say you’ve looked at 16 resumes so far, that’s √16 = 4. Once you’ve seen four solid benchmarks, you’re ready to grab the next standout.

## Applied science: Influencer and Partner Outreach
Marketing often comes down to people. You might have a long list of influencers, [newsletter authors](https://mikebifulco.com/sponsor), or potential partners you want to reach out to for an ad partnership - but when do you stop searching for more and commit to building a relationship?

If you know the list size in advance (say 30 people), use the **37% rule**: spend time with the first 11 to understand what quality looks like, then commit to the next standout who outshines the rest.

If your outreach is open-ended and you don’t know how many conversations you’ll have, use the **√N rule** instead. After you’ve talked to 16, that’s √16 = 4. Once you’ve met those first four, you’re in a strong position to recognize and act on the next really promising relationship.

"Perfect" partners for influencer marketing don’t exist. Better to stop searching, commit, and grow the relationship once you've found a good fit.

## Conclusion
This is definitely a _don't take my word for it_ kind of thing - variations of the optimal stopping problem are used all over the place: from options trading, to finding your next high-paying job, this exact kind of logic has been used to make smarter decisions without the analysis paralysis.

So if they can do it, you can too.

## Further reading

If this idea hooked you, there is _loads_ more to learn. I'd recommend starting with these:

- The wikipedia article on [Optimal Stopping Problem](https://en.wikipedia.org/wiki/Optimal_stopping) has a handful of great examples of optimal stopping in action, and links to deeper mathematics from a variety of fields, including computer science, economics, and finance. Definitely worth a dive.

- As you might expect, the Numberphile YouTube channel has a great video on this topic: The [Mathematical Way to Choose a Toilet](https://www.youtube.com/watch?v=ZWib5olGbQ0).


Founder Math: When to Stop Searching and Start Choosing with the 37% Rule

Applied science: Influencer and Partner Outreach


My first product launch was a disaster. I had spent the better part of a year building smpl with my two cofounders; our MVP worked great, we were using it to manage our own business, and on launch day... crickets.

Thousands of lines of code, months of effort, and a beautiful marketing site. We had decided to keep smpl a secret _until it [was] ✌🏾ready✌🏾.

**Our critical launch mistake: nobody knew the damn product existed!**

In the end, smpl was a success story, but it was a success story that could have had a dramatically different trajectory.

## Trust is the hardest thing to build

When you're starting a new product or company, drumming up interest with an audience of potential customers is a critical ingredient to success. When it works, it starts with authenticity; by showing up in the places where your customers are, and becoming a trusted voice in the community.

Bar none, the single most common reason for a fumbled launch is a failure to earn the trust of the people who are supposed to use your product.

There are no shortcuts to earning trust. As a founder and a builder, this comes down to **signal** - how are you substantively showing the world that you care about the product space, that you've built a product worth using, and even more importantly -- one that's worth paying for?

### Listen first, then build

The first part of building your signal is simple: immerse yourself in the world of the people you want to serve. Listen to them, _empathize_ with their problems, and become an enthusiastic part of their community.

Go where your audience is: if they're on reddit, join the subreddit. Subscribe to relevant creators on YouTube and TikTok, and watch as many of their videos as you can. Get the newsletters, read the books, go to meetups. Do whatever you can to **be a part of the community**.

In the earliest stages of product development, you should be listening more than anything. Ask questions, and listen to the answers, and decide on a product direction based on what you're observing, not on what you thought you knew all along.

Perhaps most importantly: becoming a regular in the places where you're building your market is how you become trusted by the community. It is _really_ difficult to just show up and start selling; you have to be a part of the community first.

### Ship early, ship ugly

Once you're building, ship often, and share updates with your target audience. Don't get hung up on perfection here -- share what's new and what's working well _as well as_ the things that aren't working.

It's okay to be wrong - and probably a good thing at this stage. Features that hit the cutting room floor are ones that you can learn from, and your customers will appreciate your honesty.

Because you did your homework in the first step, you should already know where your audience goes to talk about your niche. That's great news! Share your work there, with vulnerability and honesty.

You'd be surprised how much value you can get from sharing your work in this way. Something along the lines of "Hey, I just built this tool because I was frustrated with XYZ. Does anyone else find this useful?" can be a great way to get the ball rolling. This is a great time to offer free access to your product, and get feedback from die-hards in your target audience.

### The big reveal is the path to failure

Let's all say it together: [Nobody wants The Big Reveal™️](https://mikebifulco.com/newsletter/nobody-wants-a-big-reveal). Keeping your work secret is a surefire way to launch a product that nobody wants to an empty room.

### Authenticity and the trust economy

You'll do best when the work you share comes from your heart - and not from a hastily written ChatGPT prompt. That's not to say that you should _never_ use LLMs to help you communicate, but people will be able to tell when they're being **generated-at** rather than **spoken-to**.

These signals are getting more difficult to spot; trust is harder to earn in a world where people can fake the signs of passion and success. You've probably seen headlines recently about [Soham Parekh](https://techcrunch.com/2025/07/03/who-is-soham-parekh-the-serial-moonlighter-silicon-valley-startups-cant-stop-hiring/), a talented engineer who has been working for multiple startups at the same time.

It takes less effort than ever for someone to _appear_ productive, successful, and visionary. Everything is getting wrapped in a glossy layer of AI-powered "productivity"; work is being churned out of LLMs at a pace that's hard to keep up with.

What you can't fake is results, authenticity, and the ability to deliver. Show up and _be human,_ and you'll find the right people to build for.

### Prove that your work can be trusted

The most fundamentally helpful thing you can do is build a product that has real value. All of the steps you've taken to this point should help here: you've embedded yourself with your audience, built a product that you've gone _super deep on_, and shown the world that you can deliver.

Now you've got to keep the momentum going. Product development is a marathon, and when done right, it's also a [virtuous cycle](https://mikebifulco.com/newsletter/eraser-or-wrecking-ball).

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

Each iteration of your work should make the product a little more refined, and more valuable to your target audience.

---

## My favorite book for audience building

Not sponsored, I'm just a bit of an Arvid Kahl stan: His book [The Embedded Entrepreneur](https://www.theembeddedentrepreneur.com/?utm_source=mikebifulco.com&utm_medium=newsletter&utm_campaign=product-is-a-signal) is a must-read for anyone who's trying to build a product.

It _fundamentally_ changed the way I think about building products. Don't miss it.


You Built It. They Didn’t Come.


## The Big idea

Your Computer Science Degree, MBA, or Law Degree is a great thing, but don't get it twisted: history-making innovations come from all areas of study.

## Public Education: Are we really debating this?

Right now, quite a bit of energy is being spent on dismantling the United States public education system. In a word, this is absolutely _baffling_ to me.

There is a ixation on cost-cutting, privatization, and the profitability of any field of study. In 2019 (the most recent dates for which I was able to find reliable data), the average income for someone with a bachelor's degree in a STEM field was $78k USD, vs $53k for someone with a bachelor's degree in a non-STEM field. (source: [National Science Board](https://ncses.nsf.gov/pubs/nsb20212/stem-labor-market-conditions-and-the-economy)).

<Image
  publicId="newsletters/public-education-and-the-value-of-collaboration/chart"
  alt="Median Salaries by workforce and education level: 2019"
  caption="Source: National Science Board"
/>

No doubt that gap has widened by 2025 - if you're motivated by earnings, studying STEM is a smart bet.

The wage gap between STEM and non-STEM fields drives high school graduates away from arts, humanities, and social sciences. Does that mean that the work of artists, writers, and social scientists is worthless?

If you think we should be axing arts, humanities, and social sciences, **you've lost the plot.**

## Huge changes from unexpected places

Among many things that get lost in this debate, I'm concerned that we're losing sight of the fact that education is not just about getting a job. Education, research, and the arts are all about _creating a better future_.

Many innovations that have shifted the course of history have come from unexpected and unlikely places.

As a builder, I find this inspiring - change comes from unexpected places, and passionate, intelligent people from all walks of life are the ones who make it happen.

### The birth of modern urbanism

[Jane Jacobs](https://en.wikipedia.org/wiki/Jane_Jacobs) was an american journalist and author who became the most influential urbanist of the 20th century. Her ideas on urban planning and architecture were groundbreaking, and her work on the book _The Death and Life of Great American Cities_ is a classic. Her influence has shaped the way cities all around the world are built, and her work is still cited today.

### Sci-fi writers influence the future

It is easy to forget how much Science Fiction has influenced the world around us. Martin Cooper, the creator of the first mobile phone, [credits Star Trek as inspiration](https://content.time.com/time/specials/2007/article/0,28804,1677329_1677708_1677825,00.html) for the invention. Ever watch an episode of the Jetsons? A fun kids show from 1962 that imagined a world with self-driving cars, doors that open and close automatically, and robot butlers. Take that, Boston Dynamics.

These things are _so embedded_ in our culture that it can be difficult to imagine a time without them. Someone, something had to come up with these ideas. The next time you hear someone saying degrees in literature should go the way of the dinosaur, remember that we have writers to thank for these.

### UX and Library Science

My love for design and User Experience has its roots firmly planted in the Dewey Decimal System. [Librarians pioneered the field of Information Architecture](https://www.uxmatters.com/mt/archives/2012/11/information-architectures-two-schools-of-thought.php) - organizing and labeling information in a way that is easy to find and use. This was the seed that blossomed into the field of User Experience.

## So then: Invest

The examples above: from urban planning and the built environment, to space-age tech to UX itself underscore a common theme: breakthroughs often emerge when disciplines collide.

Tiny Improvements readers tend to be folks building really interesting things - I don't think I need to persuade you that keeping education alive is a good thing. Keep an ear to the ground for shifting rhetoric around education, and the next time you find yourself talking about it over a coffee or a beer, keep these examples in mind.

It is impossible to tell where world-changing innovations will come from, and "letting the market decide" which types of research and education are worthwhile is a recipe for disaster.

Pursue your interests, foster creativity in your people, and build interesting things -- regardless of where the ideas came from.

_Only my field matters_ is a narrow-minded outlook that not only breeds hubris; it blinds us to game-changing opportunities outside our expertise. Interdisciplinary openness and collaboration isn't just a good idea - it's often _necessary_ to bring us to the next wave of cultural and technological change.


Beyond ✨Shiny✨ Degrees: World-changing innovations from unexpected places

Public Education: Are we really debating this?


## The Big Idea

LLMs and vibe coding tools are most powerful when they're used an an extension of your brain - not a replacement for it. Use your newfound superpowers to make yourself smarter, not just faster.

## What the heck is vibe coding?

_Vibe coding,_ in short, is when someone uses code-trained LLMs to write software, by writing instructions in plain English rather than writing code. Compare this to traditional software engineering, where a disgruntled developer pulls their hair out while yelling at their computer and slamming their hands on the keyboard until things work.

It's a vibe, man.

It's also much faster than traditional software engineering - but can be error prone, and is definitely susceptible to [Dunning-Kruger](https://mikebifulco.com/newsletter/learn-from-a-dunning-kruger-expert) failures.

Understandably, it gets a bad rap, depending on who you ask. With that said, vibe coding tools are _also_ improving at a face-melting pace, and are only going to get better.

## What everyone gets wrong about vibe coding

A lot of people (especially those who are not developers) think vibe coding tools like Cursor, Copilot, and Claude are meant to replace developers. Or, at least, that they write “perfect” code on their own.

They don’t. And they’re not supposed to.

These tools are relentless, energetic, and patient, but they’re not experts. They're more like brilliant interns: fast, eager, and often wrong, despite their endless enthusiasm.

## Tireless, not genius

Cursor, Copilot, and Claude are the most patient pair programmers I’ve ever worked with. They never get tired. They ~never~ rarely complain.

<Image
  publicId="newsletters/what-everyone-gets-wrong-about-vibe-coding/it-did-quit-once"
  alt="Even the robots give up sometimes."
  caption="Even the robots give up from time to time."
/>

Vibe coding tools will happily try something five different ways, rewrite and refactor until we land on something that works. They persevere energetically in times when even the most seasoned engineers might decide to move on to something else.

However: don't mistake their speed and relentlessness for expertise.

My advice is to treat your vibe coding tools like interns: smart, curious, and motivated, but often missing the bigger picture. They need direction. With proper guidance and context, they can be effective problem solvers. They're also damn good at coming up to speed on new frameworks and libraries.

### Vibe coding makes the hard stuff easier

Writing software tests used to be an engineering chore I quietly avoided. I'd lean on my peers to help ensure code was tested thoroughly (have I mentioned how lucky I am to be able to work with people smarter than me?).

A _huge_ benefit of the speed enabled by vibe coding is that it makes writing tests far more satisfying. Any engineer who has been doing the job for long enough can give you a laundry list of anxieties they have about how things can go wrong: timezones make dates a nightmare, off-by-one errors plague everything, and you never know when someone will use an emoji in a place you weren't expecting.

Here's what I love: vibe coding tools make it _way_ easier to write tests. Lots of them. From `minitest` and `rspec` in Rails to `jest`, `playwright`, and `@testing-library/react` in JavaScript projects, I can describe a test in natural language, like “a user shouldn’t be able to create overlapping calendar events,” provide the tool a little bit of context about which files to test, and it'll write the test for me.

### Context and communication is the root of it all

Cursor is my primary IDE at the moment, and I really love their built-in [docs indexing system]. It takes a link to docs for the libraries and frameworks I’m using, and Cursor goes to work indexing them.

In a few moments, Cursor gets up to speed on the tools my team is using. I still have to provide plenty of steering - real-world context is something the robots haven't figure out yet, thankfully.

It's allowed me to grow a skillset that was my weakest after 20+ years of writing code - I'm growing a muscle for writing tests, hardening my apps, and using the incredible frameworks that I never took the time to learn before.

## Learn while you build

Using vibe coding tools is easy. You _can_ generate entire apps without writing a line of code. You _can_ just float on autopilot, and hope it all works out. That's the easy path.

The other path is to treat vibe coding tools like the best interns you've ever had. They'll help you level up _if_ you invest in giving them clear guidance, context, and corrections.

Don’t let these tools make you lazier. Let them make you better.

**That’s the part everyone gets wrong.**

## More reading on vibe coding

- I recently came across [We need to talk about vibe coding](https://dev.to/georgekobaidze/im-all-in-on-ai-but-we-need-to-talk-about-vibe-coding-the-new-slippery-slope-2k6p) from Giorgi Kobaidze. It's a great overview of the current state of vibe coding, and a worthwhile read.


What Everyone Gets Wrong About Vibe Coding

What everyone gets wrong about vibe coding

Context and communication is the root of it all

💌 Tiny Improvements

💌 Read the latest dispatch