A product manager once walked us through a new feature in our weekly review. Twenty slides. Conditional logic. Edge cases. Integration points. I watched people around the table nod along. The CEO asked clarifying questions that somehow made it sound even more complex. Fifteen minutes in, I still had no idea what problem we were solving.

I assumed I’d missed something. Maybe I wasn’t paying attention. Maybe everyone else just got it faster. So I stayed quiet.

Next day after the meeting, I’m on call with engineering lead. He looked exhausted. “Did you understand any of that?” I admitted I didn’t. He laughed. “Neither did I. Neither did anyone in that room.”

We’d all sat there pretending to follow along because we thought everyone else understood. The product manager thought we were all on board.

See, complexity isn’t just a design problem. It’s a courage problem. We keep things complicated because we’re afraid to admit we don’t understand them. And we’re afraid to cut things because removal feels like admitting we were wrong to build them in the first place.

Simple solutions look easy after the fact. The hard part isn’t making it work — it’s deciding what to cut. Complexity is the default. Clarity is the edit.

Why everything starts messy

You don’t wake up one day and decide to build something complicated. It happens gradually. A feature here. An edge case there. A stakeholder request. A “what if” scenario.

New features get added. Old ones stay. Stakeholders contribute ideas, but no one volunteers to kill theirs. “Just in case” thinking accumulates over time until you’re maintaining a system that does everything and solves nothing clearly.

There’s a principle in systems thinking called Gall’s Law:

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.”1

In other words, complexity isn’t a starting point. It’s what happens when you keep adding without ever subtracting.

I’ve seen this pattern repeat across every product I’ve worked on. The first stakeholder meeting generates ideas. The second meeting generates more ideas. By the third meeting, you’ve got a roadmap that would take two years to build and a feature set that would take users three months to learn.

On one project, we started with a dashboard concept. Clean. Three core metrics. One primary action. Then sales wanted to track their pipeline. Customer success wanted support ticket trends. Product wanted feature adoption data. Operations wanted system health monitoring.

Four months later, we had nineteen different widgets, eight filter combinations, and three different chart types. The product team loved it. “Look at all this flexibility users have!”

The support team told a different story. Every onboarding call was forty-five minutes of explaining what everything did. Where to find things. What each filter meant. Which chart to use when.

We’d built a monument to “just in case” thinking. Everyone got their widget. No one got clarity.

The edit is where clarity happens

There’s a quote often attributed to Antoine de Saint-Exupéry:

“Perfection is achieved not when there is nothing more to add, but when there is nothing left to take away.”2

It sounds poetic. It’s actually brutal in practice.

When we finally redesigned that dashboard, we cut fourteen widgets, six filters, and two chart types. The product team panicked. “What if someone needs that?”

Here’s what I learned: the edit isn’t cleanup. It’s not polish. It’s not the final ten percent. The edit is the actual craft.

Every article I write starts at around 3,500 words. I cut it to 2,000. Every wireframe starts with every possible state and interaction. I remove thirty percent before the first review. Every prototype includes features we know we’ll never build, just to see what happens when they’re not there.

Subtraction is where the real decisions happen.

On that dashboard redesign, here’s what we kept:

• Five widgets (down from nineteen)

• Two filter types (down from eight)

• One chart style (down from three)

We made choices. Sales gets pipeline visibility, but not granular deal stage breakdowns. Customer success gets ticket volume trends, but not individual ticket details. Product gets feature adoption, but not user-level data.

Every decision had a reason. Every cut had a trade-off. That’s what made it clear.

The day we launched, support calls dropped by 60%. User satisfaction scores went up. Task completion rates improved. And here’s the part that surprised everyone: not one person asked for the missing features.

Not one.

Why we can’t let go

If subtraction creates clarity, why is it so hard?

Because our brains are wired to avoid loss. Daniel Kahneman’s research on loss aversion shows that losing something feels roughly twice as painful as gaining something feels good.3 When you remove a feature, you feel the loss. When you add a feature, you feel the possibility.

Removal feels like failure. Like admitting you were wrong. Like wasting time and money on something that didn’t matter.

There’s also the sunk cost fallacy.

“We already built it. We already spent the time. We already committed to stakeholders. If we remove it now, all that work was for nothing.”

But here’s the truth: the work wasn’t for nothing. You learned what doesn’t work. That’s not waste. That’s progress.

I once had to defend removing a feature we’d spent 6 weeks building. The meeting lasted two hours. Engineers didn’t want to feel like their work didn’t matter. The product manager didn’t want to go back to stakeholders and explain the change. Leadership didn’t want to admit we’d bet on the wrong thing.

Everyone had a reason to keep it. No one wanted to face the emotional cost of letting it go.

I asked one question:

“If we were starting today, knowing what we know now, would we build this?”

Silence.

The answer was no. We all knew it. But admitting it meant accepting loss. So we’d rather keep something that didn’t work than face the discomfort of cutting it.

There’s also politics. Features have parents. Someone championed that idea. Someone got buy-in. Someone sold it to leadership. Cutting a feature feels like cutting that person’s idea. Like saying they were wrong.

In that same meeting, I watched team members defend features not because they believed in them, but because they’d been the ones to propose them. Ego gets attached. Identity gets wrapped up in decisions. The complexity becomes a monument to who suggested what.

Barry Schwartz wrote about the paradox of choice — how too many options create decision paralysis and decreased satisfaction.4 But the paradox doesn’t just affect users. It affects teams. More features mean more options. More options mean harder decisions. Harder decisions mean we avoid deciding. So we keep everything.

The discipline of deciding what matters

The hardest part of editing isn’t the cutting. It’s deciding what deserves to stay.

Here’s the framework I use:

1. Does this serve the core job? Every product has a primary reason to exist. A core job it does better than anything else. Does this feature support that job, or does it distract from it?

2. Does this create friction or reduce it? Friction isn’t always bad. Sometimes you want users to slow down and think. But most of the time, you want to reduce the distance between intent and action. Does this feature smooth the path or add steps?

3. Would we miss it if it disappeared? The thought experiment that matters most. If we removed this tomorrow, would anyone notice? Would anyone complain? Would anything break? If the answer is no, why are we keeping it?

We used to do an exercise with product teams called “if we could only ship three things.” Lock everyone in a room. No leaving until we agree on the three features that matter most. Everything else gets cut or deferred.

It’s uncomfortable. People fight for their ideas. But by the end, you have clarity. Not because you found the perfect three things, but because you were forced to choose.

On one project, we started with a backlog of 32 features. After three hours of debate, we had our three. Two months later, we shipped those three. The product worked. Users were happy. We never went back to build the other 29.

Not because we forgot. Because they didn’t matter.

What clarity actually looks like

The result of good editing is invisible.

When you use a product that’s been edited well, you don’t notice what’s missing. You notice what works. You don’t think about all the features that aren’t there. You think about how quickly you accomplished what you needed to do.

Dieter Rams said, “Good design is as little design as possible.”5 Not because minimalism is trendy. Because every element you add is a choice you’re asking the user to make. Every feature is a question. Every option is a decision point.

Clarity means fewer questions. Less explanation. Faster onboarding. Lower cognitive burden.

After we redesigned that dashboard, new users could complete their first task without a walkthrough. That was the goal. Not to make it beautiful. Not to make it flexible. To make it obvious.

The interesting part is what happened internally. Engineers spent less time on maintenance. Support spent less time on explanations. Product spent less time on edge case debates. We’d removed complexity from the user experience and accidentally removed it from our own workflows too.

Gloria Mark’s research on attention and cognitive costs shows that every interruption, every decision, every context switch has a cumulative toll.6 We think about users’ cognitive load, but we forget about our own. Complexity doesn’t just burden users. It burdens teams.

When I look at the hours I spent building versus the hours I spent removing, the ratio is embarrassing. Probably 3 hours of building for every hour of editing. But that one hour of editing is where the real value came from.

The builds got us to functional. The edits got us to clear.

The part nobody sees

Here’s what frustrates me about clarity: nobody sees the work.

When you add a feature, people notice. Leadership sees progress. Stakeholders see their requests implemented. Engineers see their code in production. It’s visible. It’s tangible. It’s rewarding.

When you remove a feature, nobody notices. The best outcome is silence. Users don’t miss what they never relied on. Teams don’t celebrate what’s gone. Leadership doesn’t reward subtraction.

But the impact is there. Faster load times. Simpler onboarding. Fewer support tickets. Better user satisfaction. It’s just invisible.

Most products fail not because they’re missing features. They fail because they include too many. Because every addition splits focus. Every option adds cognitive load. Every edge case complicates the core experience.

I worked with a team that had built a scheduling tool. The core job was simple: book a meeting. But over two years, they’d added timezone detection, calendar syncing, reminder customization, buffer time settings, meeting templates, availability rules, booking limits, and custom branding.

By the time I saw it, the average user took 8 clicks to book a single meeting. The product team was proud of how comprehensive it was. Users were exhausted by how much they had to configure.

We cut everything except the core path. Pick a time. Book it. Done. Three clicks.

The team resisted. “But what about power users who need advanced features?” What about them? We looked at the data. 94% percent of bookings used the default settings. 6% of users accounted for 90% percent of the customization requests.

We built for the 6% and made it harder for the 94%.

After we shipped the simplified version, usage went up. Not because we added anything. Because we removed the barriers between intent and action.

Complexity signals effort. It signals sophistication. It signals that you’ve thought of everything.

Clarity signals confidence. It signals that you know what matters and you’re willing to cut everything else.

The uncomfortable truth

Here’s what makes this hard: most careers reward addition, not subtraction.

Promotions come from shipping features. Bonuses come from hitting roadmap goals. Recognition comes from building new things. Nobody gets promoted for removing complexity.

If you’re the person who says “we shouldn’t build this,” you’re the obstacle. If you’re the person who says “let’s cut this,” you’re the critic. If you’re the person who questions whether something is necessary, you’re slowing things down.

That’s the tension. The system rewards complexity even though the outcome demands clarity.

I’ve been in reviews where I presented two options: build three new features or remove five old ones. Leadership picked the first option every time. Not because it was better. Because it felt like progress.

Subtraction doesn’t feel like progress. It feels like going backward.

But here’s what I’ve learned: the courage to say “no” or “not yet” is rarer and more valuable than the ability to say “yes.”

Anyone can add features. It takes no discipline. No judgment. No taste. You just keep building.

Editing requires conviction. You have to believe that less is actually more. That removing something will make the product better. That saying no is a service to users, not a disservice.

And you have to be willing to defend that choice when everyone else wants to keep adding.

The edit never ends

Clarity isn’t a destination. It’s a practice.

Every new feature tempts complexity. Every stakeholder request tests your discipline. Every “what if” scenario threatens to pull you back toward “just in case” thinking.

The question isn’t whether you’ll face pressure to add more. The question is whether you’ll have the systems in place to resist.

• Some teams do quarterly audits. What can we remove this quarter? What have users stopped using? What’s creating more support burden than value?

• Some teams have a rule: for every new feature added, an old one must be deprecated. It forces prioritization. It prevents accumulation.

• Some teams just have one person whose job is to say no. To ask the hard questions. To defend simplicity against the endless tide of addition.

I don’t have a perfect system. But I do have a principle: if you can’t explain why something should stay in 10 seconds — it should probably go.

Not every feature earns its place. Not every option deserves to exist. Not every edge case matters enough to complicate the core.

The edit is not cleanup. The edit is the craft. It’s where you decide what matters. It’s where you choose clarity over comprehensiveness. It’s where you admit that doing less, better, beats doing more, worse.

Simple is hard. That’s why it’s rare. That’s why it matters.

Motivation is loud. Defaults are silent.

Most products don’t succeed because users are motivated. They succeed because the path of least resistance happens to align with the desired behavior. That’s the quiet power of defaults — they require no decision, trigger no friction, and feel “natural” even when they’re engineered.

If a user has to choose the right thing every time, the system has already failed.

Product defaults: designing without asking

In products, defaults answer questions users never explicitly ask:

• Which option is pre-selected?

• What happens if I do nothing?

• What’s one click away versus three?

• What’s visible first and what’s hidden?

These decisions shape outcomes more than features ever could.

Good products don’t rely on user discipline. They rely on default alignment. Bad products assume users will read, configure, remember, and “use it properly.” Great products assume none of that.

Consider organ donation rates across Europe. Austria has a 99.98% consent rate. Germany has 12%. Same continent, similar cultures, identical decade. The difference? Austria uses opt-out as the default. Germany uses opt-in. As behavioral economists Eric Johnson and Daniel Goldstein documented in their 2003 study, “Do Defaults Save Lives?”, this single design decision — what happens when people do nothing—determines whether someone’s organs get donated.

The form itself becomes the outcome.

Gmail’s “Undo Send” feature demonstrates this principle in reverse. For years, people wrote emails they regretted sending. Gmail didn’t try to make users more careful — they redesigned the default. Now, clicking “send” doesn’t actually send. It queues the email with an undo option for five seconds. The user still makes impulsive decisions, but the system creates a buffer between impulse and consequence.

That’s the transfer: products succeed when they design around human nature instead of fighting it.

The transfer: life is also a product

Here’s the uncomfortable part: most people live inside badly designed default systems.

Not because they chose them — but because they never questioned them.

Life defaults look like the people you’re surrounded by. The food in your kitchen. The apps on your home screen. The way your calendar fills up. The distance between you and friction.

Just like products, life outcomes are mostly the result of what happens when you do nothing.

James Clear writes in Atomic Habits that “environment is the invisible hand that shapes human behavior.” He’s describing defaults. When researchers at Cornell studied eating behavior in 2006, they found that people ate 71% more soup when eating from self-refilling bowls. The eaters didn’t feel fuller — they ate until the visual cue (empty bowl) appeared. Remove the default stopping point, and consumption becomes nearly automatic.

Your environment isn’t neutral. It’s a series of pre-made decisions that execute whether you’re paying attention or not.

Most people optimize for the wrong thing. They try to build discipline when they should be building defaults. They work on willpower when they should be working on proximity. They focus on motivation when they should be eliminating choice.

Consider commute distance. If your gym is fifteen minutes out of the way, you’ve designed failure into the system. Not because you’re weak, but because you’ve added three decision points (leave work early, drive past home, choose gym over couch) where each requires active motivation. Put the gym between work and home, and the default path includes the gym. Same person, same goal, different outcome.

Motivation is a terrible interface

Motivation is fragile. It fluctuates, decays, and disappears under stress. Defaults persist.

If a behavior requires motivation, it’s not a system. It’s a gamble.

BJ Fogg, Stanford behavior scientist and author of Tiny Habits, describes motivation as unreliable by design. His Behavior Model (B=MAP) shows that behavior happens when motivation, ability, and prompt converge. Most people try to increase motivation — the most volatile variable. Better designers reduce the ability threshold by making the behavior easier, or they engineer the prompt into the environment.

Examples of no default:

• “I’ll work out if I feel like it”

• “I’ll eat healthy when I’m disciplined”

• “I’ll focus when I have time”

Compare that to:

• Gym on the way home

• No junk food in the house

• Meetings blocked by default

Same person. Different defaults. Different life.

Gloria Mark’s research at UC Irvine found that it takes an average of 23 minutes and 15 seconds to return to a task after an interruption. Most knowledge workers design their days as if interruptions are anomalies. They’re not — they’re the default. Email is open. Slack is active. Notifications are on. The question isn’t whether you’ll get distracted. The question is: have you designed against it?

Designers understand this principle as “removing friction from the happy path.” In life, the same principle applies: if the desired behavior requires clearing obstacles every single time, those obstacles are the system.

Designers understand this — then forget it at home

Product designers know this instinctively at work: reduce friction, set the right defaults, assume user fatigue, design for failure states.

But personally? They rely on willpower.

That’s the paradox: we design systems for others that we refuse to design for ourselves.

A product designer would never build an app that requires ten daily decisions just to start. Yet they design mornings that way — alarm, snooze decision, coffee decision, clothes decision, breakfast decision, commute decision. Each decision depletes what Roy Baumeister termed “ego depletion” in his research on decision fatigue. By the time they arrive at work, they’ve burned cognitive resources on choices that could have been eliminated.

Steve Jobs wore the same outfit daily. Barack Obama reduced his wardrobe to blue or gray suits. Mark Zuckerberg famously said, “I really want to clear my life to make it so that I have to make as few decisions as possible about anything except how to best serve this community.” These aren’t quirks — they’re system designs that recognize decision-making has a cost.

The best product designers treat their own lives like products under development. They A/B test morning routines. They instrument their environments with feedback loops. They remove options that create decision debt.

And yet many designers still assume their personal lives run on motivation while their products run on design.

Taste, ethics and eesponsibility

Defaults are not neutral.

Choosing a default is choosing what’s normal, what’s encouraged, what’s ignored. In products, this is a design responsibility. In life, it’s a moral one.

Your defaults reflect your values more honestly than your intentions.

When Facebook chose to make all new accounts public by default, they weren’t just simplifying onboarding — they were making a statement about privacy. When Slack defaults to open channels instead of private messages, they’re encoding transparency as a cultural value. When Apple’s Screen Time feature defaults to “off,” they’re making a choice about whether digital wellness is opt-in or opt-out.

Tristan Harris, former Google design ethicist and founder of the Center for Humane Technology, argues that “design is not neutral — it’s persuasive by nature.” In his work on The Social Dilemma, Harris explains how defaults like infinite scroll and autoplay weren’t accidents — they were designed to maximize engagement, even when that engagement came at a psychological cost.

The same applies personally. If your default is saying “yes” to every meeting request, you’re encoding a value: other people’s priorities come before your own time. If your default is checking email first thing in the morning, you’re letting other people’s agendas set your day’s emotional tone. If your default social circle emerged from proximity rather than intention, you’ve outsourced one of life’s most important decisions to geography.

According to Jim Rohn’s often-cited principle, “You are the average of the five people you spend the most time with.” Whether that’s empirically precise or not, the underlying truth holds: your defaults compound. The people, places, and patterns that require zero activation energy become your operating system.

The only question that matters

Whether in products or life, the real question is the same: What happens by default if nothing changes?

If you don’t like the answer, don’t try harder — redesign the system.

This isn’t about discipline or willpower or “getting serious.” It’s about recognizing that humans (including me and you) are prediction machines that conserve energy by defaulting to whatever’s easiest. The Stanford psychologist Albert Bandura called this “reciprocal determinism”: environment shapes behavior, but behavior also shapes environment. You’re not trapped by your current defaults, but you also can’t willpower your way past bad ones.

Change the default, change the outcome.

When Dropbox redesigned their product to automatically sync files instead of requiring manual uploads, adoption skyrocketed. Users didn’t become more motivated — the product stopped asking them to be. When meal prep services put healthy food in your fridge, they’re not banking on your discipline — they’re eliminating the decision chain between hunger and nutrition.

The best life design follows the same logic.

• Want to read more? Don’t rely on finding time. Put a book on your pillow every morning.

• Want to eat better? Don’t keep junk food in the house.

• Want to think more clearly? Block the first two hours of your day before anyone else can claim them.

• Want better relationships? Schedule recurring time with the people who matter before urgency fills the calendar.

Defaults don’t guarantee outcomes. But they dramatically shift probabilities in your favor — and over time, probabilities become destiny.

Designing your operating system

Most people inherit their defaults. They live inside systems designed by employers, platforms, and decades-old habits. They optimize for other people’s goals while their own remain aspirational.

Product designers would never ship something so misaligned. They’d call it a critical bug: the system serves the wrong objective function.

Your life has an objective function too. The question is whether you designed it — or whether it designed you.

Motivation is optional. Defaults are not.

Start with one: identify the behavior you most want to change. Then ask not “how do I get motivated?” but “what would need to be true for this to happen by default?” Trace the friction points. Redesign the path. Remove the decision.

You already know how to do this. You do it at work.

Now do it at home.

Further Reading:

• Julian Shapiro’s Growth Marketing Guide

• James Clear, Atomic Habits (2018)

• BJ Fogg, Tiny Habits (2019)

• Tristan Harris, The Social Dilemma

• Eric J. Johnson and Daniel Goldstein, “Do Defaults Save Lives?” Science (2003)

You haven’t seen what your product is capable of yet.

And if you understand how to unlock that potential, you can do what most teams consider impossible.

Unfortunately, most product teams have the idea of improvement completely backward.

They think they need months of development, complete redesigns, and executive buy-in to see any form of progress.

The reality is, you have constraints. I get it. Some of you can’t just halt the roadmap. You may have one designer, limited engineering capacity, an upcoming release. Those things are real. Meaning, you probably have one focused day you can put toward actually fixing what’s broken.

And that’s a great thing, because you can drastically improve your product in 8 hours.

One day of ruthless focus.

One critical decision.

One clear path forward.

The gap isn’t effort — it’s decision quality

Most products aren’t broken. They’re trying to do too many things at once.

You could have the most talented team in the world, but if you’re solving the wrong problem or protecting the wrong assumption, talent doesn’t matter. The code can be pristine. The design can be polished. The metrics can be tracked obsessively. None of it moves the needle if the underlying decision is wrong.

The real constraint isn’t resources. It’s clarity.

Teams spend weeks debating solutions to problems they haven’t properly defined. They add features to compensate for unclear flows. They redesign interfaces to hide structural confusion. All of it feels productive. None of it addresses the core issue.

The core misbelief

Teams believe improvement comes from more features, bigger redesigns, longer roadmaps. This creates motion without progress. Complexity becomes the hiding place for hard decisions you’re avoiding.

You add a filter because you don’t know what matters. You redesign the navigation because you can’t articulate where people should go. You debate edge cases because the core case isn’t clear. You build configurability because you haven’t decided what the right default should be.

Every addition is a symptom of an unmade decision.

And the longer you avoid that decision, the more expensive the product becomes to maintain, the harder it becomes to change, and the further you drift from what actually works.

The constraint reality

You don’t have unlimited time or alignment.

You might have one designer, one sprint, one release window before the next fire starts. You might have a stakeholder who wants results now, a backlog that’s already overcommitted, a team that’s already stretched thin.

That’s not a limitation — it’s leverage.

Because one focused day beats months of scattered iteration.

Most products are held back by one wrong assumption, one broken default, one unclear success definition. Fix that, and everything downstream improves. Leave it unfixed, and every sprint compounds the original mistake.

The teams that move fastest aren’t the ones with the most resources. They’re the ones who know which decision matters most and make it without hesitation.

The reframe: one day is enough

Here’s what changes when you accept the constraint: you stop optimizing for coverage and start optimizing for impact.

No Figma exploration. No stakeholder decks. No “nice to have” debates.

Today is about fixing decisions, not decorating outcomes.

This isn’t a workshop. It’s not collaborative brainstorming. It’s not a design sprint where everyone gets a voice and nothing gets decided. It’s surgical thinking — identifying the one decision that’s holding everything else hostage, then fixing it before the day ends.

You’re not trying to build the perfect product. You’re trying to remove the thing that’s preventing the current product from working.

That’s a completely different problem. And it requires a completely different approach.

The rule of the day

One day. Eight hours. One decision fixed.

No exceptions. No scope creep. No “while we’re at it” additions.

The constraint is what makes this work. Without it, you’ll drift back into the comfortable pattern of discussing everything and deciding nothing. The day forces prioritization. It forces honesty. It forces you to confront the one thing you’ve been avoiding because it felt too hard or too political or too risky.

Today, you fix that thing.

The 1-day product reset framework

Hour 0 — Set the constraint (30 min)

Define the single decision that matters most.

Write: “If we fix only one thing today, it’s ___.”

If this is hard, you’re avoiding the real problem. You’re hedging. You’re trying to fix three things at once because none of them feel big enough to matter. That instinct is wrong.

The whole point is to isolate the leverage point — the one thing that, if corrected, makes ten other problems irrelevant.

This might be a flow that doesn’t work. It might be a default that creates the wrong behavior. It might be an assumption about users that’s no longer true. Whatever it is, it’s the thing that makes you uncomfortable to name out loud.

Name it anyway.

Because if you can’t write it in one sentence, you don’t actually know what you’re fixing. And if you don’t know what you’re fixing, you’re about to waste eight hours making the product more complicated without making it better.

Output: one written constraint.

Hour 1 — Name the real user (45 min)

Not personas. Not future customers. The user the product actually serves today.

Ask:

• Why do they open the product?

• What are they anxious about?

• What outcome creates relief?

Most teams describe users in aspirational language — what they want them to care about. But users don’t care about your vision. They care about their problem. And if you can’t describe that problem in plain language, you’re designing for a ghost.

This isn’t about demographics or job titles. It’s about the moment before they open your product. What failed? What pressure are they under? What happens if this doesn’t work?

Get specific. “Project managers who need to report status” is not specific. “Someone who has a standup in 30 minutes and needs to know if the release is on track” is specific.

The more clearly you can name the anxiety, the more clearly you can design the relief.

Output: one plain-language paragraph.

Hour 2 — Define success (30 min)

Forget dashboards and metrics. Define the moment the user thinks: “Okay, this works.”

Rules:

• It must be observable

• It must happen early

Success isn’t retention or engagement. It’s the first moment of relief. The first time the product does what it promised without the user having to compensate for its shortcomings.

For a task management tool, success isn’t completing a project. It’s the moment they see their tasks organized in a way that makes sense without them having to reorganize it manually.

For a reporting tool, success isn’t generating insights. It’s the moment they see the data they need without having to filter, export, and rebuild it in a spreadsheet.

For a collaboration platform, success isn’t getting the whole team on board. It’s the moment one person gets an answer faster than they would have over email.

That moment — early, observable, relieving — is your success definition. Everything else is a lagging indicator.

Output: one success behavior.

Hour 3 — Trace the critical path (60 min)

One path only. First screen to success moment. No branches, no edge cases.

Every step must move the user forward. If it needs explanation, it’s broken.

This is where most products fall apart. They optimize every screen independently without asking whether the sequence makes sense. A beautiful onboarding flow that doesn’t lead to the right first action is just expensive friction.

Map the path:

• What’s the first thing they see?

• What’s the first thing they need to do?

• What happens after they do it?

• How do they know it worked?

• What’s the logical next step?

Look for gaps. Places where the user has to guess. Places where momentum stops. Places where the product asks for information it should already know or could infer.

Every gap is a decision you avoided making. Every explanation is evidence that the flow doesn’t work. Every optional path is a sign you’re not sure what the user actually needs.

Cut it down to one path. Not the ideal path. Not the power user path. The path that works for someone who just arrived and needs the product to prove itself.

Output: a linear list of steps.

Hour 4 — Kill the biggest lie (45 min)

Every product protects one comforting belief. Find the assumption complexity depends on.

Ask: Which belief, if false, collapses the experience?

Maybe you believe users need flexibility, so you built fifteen configuration options. Maybe you believe users need education, so you front-loaded tutorials. Maybe you believe users need reassurance, so you added confirmation steps everywhere.

What if that belief is wrong?

What if users don’t want flexibility — they want a default that works? What if they don’t want education — they want a product that doesn’t require it? What if they don’t want reassurance — they want confidence that the product won’t let them make a catastrophic mistake in the first place?

The lie isn’t malicious. It’s protective. It’s the story you tell yourself to justify why the product is the way it is. But if the product isn’t working, the story is wrong.

Find it. Write it down. Then cross it out.

Output: one sentence you’re no longer allowed to believe.

Hour 5 — Fix the default (60 min)

Products don’t fail because of features. They fail because of bad defaults.

Look at:

• First screen

• Primary action

• Empty state

• “Next step”

The right action should happen even if the user does nothing clever.

Defaults reveal what you actually believe about your users. If the default requires expertise, you’re designing for experts. If the default requires motivation, you’re designing for the already-convinced. If the default requires guessing, you’re designing for failure.

Most products default to empty states, blank canvases, or configuration screens. All of them push the cognitive load onto the user. All of them make success conditional on the user doing something smart.

That’s backward.

The default should be the thing most users need most of the time. Not the most flexible thing. Not the most powerful thing. The most useful thing.

If your product is a dashboard, the default view should show the most important data, not an empty grid. If your product is a form, the default should pre-fill what you already know. If your product is a workflow tool, the default should be the most common workflow, not a blank template.

Change the default. Watch what happens.

Output: one default decision changed.

Hour 6 — Remove, don’t add (45 min)

Clarity comes from subtraction. Identify what exists only for internal comfort.

Ask: What can be removed today without breaking the product?

Features stick around because someone once cared about them. Options exist because saying no felt risky. Explanations multiply because the underlying flow wasn’t clear.

None of this helps the user. It helps you feel comprehensive.

Go through the critical path you mapped in Hour 3. For every screen, every button, every field, ask: “If this disappeared, would the core path still work?”

If yes, remove it. Not “hide it in settings.” Not “make it optional.” Remove it.

You’re not trying to make the product smaller. You’re trying to make the decision clearer. Every element you remove is one less thing competing for attention, one less place for the user to get stuck, one less point of confusion.

The goal is a product where the right action is obvious because nothing else is in the way.

Output: a removal list.

Hour 7 — Validate with reality (45 min)

No usability theater. Do one:

• Watch a real session

• Hand the product to someone cold

• Re-run the flow yourself after a break

Watch for hesitation, guessing, accidental success.

You’re not testing whether people like it. You’re testing whether the decision you made in Hour 0 actually holds. If the path is still unclear, you fixed the wrong thing.

This isn’t a formal study. It’s a reality check. You need to see whether the thing that felt obvious to you after eight hours of thinking about it is actually obvious to someone who just arrived.

If they hesitate, the design isn’t clear. If they guess, the flow isn’t intuitive. If they succeed by accident, the product is fighting them instead of guiding them.

One session is enough. You’re not gathering statistically significant data. You’re checking whether your logic holds under contact with reality.

If it doesn’t, you have 30 minutes to correct it.

Output: one confirmed insight, one correction.

Hour 8 — Lock the decision (30 min)

Decisions decay if they’re not written.

Document:

• What changed

• Why it changed

• What you’re explicitly not fixing yet

This isn’t documentation for compliance. It’s documentation for memory. Three weeks from now, when someone asks why you removed that feature, you need to remember the decision you made and the reasoning that supported it.

Write it plainly:

• We changed the default from X to Y because users were consistently choosing Y anyway.

• We removed the secondary path because it added complexity without improving outcomes.

• We’re not fixing the admin panel yet because it doesn’t block the core user from succeeding.

The last part matters. You’re going to be tempted to expand scope. Someone’s going to say “while we’re at it, we should also fix…” and if you don’t have a written record of what you’re explicitly not fixing, the focus will dissolve.

Write the decision. Share it. Move on.

Output: a short decision record.

What you end the day with

One corrected default. One clear success definition. One path that actually works. Less product than you started with.

No roadmap. No redesign. Just leverage.

You don’t walk away with a plan to fix everything. You walk away with proof that fixing one thing changes everything else. The team sees it. The user feels it. The metrics reflect it.

And once you’ve done it once, you know how to do it again.

Why this works when other approaches fail

Most improvement efforts fail because they try to fix everything at once.

They launch initiatives. They run workshops. They create alignment decks. They build consensus around a vision that’s too broad to execute and too vague to measure.

This framework works because it does the opposite. It isolates one decision, makes it, and moves on.

The constraint isn’t a limitation. It’s the entire point. Without it, you’d spend the day debating. With it, you spend the day deciding.

And decisions compound. One good decision makes the next one easier. One clear path makes the next feature obvious. One corrected default changes user behavior, which changes what you optimize for next.

You don’t need a year. You don’t need a rebrand. You don’t need executive sponsorship.

You need eight hours and the willingness to fix the thing you’ve been avoiding.

Final reframe

Most teams don’t need more time. They need one day of uncomfortable honesty.

Fix the decision. The product will follow.

One day of ruthless focus.

One critical decision.

One clear path forward.

You haven’t seen what this product is capable of yet. But you will.​​​​​​​​​​​​​​​​

There’s this moment in a career that nobody talks about.

It’s not the beginning when you’re struggling to make anything good. Ira Glass covered that beautifully. And it’s not the middle, when you’re grinding through volume trying to close the gap between what you can make and what you can recognize as good.

It’s what comes after.

You’ve been doing this for 10, 12, 15 years. The work is finally good. You ship things that work. People trust your judgment. Execution isn’t the bottleneck anymore.

And then you notice something strange: the constraints that used to hold you back have mostly disappeared. You can execute almost anything you imagine. You have leverage. You have speed. You have power.

That’s when a different kind of pressure shows up. One nobody warned you about.

Early on, you’re limited by what you can do.

Later, you’re limited by what you’re willing to do.

The gap Ira Glass talks about eventually closes

Ira Glass gave us one of the most honest descriptions of creative development ever recorded. The taste gap – where your ambition outpaces your ability. Where you can recognize good work but can’t make it yet.

He says:

“All of us who do creative work, we get into it because we have good taste. But it’s like there’s this gap. For the first couple years that you’re making stuff, what you’re making isn’t so good. It’s not that great. It’s trying to be good, it has ambition to be good, but it’s not that good.”

And his advice is right:

• Do a huge volume of work

• Put yourself on a deadline

• Fight through it

That phase is real. Most people quit there.

But here’s what Glass doesn’t address: What happens when you stop quitting? What happens when skill finally catches up?

Ira Glass explains why beginners suffer.

He doesn’t explain what happens when they stop.

What changes when skill arrives

When skill matures, the world opens up. You can execute almost anything you imagine. Constraints loosen. What used to take weeks takes days. The voice in your head that said “I can’t make this work” gets quieter.

New realities emerge.

You’re asked to ship faster – because you can. You’re rewarded for results, not judgment. You’re trusted to “figure it out” without much oversight.

Senior designers aren’t blocked by how to do something. They’re deciding whether.

And that’s where it gets interesting. Because skill doesn’t just remove friction. It creates opportunity. The opportunity to take shortcuts. The opportunity to ship something that works but doesn’t sit right. The opportunity to build things you know you’ll regret – but nobody will ever trace back to you.

Skill removes friction. It doesn’t remove responsibility.

Taste after competence

In the beginning, taste is diagnostic. It tells you what’s wrong with your work before you can fix it. That’s the gap.

After competence, taste becomes something else. It becomes directional. Taste is what tells you when something is possible – but shouldn’t be done.

I’ve felt this dozens of times working on enterprise platforms. You know the solution would “work.” It would ship. It would pass review. The metrics would move in the right direction. And yet. Something doesn’t sit right. The experience feels thin. The system loses coherence. You’re offloading complexity onto users instead of absorbing it yourself.

You could build it. Nobody would stop you. Most wouldn’t even notice.

But taste notices.

Taste shows up as discomfort with shortcuts. Resistance to “good enough.” A gnawing awareness of second-order effects that won’t surface for months.

It’s not perfectionism. Perfectionism is about polish. Taste is about structure. About trade-offs you can feel but can’t always articulate.

When you’re junior, taste makes you frustrated with your own work. When you’re senior, taste makes you cautious with your own power.

Silicon Valley as a case study

There’s a piece from Working Theory called “Taste Is Eating Silicon Valley” that names something important: taste can be eroded by systems that don’t reward it.

The argument goes like this:

When speed, scale, and growth are the only metrics that matter, taste slowly atrophies.

What once felt wrong becomes “industry standard.” Engineers optimize for what’s measured. Designers ship what gets approved.

The incentives retrain your judgment.

I’ve watched this happen. Worked in environments where the feedback loop was so tight on shipping that anything beyond “does it function” felt like a luxury. After a while, you stop noticing the patterns you’re normalizing.

This is the real danger of skill without taste: you have the capability to move fast, build at scale, and ship constantly – but nothing internal is slowing you down.

When skill outpaces taste, power drifts toward exploitation.

Not because anyone becomes evil. But because systems reward outcomes without evaluating judgment. And skill, amplified by incentive, becomes a force multiplier for whatever you point it at.

Taste is the only counterweight.

Where taste actually lives in product design

Let me be concrete about what taste looks like in practice. Because it’s easy to make this abstract.

• Taste is choosing boring clarity over clever complexity

• It’s killing a feature that tests well in research but you know will age badly

• It’s naming things carefully, even when nobody’s watching

• It’s refusing dark patterns even when the metrics reward them

• It’s designing systems that explain themselves, so users don’t have to ask

Important distinction here: taste is not visual polish. A product can be beautifully designed and still have no taste. Taste is structural judgment.

Good taste in product design is the refusal to offload complexity onto users.

It’s absorbing the hard work yourself so the experience feels effortless for them. It’s knowing that speed isn’t just shipping. It’s maintaining what you shipped. It’s understanding that the best systems are the ones you don’t have to fix in six months.

Why skill alone isn’t a safeguard

There’s research showing that power reduces empathy.1 The more capability you have, the less likely you are to consider the perspective of those affected by your decisions. It’s not malice. It’s distance.

Skill creates that distance.

When you can ship anything, you become detached from the cost of shipping poorly. The feedback loops lengthen. The consequences become someone else’s problem.

Meanwhile, incentive systems reward output, not judgment. People optimize for what’s measured. Measured long enough, the optimization becomes invisible.

The problem isn’t bad people.

It’s systems that reward outcomes without judgment.

Skill doesn’t protect you from this. It amplifies it.

How taste develops

I’m not going to give you tips on “building taste.” That’s not how it works.

But I can tell you what I’ve observed about when taste sharpens – mostly by looking backward at my own work.

Taste develops through exposure to consequences.

Not hypothetical consequences. Real ones. Living with systems you built. Returning to projects a year later and feeling the weight of decisions you barely remember making.

I’ve gone back to work from five years ago and immediately known: that was a shortcut. I can see it now. I couldn’t see it then.

Taste sharpens through long feedback loops.

Not A/B tests that resolve in a week. But products that have to evolve over years. Teams that have to maintain what you created. Users who live inside your decisions daily.

When you stick around long enough, you start to feel what lasts.

Taste comes from having to live inside what you’ve made.

If you only ever ship and move on, taste stays theoretical. It’s the return trip that teaches you.

Skill gives you power. Taste decides who you become.

Skill determines what you can do. How far you can reach. What problems you can solve.

Taste determines what kind of builder you are.

What you normalize. What you refuse. Whether you absorb complexity or push it downstream.

The most dangerous moment in a career is when nothing stops you.

When you have the skill to build anything, the leverage to move fast, and the incentives pushing you to ship – that’s when taste matters most.

Because nobody’s going to audit your decisions for long-term coherence. No one will ask if this feature made the system better or just bigger. The metrics don’t capture whether users trust the experience or just tolerate it.

You’re the only one who knows.

The mature form of the taste gap

Ira Glass described the first gap: taste that exceeds skill. That gap hurts because you can’t meet your own standards. There’s a second gap. One that comes later.

Taste that exceeds incentive. This gap hurts because you can ignore your standards. Because the work would ship anyway. Because nobody’s stopping you.

Early career: taste hurts because you can’t meet it. Later career: taste hurts because you can ignore it.

The junior version is frustrating. The senior version is uncomfortable in a different way. It asks you to choose slower when faster is rewarded. To say no when yes is easier. To build less than you’re capable of because less is actually more.

Skill opens doors.

Taste decides which ones you walk through.

And which ones you quietly close behind you.

There’s a specific kind of frustration that nobody talks about.

Months of work. Real work. The kind that matters. And nothing to show for it. No screenshots worth sharing. No before-and-after to post. Just a feeling that something’s finally starting to click, but you couldn’t explain what if you had to.

Meanwhile, someone asks: “What are you working on?”

And you realize you don’t have a good answer.

This is the paradox at the center of anything worth building: the better the system, the worse it feels while you’re making it. The better it works, the less anyone notices.

I’ve spent fifteen years building products for Fortune 500 companies. The projects that shipped fastest almost always created the most problems. The ones that felt endless during development? Those are the ones people still use without thinking about.

Speed is what users experience. Slowness is what builders endure.

And the gap between those two things is where most of the real work happens.

Why "fast to build" is a red flag

There’s a reason startups obsess over velocity. Shipping feels like progress. Deployment creates dopamine. Every feature that goes live is proof you’re not just thinking – you’re doing.

But here’s what I’ve learned watching products grow (and break) over 15 years: fast builds optimize for visible output, not structural integrity. They prioritize shipping over coherence.

When teams move fast, they avoid answering hard questions. Questions like:

• Does this mental model actually match how users think?

• Will this pattern scale when we’re not the only ones touching it?

• Are we building something that explains itself, or something that requires explanation?

Speed masks uncertainty. And uncertainty doesn’t disappear – it just moves downstream.

Systems built quickly tend to externalize their complexity onto users. You see it everywhere: documentation that exists because the interface doesn’t make sense. Support tickets that wouldn’t exist if someone had taken two extra days to think through edge cases. Training videos for features that should’ve been obvious.

At one enterprise client – Fortune 500, huge eng team, aggressive timelines – we shipped a dashboard in eight weeks. Stakeholders were thrilled. Then we spent the next eighteen months explaining how to use it. Every month, another training session. Every quarter, another round of usability improvements that were really just attempts to fix what we’d broken by rushing.

Speed compounds into fragility, not leverage. The debt always comes due.

The invisible work that makes products feel effortless

The best product I’ve ever helped build took almost twice as long as anyone expected. For months, we weren’t designing screens. We were arguing about words.

• What do we call this thing?

• Does “workspace” imply collaboration, or isolation?

• If users see “settings” here, will they expect to find their profile there too?

• When we say “cancel,” do we mean cancel the action or cancel the subscription?

This drove stakeholders insane. Where were the mockups? Where were the prototypes?

What they couldn’t see: we were doing the actual work. The work of clarifying mental models. The work of removing options instead of adding them. The work of naming things correctly so everything downstream would make sense.

Effortless products are the result of accumulated restraint, not brilliance. Every “simple” interaction hides dozens of rejected alternatives. Behind every clean screen is a graveyard of features that could’ve been there but shouldn’t have been.

I remember spending an entire week on a single button. Not the design – the placement. Should it live in the header or the context menu? On the page or in a modal? The answer seemed obvious until you realized that every choice created expectations about where similar actions would live everywhere else.

We moved it fourteen times.

When we shipped, nobody noticed the button. Which was the point.

This kind of work – naming, sequencing, constraint-setting – takes time because it forces clarity. And clarity is slow. You can’t shortcut it. You can only fake it, temporarily, until users show you what you missed.

The absence of friction is often mistaken for the absence of work. But friction doesn’t just disappear. Someone has to absorb it.

When slowness felt like failure

I didn’t always understand this.

Early in my career, speed was proof of value. The faster I shipped, the safer I felt. Turn around wireframes in a day. Deliver three options by tomorrow. Be the designer who “gets it done.”

And for a while, this worked. Speed got me noticed. Speed got me promoted. Speed felt like competence.

Then the problems got harder.

I started working on enterprise systems – the kind where a mistake doesn’t just frustrate users, it costs them hundreds of thousands of dollars. The kind where mental models are actually complex because the domain is actually complex. Legal tech. Financial platforms. Data infrastructure.

And speed stopped working.

At one company, I pushed to ship a feature in three sprints instead of six. We made the deadline. The feature worked. And within two months, we’d filed more bug tickets on that feature than any other part of the product. Every shortcut I’d taken became a support request.

But here’s the thing: even after I learned this, the anxiety didn’t go away.

Slowness still triggered something deep. The fear of falling behind. The fear of not being needed. The fear of appearing unproductive while everyone else shipped. Every day without visible progress felt like failure, even when I knew, rationally, that the work was happening.

I’d sit in standups with nothing to report except “still thinking through the data model.” You can see the doubt on people’s faces. You can feel it in your own chest.

What I eventually realized: the discomfort wasn’t a signal to move faster. It was a sign I was finally doing real work. The kind that doesn’t fit into a sprint update. The kind that only becomes visible when everything else works.

You don’t get slower. The problems get more real.

The same pattern shows up everywhere

This isn’t just about product design.

The things that create ease in life – health, trust, financial stability, meaningful relationships – all follow the same pattern:

• Sustained effort upfront

• Delayed payoff

• Minimal feedback while you’re doing the work

Building physical fitness feels pointless for weeks. You’re sore. You’re tired. The scale barely moves. Then, months later, you realize you climbed five flights of stairs without thinking about it.

Building financial stability means saying no to things that feel good now. Skipping the upgrade. Keeping the older car. There’s no notification that says “congratulations, you’re 18% more secure than last month.” You just wake up one day realizing you’re not worried anymore.

Building a relationship (a real one) means having the same conversation seven times. Showing up when it’s boring. Investing in infrastructure that doesn’t feel romantic but turns out to be essential.

Like products, lives become hard to use when built reactively. You patch instead of plan. You respond instead of design. Everything functions, technically. But the friction accumulates. The maintenance costs compound.

Ease later is always paid for upfront. There’s no way around the toll.

Why we resist slow systems

Here’s the uncomfortable part: our brains are wired against this.

Research on temporal discounting shows that humans consistently prioritize immediate feedback over delayed outcomes – even when the delayed outcome is objectively better.1 We’ll take a smaller reward now over a larger reward later, almost every time. (This isn’t weakness. It made perfect evolutionary sense when survival wasn’t guaranteed past next week.)

The planning fallacy compounds this. We systematically underestimate how long meaningful work takes. Not by a little – by a lot. Studies show we underestimate by 30-50% on average, even for tasks we’ve done before.2 Our brains genuinely believe meaningful change should happen faster than it does.

So when you’re three months into building something and feel like you should be further along – that’s not intuition. That’s a cognitive bias talking. Your expectations are calibrated wrong because human expectations are calibrated wrong.

This creates a psychological mismatch: effective systems feel wrong while they’re being built. The discomfort isn’t a signal that something’s broken. It’s the expected experience of building anything worthwhile.

What feels efficient in the moment often undermines stability over time. The quick win creates next month’s problem. The shortcut becomes the bottleneck. The decision you made to save a day ends up costing a quarter.

Our brains are wired against the kind of systems that actually work. Which means building them requires working against your own instincts.

Fast life, slow problems

You can see this everywhere once you start looking.

Careers built on constant motion but no foundation. Always busy. Always tired. Always one opportunity away from finally having it together. But the gaps never fill because there’s no system underneath – just momentum.

Health routines optimized for motivation instead of sustainability. Starting strong every January. Burning out by March. Repeat. The pattern isn’t bad discipline – it’s bad architecture. Systems designed for how you feel on your best day instead of how you actually live.

Financial decisions chasing quick relief. The subscription that’s “only” $15 a month. The purchase that’s “basically free” on installment. A hundred tiny yeses that never individually hurt but collectively drain. No single decision is wrong. The structure is wrong.

Relationships maintained reactively instead of proactively. Reaching out when something’s wrong. Making time when there’s a crisis. Always catching up, never getting ahead.

A life optimized for speed defers maintenance. And deferred maintenance doesn’t disappear – it accrues interest. Every shortcut borrowed against tomorrow’s capacity. Every quick fix kicked the real problem six months down the road.

Just like products, these lives appear functional but feel exhausting to inhabit. The cost is paid in friction, not failure. Nothing breaks. Everything just gets harder.

Slowness as signal

So what’s the alternative?

Not moving slower for its own sake. Slowness without purpose is just procrastination with better PR. The point isn’t to drag things out. It’s to recognize what slowness might actually mean.

Slowness can signal depth, not hesitation.

When you’ve been working on something for months and feel like you should be further along – ask yourself:

• Am I stuck, or am I building something that compounds?

• Is this stagnation, or is this the kind of work that can’t be rushed?

Repetition isn’t always failure to progress. Sometimes it’s the process of removing variance. Running the same experiment again because you’re not sure the first result was real. Having the same conversation with different stakeholders because alignment requires repetition.

What feels boring to build is often calming to live inside. The feature nobody notices. The habit so automatic you forget you formed it. The relationship so stable it doesn’t create stories.

The absence of urgency is a feature, not a flaw.

I think about the best products I’ve used – not designed, used. Most of them, I can’t describe what makes them work. They just do. The decisions are invisible. The structure holds without announcing itself.

That’s what slow building creates. Things that don’t need to explain themselves.

The user experience of your own life

Here’s what I keep coming back to:

You are both the system designer and the user.

Your routines, your standards, your defaults – you built them. Maybe consciously. Probably not. Either way, you’re the one who lives inside them. Every day. Every hour.

The question isn’t how fast you can move. Speed is seductive, but it’s the wrong metric. The question is: how does it feel to exist in what you’ve created?

A well-designed life doesn’t impress anyone. It doesn’t look ambitious from the outside. Nobody writes blog posts about the person who quietly built something sustainable and then just... lived in it.

But that’s the point.

Speed fades. Ease compounds.

The best systems don’t rush you. They carry you.

I was fourteen, sitting on the floor with an HTML book I didn’t understand.

Most kids at that age were glued to video games. I was glued to lines of code that refused to work. I’d type <font color=”red”>Hello world!</font>, refresh page, and nothing happened. Hours would vanish into the void of trying to figure out why the hell the text wasn’t turning red.

Nobody told me to do this. Nobody paid me. It wasn’t school. It wasn’t a “career path“. It was pure obsession.

Looking back, that one obsession shaped my entire life. It turned into a design career spanning 15 years, high-ticket clients, and freedom most people spend decades chasing. But at the time, it just looked like wasted hours on a computer.

The lie we’re told about careers

When you’re young, people feed you the same story:

• Pick a safe path: be a doctor, lawyer, accountant.

• Don’t waste time on hobbies.

• Don’t chase distractions.

My parents weren’t trying to sabotage me. They just wanted me to be safe. They didn’t thin designing websites could be a real job. To them, speding hours moving pixels on a screen looked like playing, not working.

And, honestly, they were'n’t wrnig in their world. The jobs they grew up around didn’t reward obsession. They rewarded predictibility.

But the safe path is the slowest path.

You’ll spend years climbing someone else’s ladder, hoping for incremental raises, while the kid who’s “wasting time“ building websites or making YouTube videos for fun will race past you. Bt because they’re smarter, but because obsession compounds faster than discipline.

How obsession compounds

Most people treat learning like school: read chapter, take a test, move to chapter two. It’s slow, linear, and predictable.

Obsession doesn’t work that way. Obsession is messy. You stay up until 3am googling why <div> won’t center. You’ll break a client’s website and scramble to fix it before they notice. You copy designs you admire pixel to pixel just to feel how it works.

That’s how I learned design. Not through a bootcamp, not through formal education, but by chasing curiosity into every corner of the internet.

And there’s a hidden benefit: what looks like play today compounds into mastery tomorrow.

Because wile others are putting in their neat little two houws of “study time“, you’re drowning in it willigly. You don’t need motivation. You don’t need accountability. You want to do it.

That creates unfair sped. What others learn in years, you learn in weeks.

The turnign point

My obsession could have stayed just a hobby. It almost did.

Then life forced me to make it serious.

When my wife got pregnant, I couldn't just “play with design“ anymore. I needed income. I needed proof that this obsession wasn’t just a phase. So I tool a local office job. My first salary? $400 a month. It barely covered food.

But the difference between me and other designer designers was clear: I wasn’t just doing the assigned tasks. I couldn’t stop tinkering. I’d redesign landing pages after hours. I’d stay late learning tools nobody asked me to use. I’d question why flows are broken instead of just making things “look nicer“.

Obsession leaked out of my whenever I wanted it or not.

That obsession is what pushed me out of that $400/month trap into freelancing. It’s what landed me foreing clients who paid me 3x what local companies offered. It’s what helped me jump from $1500 retainers to $9000/month contracts.

The irony that still makes me laugh: the thing my parents thought wasn’t serious became the most serious foundation of my life.

The invisible value of obsession

Here’s a mistake most young designers make: they thing obsession is weakness. They hide it. They try to be “well rounded“. They spread their energy across safe things: a little design, a little coding, a little marketing.

But the market doesn’t rward “a little“. The market rewards the people who got way deeper than anyone else is willing to go.

Client’s don’t hire you because you’re balanced. They hire you because you’re obsessed with making their flow smoother, their site faster, and their product easier to use. Employers don’t promote you for being average at everything. They promote you because you’re the person who won’t stop until the problem is solved.

The invisible value of obsession is this:

• You become the one peope can rely on

• You learn faster bcause you actually enjoy the grind

• You build things no one else would bother building

That’s what turns you from “just another designer“ into someone people fight to work with.

Obsession beats discipline

Let’s be blunt: discipline is overrated.

Discipline is forcing yourslef to sit down for two hours and grind through a task. Obsession is staying up all night because you can’t pull youself away.

Which one you think compounds faster?

The world tells you discipline is everything. And sure, discipline has it's place. But people who create real breakthroughs — the ones who make millions, who change industries — they’re not just disciplined. They’re obsessed.

They don’t count the hours. They loose track of them.

How to use obsession as your strategy

So how do you turn obsession into a career strategy instead of just a hobby?

Here’s a playbook I wish I had when I was younger:

1. Follow your curiosity ruthlessly. If you feel the urge to dive into animation, or typography, or motion design — don’t ignore it. That itch is a compass.

2. Build things, don’t just consume. Reading tutorials won’t get you far. Make websites. Clone products. Break things and fix them. Obsession only compounds when it’s active.

3. Show you work. Post ugly drafts. Share the experiements. That’s how strangers become clients. My first international cient came from a project I did for fun.

4. Tie obsession to outcomes. At some point, you need to make it pay. Look at where your obsession overlaps with what businesses value. My obsession with flows and interface became SaaS design contracts.

5. Ignore the timeline. Everyone else is asking “How long will it take to learn?“ Obsession doesn’t care. You’ll be doing it anyone, so time stops to matter. That’s the cheat code.

What it looks like in practice

When I think about the biggest leaps in my career, they weren’t logical. They weren’t carefully planned. They came directly from obsession:

• Spending nights reverse-engineering how apps were built → landed my first $1,500/month client.

• Writing case studies no one asked for → pulled in offers from San Francisco.

• Learning Framer because it was fun → now building templates that can scale income far beyond client work.

None of these looked “smart” at the time. They looked like I was just playing. But the compounding of years of play turned into leverage.

The emotional side no one mentions

Obsession isn’t always easy.

When you’re deep into it, you’ll feel misunderstood. Friends will ask why you spend every night on a laptop instead of going out. Parents will say you’re wasting time. People will call you crazy.

That’s part of the deal. Obsession makes you different. And being different feels lonely. Until the results show up.

The same people who thought I was wasting time later asked me how I built a career that gives me freedom, remote work, and income they can’t imagine.

At some point, “crazy” flips into “genius.”

The call to the younger version of me

If I could sit down with my younger self — the kid staring at HTML code at 3am — I wouldn’t tell him to sleep more, or to be balanced, or to pick a safe career.

I’d say:

Keep going. Don’t kill that obsession. Don’t try to be normal. That obsession is your only edge. Double down on it until the world has no choice but to take you seriously.

Because obsession isn’t a phase. Obsession is a strategy.

Final words

If you’re reading this and you’re obsessing over something right now (whether it’s design, coding, writing, or whatever) don’t bury it. That’s the thing that will separate you from the thousands of people who are just “interested.”

Obsession isn’t something to tame. It’s the most valuable asset you’ll ever have.

The world will call you crazy until it starts calling you genius.

Clients will ask for prettier buttons — when the real problem is the broken flow. Your job is to see through the noise.

There’s a quote by Steve Jobs:

Some people say, "Give the customers what they want." But that's not my approach. Our job is to figure out what they're going to want before they do. I think Henry Ford once said, "If I'd asked customers what they wanted, they would have told me, 'A faster horse!'" People don't know what they want until you show it to them. That's why I never rely on market research. Our task is to read things that are not yet on the page.

That’s not arrogance — it’s awareness.

Most clients aren’t bad at giving feedback. They’re just too deep inside the problem to describe it clearly.

What they think they need — a sleeker UI, a new feature, or a “bit more polish” — is often just a symptom.

Your job isn’t to build what they ask for. It’s to uncover what they actually need.

Surface wants vs invisible problems

Here’s the thing: people express problems using what they can see.

Design is visual, so the feedback becomes visual.

• “Make the logo bigger.”

• “This page feels empty.”

• “Can we make it more fun?”

But underneath those requests, there’s often a mess:

• A broken flow

• No narrative clarity

• Confusing priorities

• Unclear goals

They say “can you add more color?” → What they mean is “this doesn’t feel trustworthy.”

They say “make this part pop more.” → They mean “users are skipping over something critical.”

They say “we just need something simple.” → They mean “we haven’t done the strategic thinking yet, so we’re winging it.”

The better you get at recognizing these disconnects, the faster you shift from being a pixel pusher to being a creative partner.

Read between the lines

This is something I’ve learned the hard way: take feedback as a signal, not a command.

When a client says:

• “It doesn’t feel right” → Ask: what’s the goal we’re not hitting?

• “We want something more modern” → Ask: what does modern mean for your audience?

• “We like what X is doing” → Ask: why? what outcome are they getting that you want?

And instead of asking “what do you want to see here?”, I’ve started asking:

• What’s the biggest risk if this doesn’t work?

• What do users usually get stuck on?

• If we only fixed one thing, what would move the needle most?

The goal is simple: stop designing solutions to surface-level feedback. Start designing to solve business problems.

Show, don’t just ask

Sometimes, showing an alternate flow or direction is the most effective way to shift the conversation. Clients don’t always know how to describe the solution — but they know when they feel it.

Don’t wait for perfect briefs. Look for patterns. Ask better questions. Be the one who connects dots instead of coloring within the lines.

The more you do this, the less your clients will see you as “the designer.” They’ll see you as the person who makes things work.

Thanks for reading. If this resonated with you, consider becoming a paid subscriber of Alex’s Camp to unlock access to all posts about creative freedom, productized thinking, and building a smarter, saner design career.

Keep exploring, — Alex

I never really looked for people who were just "smarter" than me. Instead, I was drawn to people who had a kind of freedom that I didn’t.

When I think about the people who have made the biggest difference in my life, they weren’t always the ones with the best degrees or the highest IQs. They were the ones who had a kind of freedom I wanted — whether that was creative freedom, emotional freedom, or just the ability to relax and not overthink everything.

I knew someone who never worried about money — who took risks on projects without freaking out. Another person could talk to anyone with confidence while I second-guessed every word I said. A designer friend trusted their instincts instead of doubting themselves. An entrepreneur I knew made quick decisions while I sat and debated for way too long.

Being around them wasn’t always easy. Sometimes, it made me notice my own weaknesses. But that discomfort meant I was learning. Being around people who make you feel a little less sure of yourself can be tough, but if you let it, they help you grow.

Ribbonfarm explains it well:

"They are people who are playing just a slightly different game than you are. That difference makes them a reliable source of unpredictability in your life."

And that’s important — when people think differently from you, it pushes you to grow.

Finding the right people isn’t easy. For a long time, I had lots of friends but very few who truly understood me. Eventually, I realized that the best people make you feel both free and safe. Safe enough to say what’s on your mind. Free enough to take risks. Enough to change, knowing they’ll still be there for you.

To find those people, start small. Find just one person first. They don’t have to be in your city. They might be someone you meet online. Someone whose work inspires you, whose thinking challenges you, whose confidence you admire. Someone who, just by being themselves, shows you what’s possible.

I’ve been changed by people like that. By how they work, how they organize their days, how they handle failure. By how they notice beauty in places I never thought to look. Lately, I’ve started to see beauty in people — not in their looks, but in the way they carry themselves. Confidence, kindness, curiosity, and boldness shine like a kind of light.

There’s a quote I love: "Realizing someone is beautiful in a way no one you've ever met is beautiful — and because of that, they've expanded your understanding of beauty forever." That’s what great people do. They don’t just teach you things. They change how you see the world. And once you find one of these people, you realize you can find more.

Finding them is hard. But they are out there. You just have to look.

Ever notice how we talk ourselves out of difficult things?

We say, "I'm not disciplined enough." "I'm not that kind of person." "That’s just too hard for me."

But if you really think about it, you’ve already done hard things. A lot of them.

Maybe you taught yourself a skill from scratch, landed a job that once felt out of reach, moved to a new city alone, or pushed through a tough time in life. You didn’t feel ready — but you did it anyway.

That’s proof.

We all know that doing hard things is... well, hard. But have you ever noticed that the best things in life usually come from the hardest things we’ve done?

Think about it. The skills that make you valuable? The relationships that mean the most? The accomplishments that actually make you proud? None of them came easy.

That’s not a coincidence.

There’s a reason people who push themselves tend to have more fulfilling lives. The more you take on difficult things, the stronger, more capable, and more confident you become.

Pressure is a privilege.

Hard things make you stronger

When you challenge yourself, you build resilience. The more discomfort you face, the better you get at handling it.

A workout that feels impossible today will feel normal in a month. A skill that seems overwhelming at first will feel second nature after enough practice. The struggle is the growth.

If you avoid hard things, you shrink. You get weaker, less adaptable, and more afraid of failure. But when you choose to do hard things, you become the kind of person who can take on anything.

Hard things create meaning

Ever noticed that easy things don’t bring real satisfaction?

Scrolling social media, binge-watching shows, playing it safe — these things feel nice in the moment, but they don’t leave you fulfilled. The things that bring true joy — achievements, deep relationships, mastering a skill — come from effort and persistence.

Joshua Waldron puts it well:

“Hard creates fulfillment. It creates significance. It makes life fun.”

Because when you push through difficulty, you’re not just achieving a goal — you’re proving to yourself that you’re capable of more than you thought.

Hard things build confidence

Confidence doesn’t come from thinking you're capable — it comes from knowing you are.

And the only way to know is to prove it to yourself, over and over again.

Every time you step outside your comfort zone, your brain remembers: I’ve done hard things before. I can do this too. You stop avoiding challenges because they no longer feel impossible.

Confidence isn’t something you’re born with. It’s something you build — one hard thing at a time.

The challenge

If doing hard things makes life better, the real question is: what’s stopping you?

Most of the time, it’s just fear of discomfort. But what if you started seeing that discomfort as proof that you’re on the right track?

So here’s a challenge: Pick one thing you’ve been avoiding because it feels hard. And start. No waiting for motivation, no overthinking — just action.

Because on the other side of hard things? That’s where the good stuff is.

— Alex

P.S. Want to start small? Keep a list of hard things you’ve done. Anytime you doubt yourself, look at it. You’re stronger than you think.

I was always afraid to do what I wanted, thinking no one would need it.

But now, looking back, I see that every breakthrough in my life happened when I followed my curiosity — not when I tried to control the outcome, not when I meticulously planned every step, but when I let go and allowed things to unfold.

When I obsessed over results, I became stuck. The weight of expectations made everything heavy, turning passion into obligation. I was pushing against reality, trying to force my way through circumstances that weren’t ready to change.

At some point, I became a hostage to outcomes. I started acting from a place of need rather than want — and that’s when the joy disappeared. My work felt calculated and uninspired. I became serious, smart, and sad. What once felt effortless became a struggle.

Then I realized something: life was moving forward, with or without me. And I didn’t want to spend it proving my worth to people who didn’t even understand what I was trying to do. So I took a risk. I let go of proving, chasing, and performing. And I started doing what I wanted again.

It was not as easy as it appeared at first.

Doubt whispered in my ear. Fear told me I was being reckless. But I trusted my inner feelings, closed my eyes, and immersed myself in the pleasure of the process, forgetting about the metrics and opinions of others. That’s when the fire came back — the creativity, the excitement, the magic.

I realized that the most valuable thing for others is exactly what I want to do.

Because I do this out of love, not out of a desire to maintain the mythical status of a “good guy.”

I realized that the world doesn’t need me to be good or correct. It doesn’t reward me for following a safe script. It wants me to play, explore, dance, and create — not out of obligation, but out of love.

And the irony? The things I once did for fun, in stolen moments and on weekends, when I could "afford" to follow my passion — those were the things that changed my life the most.

So I stopped waiting for permission. I stopped doing what was “necessary” and started treating every day like it was my last.

And here’s what I found:

When you move with joy, life moves with you. When you trust yourself, you create your best work. And when you stop chasing outcomes, the best outcomes find you.

Think outside the box.

Very common saying among designers. But thinking outside the box doesn’t mean you can't have constraints. Without limitations the possibilities are endless. And endless possibilities lead to choice paralysis and unfocused work.

Thinking outside the box is stepping out of your own perspective and selecting *conscious constraints* that help you focus. Defining the right boundaries allows you channel creativity in a way that produces innovative and impactful solutions. These boundaries force us to find creative solutions that work within the defined parameters.

Look at Sam's work.

In his interviews he often mentions the importance of constraints:

Constraints are the best fuel for creativity.1

and

Artists often impose extreme constraints on themselves to focus creativity.2

Truth is, constraints are inevitable part of any design process. They can stem from business goals, technical limitations, user needs, or timeline and budget restrictions. But constraints shape how products are conceptualized, designed, and built. So rather than seeing them as obstacles, great designers embrace constraints as opportunities to innovate and create focus.

Types of constraints in product design

As product designers, we face various constraints that shape our decisions throughout the design process. These constraints influence how products are built, who they serve, and how they function. While constraints can initially seem restrictive, they often lead to focused, efficient, and more impactful designs. The key is to recognize, understand, and leverage these limitations effectively.

Technical constraints

Technical constraints refer to the limitations of the technology stack, frameworks, and platforms used to develop a product. These can include factors such as processing power, storage limitations, legacy systems, or compatibility issues with different devices and browsers. We need to learn to work within these constraints to ensure that the final product is both functional and performant.

Strategy: reframing constraints as opportunities can drive innovative solutions. Instead of seeing technical limitations as barriers, use them as guidelines for prioritization and optimization. Prototyping and testing early in the process can help identify potential roadblocks and refine solutions that align with technical realities.

Example: mobile-first design. When designing for mobile devices, screen size and performance constraints require prioritizing key features and optimizing user experience. This forces us (designers) to streamline interactions and eliminate unnecessary elements, leading to cleaner, more focused designs that also enhance desktop experiences.

Business constraints

Business constraints stem from financial, strategic, and operational limitations, such as budget restrictions, project timelines, stakeholder requirements, and regulatory compliance. These constraints directly influence what features can be developed, the pace of iteration, and the overall direction of the product.

Strategy: prioritization is crucial when dealing with business constraints. We need to focus on high-impact features that align with business goals and user needs. Leveraging existing systems, such as design frameworks or pre-built components, can also help reduce costs and accelerate development.

Example: startups with limited resources. Early-stage startups often have small teams and tight budgets, requiring them to focus on minimum viable products (MVPs). By prioritizing core functionalities and iterating based on user feedback, startups can maximize impact without overextending their resources.

User constraints

User constraints are the limitations and needs of the end user, including accessibility requirements, cognitive load, and behavioral patterns. These constraints are influenced by factors such as age, disabilities, digital literacy, and usage context (e.g., using an app while commuting).

Strategy: prototyping and user testing are essential for understanding and addressing user constraints. By continuously iterating based on real user feedback, we can ensure that our solutions remain inclusive, usable, and effective for diverse audiences.

Example: designing for accessibility. Products designed with accessibility in mind, such as ensuring proper color contrast, keyboard navigation, and screen reader compatibility, improve usability for everyone, not just those with disabilities. Companies that prioritize accessibility create more inclusive experiences and expand their user base.

Design constraints

Design constraints include brand guidelines, existing design systems, and the physical limitations of interfaces (e.g., screen size or input methods). These constraints ensure consistency across products and create familiar experiences for users but may limit creative freedom.

Strategy: leveraging existing systems, such as component libraries and established brand guidelines, helps maintain consistency while speeding up the design process. However, we can also push the boundaries when justified, advocating for updates to outdated design standards if they hinder usability or innovation.

Example: maintaining brand consistency in multi-platform products. Companies like Google and Apple follow strict design guidelines to ensure a seamless experience across their apps and services. While these constraints limit drastic design changes, they also create familiarity and trust for users navigating different platforms.

Balancing constraints and innovation

Constraints are not the enemy of innovation — they’re a catalyst for it. By embracing constraints, we can channel our creativity into solving meaningful problems within real-world boundaries. The key is to balance pragmatism with ambition: respecting constraints while pushing for innovative, user-centered solutions.

So, you've just landed your dream job as the first design hire at a startup. Congrats! It’s an exciting moment — you’re holding the keys to shape the design culture and craft the user experience from scratch.

But let’s be real: you’re also stepping into the unknown.

Suddenly, you realize there’s no research to rely on, no design system to follow, and no clear answers to why development took some “creative liberties” with your designs. Sound familiar? You’re not alone.

Having spent over 14 years in design (much of it as a “team of one”), I’ve seen a lot of this: the chaos, the challenges, and the opportunities. Here’s what you’re likely to face — and more importantly, how to thrive.

Lack of structure and resources

Startups are fast-paced and often scrappy. You may find yourself in an environment with minimal structure and limited resources, which makes defining a clear design approach tricky.

What to do: Grab an oar and start rowing

Startups move fast, so don’t wait for everything to be perfect. Look for quick, low-risk wins that help you contribute immediately. This could be refreshing a UI component, creating a quick prototype, or organizing a design critique.

Wearing multiple hats

As a solo designer, you’ll be juggling roles: UX researcher, UI designer, interaction designer, and maybe even a copywriter. It can be overwhelming, especially if you’re still early in your career.

What to do: Build leverage

Keep track of everything: decisions, iterations, and documentation. That messy Figma file? Organize it. Those interview questions? Save them for reuse. Build systems that help you move faster over time.

Lack of design culture

When there’s no existing design culture, you’ll need to build it from scratch. If the team doesn’t understand the value of design, this can feel like pushing a boulder uphill.

What to do: Be resourceful

When resources are scarce, get creative. No design system? Start with screenshots of existing components. Limited research? Talk to customer-facing teams. Even small actions can generate big insights.

Managing expectations

Other teams may not fully understand the design process, leading to mismatched expectations and potential frustration.

What to do: Collaborate without permission

Reach out across teams and start building connections. Offer to review a product requirements doc, help sales prioritize client requests, or chat with growth about their experiments. Don’t wait for an invite — just dive in.

Limited feedback

Without a design team to bounce ideas off, it can be hard to grow your skills or validate your decisions.

What to do: Advocate by doing

Instead of trying to persuade people with arguments, show them the value of design through action. Deliver small wins and refine processes as you go. In the words of Andy Grove, “Let chaos reign, then reign in the chaos.”

Industry and system learning curve

If you’re new to the industry, you’ll need to quickly understand both the product and the market it serves while also navigating the technical aspects of building a design system.

What to do: Understand the company’s bets

Know the market, the competitors, and the strategic bets your company is making. Tools like Porter’s Five Forces can help you analyze the business landscape. This understanding will guide your design decisions and help you frame their impact.

Communication and collaboration

Startups thrive on collaboration, but cross-functional teams might lack a shared understanding of design’s role. Bridging these gaps will require tact and persistence.

What to do: Build bridges to bold ideas

Dream big, but stay practical. Advocate for a long-term vision while showing how to get there incrementally. The goal is to inspire the team without overwhelming them with unrealistic expectations.

Final thoughts

Being the first design hire at a startup can feel like a lot. Because it is. But with the right mindset, resourcefulness, and a dash of persistence, you can thrive.

You don’t need to be a superhero. Just stay fast, informed, and flexible.

If I can do it, you can too.

If you enjoyed this post and want more insights like this, subscribe to Alex’s Camp. It’s free, and by subscribing you’ll never miss new posts.

Subscribe now

Enjoying Alex’s Camp? Share the value with your friends! Invite 3 friends to subscribe, and you’ll get 1 month of paid subscription for free. Spread the knowledge and unlock even more exclusive content!

Refer a friend

I’m in a rut. Feels like I’m not delivering any value. I keep focusing on details no one cares about (colors, typography, and icon stroke width) but clients aren’t happy.

This was me almost 10 years ago.

Back then, I thought the problem was my design skills. Maybe the buttons weren’t quite right, or the layout could be cleaner. But here’s the twist: it wasn’t about the pixels; it was about the purpose.

Founders and businesses weren’t looking for “perfect” designs — they wanted results. Once I shifted my focus to how design could drive real outcomes (more leads, lower bounce rates) everything clicked into place.

If you’ve ever questioned your impact as a designer, know that you’re not alone. It’s easy to fall into the trap of focusing on aesthetics over results, doubting your abilities, or wondering if your contributions matter. But how do you know if you’re truly doing a great job?

After years of navigating these questions, I’ve found three core areas that help define success: delivering business impact, contributing to your team’s efforts, and receiving positive feedback.

Are you delivering business impact?

At its core, design is a strategic tool for driving business growth. It’s not just about making things look good — it’s about solving problems, improving outcomes, and contributing to the bottom line. This realization transformed how I approached my work.

For example, instead of obsessing over the exact shade of a button, I shifted my focus to its function: does this button’s contrast and call-to-action drive conversions? Instead of worrying about typography sizes, I began asking, does this layout reduce bounce rates?

To evaluate whether your work is delivering business impact, ask yourself:

• Are you hitting essential goals that align with business priorities?

• Are your designs contributing to measurable outcomes (like higher sales, improved conversion rates, or reduced churn)?

One thing to keep in mind: you need to work with companies that value design’s strategic role. If the companies you work with see design as an afterthought, your impact will always feel limited.

When in doubt, look for ways to directly tie your work to business outcomes. This is one of the most reliable ways to demonstrate your true impact.

Are you contributing to the team’s efforts?

Design is rarely a solo effort. Your impact scales significantly when it’s part of a larger team effort. But contributing to your team’s success requires more than just completing your individual tasks. It means being proactive, collaborative, and sometimes stepping into roles outside your comfort zone.

Early in my career, I believed my job was just to “design things.” But as I grew, I realized that some of my most significant contributions came from pushing the team to prioritize critical work, finding unique customer insights, or coming up with ideas that sparked new directions for projects. These are the kinds of efforts that make you indispensable to your team.

To assess your contribution, ask yourself:

• Are you bringing fresh ideas and perspectives to the table?

• Have you made significant individual contributions that others on the team recognize?

• Would your teammates or clients miss you if you left?

Remember, the higher you climb in your career, the more your contributions will shift from execution to strategy and leadership. That doesn’t mean you have to manage teams — not everyone wants to be a manager. I don’t. I found managing people to be one of the most draining periods of my career. I thrive in the craft of design and hands-on problem-solving. If leadership isn’t your thing, focus on being a force multiplier through your individual work.

Are you getting (positive) feedback regularly?

Feedback is one of the most critical tools for growth. Without it, you’re flying blind. Early in my career, I learned that feedback is not just about improving your work — it’s also about building trust and relationships with your team and clients.

The goal isn’t just to hit deadlines or meet expectations. It’s to create a lasting impression. You want people to say, “This designer is amazing” rather than just “They got the job done.”

Here are a few ways to build trust and ensure you’re getting positive feedback:

1. Understand your stakeholders. Before a project begins, take time to understand your clients or team’s goals, pain points, and expectations. This helps you frame your work in a way that resonates with them.

2. Check in regularly. Frequent communication builds trust and keeps everyone aligned. Regular updates and feedback loops show you’re invested in the process.

3. Set expectations and over-deliver. Doing what you say you’ll do builds respect, but exceeding expectations leaves a lasting impact.

4. Embrace your role as an expert. Confidence in your craft inspires confidence in your clients and teammates.

Ask yourself:

• Are people eager to work with you again?

• Do clients or executives actively seek your input or recommendations?

Positive feedback isn’t just a career boost, it’s a sign that you’re building meaningful relationships and delivering value beyond the work itself.

Wrapping up

Being a great product designer isn’t about perfection. It’s about impact, collaboration, and relationships. If you’re ever unsure about where you stand, ask yourself:

1. Are you delivering measurable business impact?

2. Are you making meaningful contributions to your team’s success?

3. Are you getting consistent, positive feedback from stakeholders?

These aren’t just metrics for success; they’re guideposts for growth. If you focus on these areas, you’ll not only know you’re doing a great job — you’ll be well on your way to an even greater career.

Imagine you’re scrolling through yet another SaaS platform demo. The product promises innovative features, but the interface feels generic, like dozens of others you’ve seen. You’re intrigued by what it can do, but something is missing — trust, confidence, delight.

This is the danger of “good enough” design. It’s functional enough to get by but rarely leaves a lasting impression. In a market flooded with competition, where users have countless options, good enough is rarely good enough.

The problem with good enough design

It’s easy to see why startups take this route. Time is critical, budgets are tight, and the pressure to ship quickly is enormous. Using a pre-made UI kit or sticking to basic design principles can help launch an MVP faster.

But what happens next?

Even the most feature-rich products can struggle in a crowded market if they fail to stand out. A generic design might work for initial testing but often leaves users with the impression that the product is just another tool in a sea of sameness.

While users may appreciate functionality in the short term, they also expect more:

• Seamless, intuitive experience that reduces friction.

• Polished, professional interface that builds trust.

• Brand identity that feels unique and memorable.

Without these elements, users are likelier to churn or abandon the product altogether. Worse, they might never see the product as a serious contender, no matter how powerful its features are.

Thoughtful design drives success

The solution isn’t to abandon speed entirely but to balance it with intention. Startups can — and should — test ideas quickly, but they need to invest in thoughtful design from the very beginning. Here’s how:

Start with a scalable design foundation

A pre-made UI kit or basic templates can be a helpful starting point, but only if they’re part of a larger plan. From day one, consider how your design choices will scale. A modular design system not only makes your product look cohesive but also allows for easier updates as your product grows.

Invest in branding early

Your product’s identity isn’t just about colors and logos. It’s about the feeling users get when they interact with your product. A well-defined brand can make even a simple interface feel purposeful and unique, setting the tone for everything else.

Test usability, not just functionality

When testing early versions of your product, focus on how users interact with it.

• Do they struggle to complete tasks?

• Are there moments of frustration or confusion?

These insights can inform design updates that go beyond aesthetics and directly improve the user experience.

Iterate with design in mind

As you gather user feedback, prioritize improvements to both functionality and design. Small, thoughtful changes — like streamlining workflows, improving visual hierarchy, or adding micro-interactions — can dramatically enhance the overall experience.

Benefits of prioritizing design

Thoughtful design isn’t just about making a product look pretty. It’s a strategic investment that drives real results:

• Improved user retention: A product that’s intuitive and delightful to use keeps users coming back.

• Stronger brand perception: A polished interface builds trust and positions your product as a market leader.

• Increased efficiency: A scalable design system reduces time spent fixing inconsistencies and accelerates development.

• Higher conversions: An optimized user experience makes it easier for users to sign up, upgrade, or stay engaged.

Startups that invest in design from the beginning don’t just ship a product — they create a product experience that users remember.

What should designers do?

As a designer, you have a crucial role to play in shaping the success of SaaS products. Advocate for thoughtful design, even in the MVP stage. Help founders understand that while speed is essential, design isn’t just a nice-to-have — it’s a competitive advantage.

When working on early-stage products, balance practicality with vision. Lay the groundwork for scalable, user-focused design, and show stakeholders how investing in design now will save time, money, and effort later.

What should SaaS founders do?

Don’t fall into the “good enough” trap. Yes, testing your ideas quickly is important, but thoughtful design isn’t a luxury — it’s a necessity. Your users aren’t just judging your product on what it does; they’re judging how it feels, how easy it is to use, and whether it reflects the level of professionalism they expect.

Invest in scalable design systems and brand identity early. You don’t need perfection right away, but you do need intention. With thoughtful design, your product can grow with your users and stand out in a crowded market.

In the race to launch a product, it’s tempting to cut corners on design. But the companies that win aren’t just those who ship fast — they’re the ones who build experiences that users remember.

The New Year is here. It’s that time when we all get hyped up, set big goals, and promise ourselves, this year will be different. But let’s be real. By mid-March, most of those goals will be gathering dust.

Why? Because we want results. Fast. When things don’t click right away, it’s easy to think, “Maybe I’m not cut out for this” or “Maybe this goal was just a dumb idea”. And then we quit.

But here’s the thing: change doesn’t work that way. It’s not about flashy starts or quick wins. It’s about showing up, day after day, even when it feels like nothing is happening.

That feeling

You know the one. The rush of motivation when you sit down, grab a pen, and list out all your goals. It feels amazing, doesn’t it? You’re inspired. Fired up. Ready to tackle the world.

But let’s be honest. That’s the best part of goal-setting. Writing them down. Dreaming about them.

The rest? It’s tough. It’s about patience, discipline, and sticking to it even when you’d rather not.

I’ve been there. Every year, I’d make a long list of goals: big ones, small ones, all the things I wanted to do. Then I’d dive in. Try this method, that app, this planner. And guess what? Most of those goals didn’t happen.

Sound familiar?

Stop setting goals

A few years ago, I gave up on goals completely. I was tired of feeling like I’d failed every time I didn’t cross something off the list. So I just stopped.

At first, it felt freeing. No pressure. No lists. But eventually, I realized I wasn’t getting anywhere. I was just drifting.

Then I picked up a book called The Compound Effect by Darren Hardy, and something clicked. The book’s whole idea is this: success doesn’t come from big, dramatic moves. It comes from small, smart choices you repeat every day.

One little action might not look like much, but over time? It adds up.

You can’t do it all at once

Here’s the part no one tells you: success isn’t about juggling a million things. It’s about focusing on one thing at a time.

I learned this the hard way. I was on a mission to find my dream clients — the ones that would pay well, give me great projects, and let me work how and where I wanted. But I was so busy hustling on small jobs and sending out proposals to anyone and everyone that I didn’t have time to actually think about what I wanted.

When I finally stopped, I felt stuck. Guilty, even. I wasn’t working, wasn’t earning, wasn’t “doing enough.” But that pause gave me the clarity I needed. I figured out exactly who my dream clients were. Then I went after them. And it worked.

Gary Keller, in his book The One Thing, says it perfectly:

“Success is sequential, not simultaneous.”

One thing at a time. Finish it. Then move on to the next.

Resolutions that work

Most of us set goals like this:

• Grow to 10,000 followers

• Make $100,000

• Write a book

• Lose weight

Sound familiar? The problem is, these goals focus on the outcome, not the process. And here’s the truth: you can’t control the outcome.

What you can control is what you do every day to get there.

So flip the script:

• Grow to 10,000 followers → Post something valuable every day

• Make $100,000 → Reach out to 3 potential clients daily

• Publish a book → Write 1 page every day

• Lose weight → Cut 200 calories and exercise every day

Small actions, repeated daily, create momentum. Over time, they compound into something bigger.

One step at a time

In my last post, I talked about embracing change. This? This is the next step. Once you decide to change, you have to commit to it. Not with a grand gesture, but with small, steady steps.

Think of it like planting seeds. You don’t plant a tree today and expect shade tomorrow. You water it. Care for it. And trust that it’ll grow.

So, here’s your challenge: take one of your goals. Break it down into tiny, daily actions. Then do the work. Every day. Even when it feels like nothing is happening.

That’s how real change happens. It’s not flashy. It’s not fast. But it works.

The design world is evolving fast. Companies are no longer hiring experts in just one narrow skill. Instead, they want generalists — designers who see the big picture, connect the dots, and align user needs with business goals.

These designers don’t just make things look good. They solve real problems, create systems, and think strategically. With modern tools speeding up workflows, designers now spend less time on repetitive tasks and more time focusing on what truly matters.

Shift in how we work

New tools have transformed the way designers think and create. What once took hours now takes minutes, allowing for faster idea exploration and iteration. But this also changes what’s expected from designers.

It’s no longer enough to produce good work; you need to communicate your ideas clearly, write thoughtful prompts, and refine outcomes to align with your vision. Quick mockups can now help designers bring ideas to life early in the process, making collaboration with clients and teammates smoother.

Today, being fast, clear, and strategic is what sets a designer apart.

Adapting to new roles

Modern designers aren’t just creators — they’re problem-solvers who understand why they’re designing something. Instead of focusing on repetitive tasks, today’s tools let designers invest their time in creativity and strategy.

Strong communication skills are now just as important as technical ones. Explaining your ideas clearly, leading discussions, and connecting with your team or clients is crucial. Learning complementary skills like coding or psychology can also help you design more meaningful solutions.

Future of design careers

Design jobs are no longer one-size-fits-all. Many roles combine skills, like designing and coding or specializing in AI-driven interactions. Freelancing and entrepreneurship are also growing but require strong personal branding and the ability to stand out in a competitive market.

At the same time, ethical and inclusive design is becoming more important. Designers are expected to create innovative, user-centered solutions that also reflect social values. Success in this evolving field depends on staying flexible, learning new skills, and balancing creativity with responsibility.

Staying human

Real-time collaboration tools have changed how teams work. Platforms like Figma and Miro make working with global teams easy, while automation takes care of repetitive tasks. This frees up designers to focus on solving bigger challenges and refining their ideas.

But in the middle of all this tech, empathy, ethics, and inclusivity matter more than ever. Designers must create work that resonates with diverse audiences, solves real problems, and reflects values that people care about.

Change in design isn’t something to fear — it’s an opportunity. Use new tools to boost your creativity, not replace it. Stay curious, learn across disciplines, and keep people at the center of your work.

Design is at an exciting crossroads. As technology reshapes the field, now’s the time to rethink your career, explore new trends, and embrace the future.

If you found these insights helpful, I’d love to continue the conversation. Subscribe to Alex’s Camp, where I share strategies and trends shaping the design world.

Subscribe now

What trends do you see shaping design? Share your thoughts in the comments, and let’s connect!

Fear is a natural emotion. We’ve all felt it — whether it's standing on the edge of a major decision, facing something new, or stepping out of our comfort zones. Fear tells us to pause, retreat, or stay where it's safe.

It can be paralyzing, stopping us from reaching our full potential. But what if there was another way to respond to fear? Instead of retreating, what if we leaned into it with curiosity?

Curiosity is the antidote to fear. It transforms how we view challenges and uncertainty. While fear screams "avoid," curiosity whispers "explore."

The same situation that fills us with anxiety can spark curiosity if we allow it. I’ve seen this play out time and again in my career as a designer, where tackling complex problems with curiosity has led to breakthroughs and innovation.

Understanding fear

Fear has a simple job: to protect us.

It keeps us from harm, both physical and emotional. But in today's world, fear is often more a mental roadblock than a physical one. We fear failure, rejection, or the unknown. In moments of fear, we feel the urge to retreat, to play it safe.

Yet, playing it safe often leads to stagnation. We shy away from new projects, turn down opportunities, or avoid learning something difficult because the fear of the unknown looms large.

But the thing about fear is that it grows in the dark, fed by our ignorance and assumptions.

The power of curiosity

Curiosity is different. It’s what drives us to explore, to ask questions, and to seek out answers. Curiosity nudges us to move forward rather than pull back. It opens up possibilities, replacing fear of the unknown with a desire to understand it.

When I faced moments of doubt in my career — whether launching a new project or venturing into an unfamiliar design challenge — it wasn’t confidence that kept me going. It was curiosity. I wanted to see what was on the other side, to learn something new, and to push past my fear.

How curiosity counteracts fear

Think about it: when you're curious, you're less focused on what could go wrong and more interested in what you might discover.

Curiosity reframes fear. It's not a question of "What if I fail?" but rather, "What can I learn from this?"

I remember a time when I worked on a particularly technical project. Initially, the complexity scared me. I didn't feel ready. But I let my curiosity lead the way — what could I uncover by diving in?

Step by step, my fear faded as curiosity guided me through each challenge, ultimately leading to a successful outcome.

Cultivating curiosity

Cultivating curiosity starts with the willingness to ask questions.

Instead of shying away from difficult tasks, ask: What can I learn here?

Start small — be curious about something in your daily routine or work. Surround yourself with diverse ideas and perspectives. Most importantly, embrace uncertainty. Rather than seeing it as a threat, view it as an opportunity to explore.

Conclusion

Fear is a powerful emotion, but curiosity is just as strong. When fear tries to pull us back, curiosity encourages us to move forward. It shows us that there’s more to gain by exploring the unknown than avoiding it.

The next time you feel fear rising within you, pause and let curiosity take over.

You'll be surprised at what you might discover.

For a while, I convinced myself that more was better — more projects, more side gigs, more hustles. It seemed like the fast track to success. But what I didn’t realize was that I was slowly driving myself into the ground. And trust me, that road is not paved with gold.

The many things

At one point, my life looked like this: I was freelancing as a designer, launching an online store, starting a clothing brand, doing marketing gigs, barely squeezing in time for content creation, building websites from scratch, mentoring fellow designers, and — oh, don’t forget — trying to launch a course. That wasn’t all. I wanted to be a present husband and father, spend time with friends, and somehow carve out weekends to relax. Ambitious, right?

Each new endeavor felt exciting at first, like unlocking a new level in a video game. More money! More opportunities! It was limitless. But after the initial thrill wore off, I found myself drowning in the sheer volume of work. There was just no room to breathe. I was constantly on the go, hopping from one task to the next. I thought that juggling everything would diversify my income and, eventually, lead me to the promised land of "success."

I quickly realized that while I was doing everything, I was doing none of it particularly well. Worse, I felt tired all the time — unmotivated, even. My projects stalled, and my self-esteem sank lower than the floor. I had spread myself so thin that I wasn’t giving anything the attention it needed. It was a wake-up call, but I didn’t have a clue what to do next.

The breaking point

It was around this time that I hit my breaking point. I felt completely burnt out, and every task felt heavier than it should. I was doing too much, and none of it was bringing me joy anymore. I kept telling myself that I could push through it — that if I just worked harder or stayed up later, everything would fall into place.

Eventually, I had to face a harsh reality. I couldn’t keep going without something falling apart. Worse, everything was falling apart, including my health and my relationships. So, I made a decision that felt almost radical: I shut down everything except for the one thing that brought me the most value, joy, and stability — design work.

The funny thing is, at first, I felt like I was missing out by focusing on just one thing. I’d become so used to juggling a million projects that doing only one thing seemed almost lazy.

But then, something amazing happened. I started to notice the benefits almost immediately. Without the distractions of my other ventures, I was able to finish all work by noon. My afternoons were mine again. I could spend time with my kids, my wife, and my friends, and I actually had weekends again. I hadn’t realized how much I’d been missing until I got it back.

The shift to design

Choosing to focus on design wasn’t a difficult decision when I really thought about it. Design was something I’d always loved doing — it was something I was good at, and it brought in the most income.

What was stopping me from going all in? Fear, mostly. Fear that if I only did one thing, I’d somehow be less. Less competitive. Less successful. Less... everything.

But that fear melted away as soon as I committed. Once I focused on just offering design services, something clicked. I wasn’t just doing the work anymore; I was thriving in it.

I had more time to pour into each project, and because of that, the quality of my work skyrocketed. I was proactive, flexible, and genuinely excited about every project I took on. And clients noticed.

I raised my rates, picked up larger projects, and developed deeper relationships with the companies I worked with. The difference was night and day.

Clarity after chaos

The most surprising part of focusing on one thing was how much calmer I became. It was like I’d been living in a constant state of low-level panic before, and I hadn’t even realized it.

But once I cut away the excess and focused on design, I felt in control again. I knew what I had to do, and I did it well. There were no more late-night panics about uncompleted tasks or unfinished projects, just a sense of satisfaction from doing one thing, and doing it right.

This shift helped rebuild my confidence. When you stop scattering your energy in ten different directions, you get really, really good at the one thing you focus on. And that’s empowering. Instead of feeling like I was spinning my wheels, I started seeing real, measurable progress in my work. I wasn’t just "staying afloat" anymore — I was thriving.

The magic of doing only one thing

What I’ve learned from this journey is that you don’t have to do everything to succeed. In fact, doing everything is often the quickest way to fail. The real magic happens when you focus on one thing and find a way to make it better than anyone else.

For me, that was design. For you, it might be something different. But whatever it is, give it your full attention. Cut out the distractions, the extra projects, and the noise.

Trust me, your future self will thank you.

You’ve barely caught your breath, and suddenly you’re trying to wrap your head around workflows that sound like something from a sci-fi novel. It’s overwhelming. Your brain is juggling a million concepts, and then there’s a list of things you need to learn that just keeps getting longer.

Oh, and did I mention you’re also working with technical stakeholders who may have never worked with a designer before? Yep, that’s the cherry on top.

It might feel like you’ve been dropped into the middle of a conversation in a language you don’t speak. I know this feeling well because when I first started, I was drowning in jargon, complex models, and workflows that seemed impossible to untangle. But the challenge wasn’t just understanding the language — it was figuring out how all the pieces connected and how they impacted the business.

But hey, it’s not all bad.

Having spent five years in this world, I can tell you that designing for these spaces is one of the most rewarding challenges out there. There’s a lot of room for simplifying the complex, and let’s be honest, that’s where we designers thrive.

The problem, though, is wrapping your head around the domain itself. It’s like standing at the bottom of a mountain looking up, wondering how the heck you’re going to climb it. You want to make time to learn all the things, but your day is already packed. Sound familiar? I’ve been there too.

The designers who nail it in these domains? They’re the curious ones. They’re not afraid to step out of their comfort zones and ask questions — even if they feel clueless at first. And the more they learn, the more strategic they become. So, if you’re feeling lost in a sea of technical terms or can’t seem to make sense of a new domain, today we'll talk about six strategies that’ll help you navigate the chaos — and maybe even enjoy it.

Personal experience

One of the trickiest domains I’ve worked in has been external data platforms, where data engineers handle immense volumes of information. This isn’t your typical app or website. Here, the focus is on manipulating, transforming, and analyzing data, often with industry-specific processes and terminology that can leave even the most seasoned designer scratching their head.

At first, understanding the workflows felt like walking into a room full of people speaking a language I didn’t know. I had to understand not just how the platform worked but how it fit into the larger picture — how data engineers used it, what their pain points were, and how this impacted the businesses that relied on it.

I’m not someone who shies away from tough challenges, so I dove in. The key to my breakthrough? Finding relatable references. Even the most complex workflows have something in common with everyday experiences — whether it's explaining a data pipeline like a plumbing system or comparing intricate business models to something more tangible.

The moment I could relate these concepts to something I already understood, things started clicking. And I found a way to explain what I had learned in a way that made sense to others, too.

1. Start with the basics (seriously)

When you’re dropped into a new technical space, the first thing you need is a game plan. And that plan? It’s all about breaking things down into three key areas:

• The Product: What problem does it solve? Who’s the competition? How does it even work?

• The Users: Who are they? What are they trying to achieve? Where does the product help them — and where does it leave them frustrated?

• The Domain: What’s the foundational knowledge here? Think jargon, workflows, history, and the trends shaping the space.

When I first entered these complex spaces, I felt like I was drowning in new information. So, I started keeping a log of all the technical terms that kept popping up. In my downtime, I’d look them up. Slowly but surely, things started to make sense, and I didn’t feel as lost.

It also helped to sketch out flowcharts and diagrams — visuals to map out how everything connects. This not only filled in the gaps in my knowledge but became a handy onboarding tool for others on my team. Over time, you start to see the relationships between the product, users, and the technical domain, and that’s when things really start clicking.

2. Ask stupid questions

I’ve never been afraid of looking stupid. In fact, asking so-called “stupid” questions has been my superpower in technical domains. Whenever I didn’t understand something, I asked. And the more I asked, the clearer things became.

Coming from a technical background as a developer helped me, too. I knew how things should work under the hood — what made code function and what didn’t. This background gave me a head start when it came to understanding new concepts and figuring out how they applied to the design process.

So, when I needed to learn fast, I asked. I didn’t mind if the question seemed dumb because, at the end of the day, clarity was more important than saving face. And that curiosity opened doors — it led to deeper conversations and a much quicker understanding of the domain.

3. Make friends with experts

One of the most valuable moves I make when starting a project is investing time upfront with the experts. I spend the early days not just sitting in front of a screen but actively engaging with stakeholders, product managers (PMs), and subject matter experts (SMEs). These are the people who live and breathe the product. Their insights give me a holistic understanding of not just how the product works, but why it exists and how it serves the users.

If you want to fast-track your understanding, build relationships with Subject Matter Experts (SMEs) and key stakeholders. These are the people who’ll give you the inside scoop and help you see things from different angles.

At one of my previous projects, I connected with a bunch of sales experts early on. These folks had deep technical knowledge and were working with customers every day. Their insights were pure gold because they weren’t just theoretical — they were based on real customer experiences. Soon, these sales experts became my go-to when I needed feedback on a design or to get a quick pulse on what customers were struggling with.

4. Watch users in action

You can read all the research reports you want, but nothing compares to watching real users in action. Whether they’re stumbling over a task or breezing through it, observing them will give you insights that no amount of desk research can.

Start meeting with your users, and you'll see the shift in your designs. You won't be guessing anymore — you'll design based on real-world interactions.

If you can’t get direct access to users, ask to sit in on calls with your PM or researchers. Even if you’re just a fly on the wall, you’ll pick up invaluable insights.

5. Use the product (actually)

I worked with this designer once who was pretty much a legend in the company. He wasn’t just good at design; he knew the product inside and out because he used it every single day. He wasn’t just designing for users — he was one.

This guy inspired me to dive into the product I was working on. And while it’s tough, especially when you’re working on a product outside of your day-to-day world, using it yourself changes everything. You start to see where the product shines and where it completely falls apart. And when you experience the pain points firsthand, you can design with empathy.

At one of my companies, they had a program where new hires would go through key user journeys and share their findings. This wasn’t just a training exercise — it was a way to ensure that everyone, designers included, was using the product and seeing it from a user’s perspective.

6. Share what you're learning

Ever tried explaining something complicated to someone else? It forces you to make sure you actually understand it. Sharing your learnings with others is one of the best ways to solidify your own knowledge.

When I started on an external data product, I shared things I've been working on with the rest of the design team. What started as a simple presentation led to deeper discussions and even revealed gaps in my knowledge. It made me better.

Don’t worry — you don’t have to become a domain expert. You just need to know enough to advocate for your users and be the voice that connects different parts of the company.

Wrapping it up

Designing for technical domains is intimidating, but it’s also a huge opportunity to grow as a designer.

You’re not just creating pretty interfaces — you’re solving complex problems that can have a real impact.

The trick is to stay curious, keep learning, and never be afraid to ask questions (even if they feel dumb). You’ve got this.

We all have goals, dreams, and ideas. But there's something that separates people who only dream from those who achieve what they want. It's the ability to go from the "aha" moment to taking actual steps to execute goals, dreams, and ideas.

The greatest skill one can develop is decreasing the time between idea and execution. — Dan Koe

If you ever felt paralyzed to execute a project or a goal, waiting for conditions to be perfect — congratulations! You've experienced the Someday Syndrome.

Waiting for everything to align, whether it's resources, time, or a perfect partner, could mean an endless wait. Procrastination and the "someday syndrome" don't only put off our goals, dreams, and ideas; they make them unattainable.

Ideas don't come out fully formed. They only become clear when you work on them. You just have to get started. — Marc Zuckerberg

Why do we delay execution?

There are a few reasons why we delay the execution of our ideas:

• Fear

• Perfectionism

• Procrastination

Fear

Ideas frequently die because of fears about failing, losing time/money or leaving one's comfort zone.

Next time you'll catch yourself in fear of getting started, remember that big dreams require uncomfortable journeys. Fear of uncertainty is natural. Acknowledge it. Accept it. Move on.

Perfectionism (my favorite)

In a world filled with advice on output optimization, the temptation to go on endless iterations is appealing. But you need to learn to avoid using perfectionism as a justification for delay.

Many of us fail to start because we wait for perfect conditions or have high expectations about results.

Strive for progress, not perfection.

Procrastination

Procrastination often comes from a lack of clarity. Even with good intentions, we delay taking action.

We procrastinate for a variety of reasons, including psychological and personal traits. Perfectionism. Fear of failure. Low self-esteem. You name it.

How do we reduce the gap between the idea and execution?

For a very long time in my life, I've been delaying the execution of my ideas for one of the reasons above. I went through all of them. Sometimes a few at a time.

What I learned from this experience was that all I needed was more clarity. Clarity is the key to bridging the idea-execution gap. Clarifying my plan to its essence, and then taking the first step. Complexity often leads me to paralysis. Clarity gave me a sense of direction.

Break down your goals

Taking an overly ambitious first step often results in frustration. We tend to delay tasks that seem too big, complex, or vague. Break down your goals into smaller, manageable steps to reduce resistance and increase clarity.

For example, I break writing a newsletter into steps like research, outline, draft, edit, and publish. Same with design work: research, wireframes, UI design, interactions, handoff.

Embrace imperfection

Perfectionism gets me stuck in endless preparation cycles. I'm trying to account for every possible outcome before moving forward.

But conditions are rarely perfect, and striving for perfection often serves as an excuse for inaction.

Prioritize progress over perfection. This is a mindset shift to help you understand that your efforts don't need to be error-free. Remember that failure is just research unless you never try again.

Leverage accountability

It is easy to put off commitments that only affect you. But most people have a strong desire not to let down those who rely on them. Benefit from this trait and tell about your intentions to someone close who will hold you accountable.

For example, going to the gym by myself has been always a challenge. But once I hired a coach – I showed up every time. All because I had to keep a promise to come to the gym at a time.

You can join a group of people who share your interests or work on similar projects. Such environments make it difficult to give up without facing consequences.

Reducing the gap between idea and execution means developing a habit that converts your ideas into actions. It's a skill that, like any other, can be improved with consistent practice, effective strategies, and the right mindset.

Remember that it's not the idea but execution that differentiates achieving a goal and daydreaming.