there’s a specific kind of tired that comes from scrolling through AI posts.

it’s not the tired from doing too much. it’s the tired from watching others do too much - or at least, appearing to. every day there’s a new tool, a new workflow, a new “i built this in 10 minutes with AI” post. and somewhere between the third and fourth one, a quiet guilt starts to creep in.

am i keeping up? should i be trying that? why haven’t i tried that yet?

i’ve been feeling this a lot lately. and what makes it harder to shake is that it doesn’t just feel like missing out on tools, it starts to feel like missing out on who you’re supposed to be becoming.

i’ve always thought of my strengths as a designer in pretty specific terms: i move fast, i have good taste, i can articulate ideas clearly. those things felt like mine. but lately, scrolling through what AI can do, those same strengths start to feel... negotiable. you think you iterate fast? AI can prototype 20 directions in five minutes. you think your taste is sharp? there are tools that have consumed more visual references than you’ll see in a lifetime. you think you write and communicate well? you know.

it’s a strange kind of identity erosion. slow, quiet, and hard to name until you’re already in it.

think of AI less like a revolution, more like a new tool

i was talking to a friend about this the other day, and something they said reframed it for me in a way i haven’t been able to shake.

they said: think about AI just as a new tool, nothing more.

which, yes, obvious. i know. but hear me out, because i don’t think we actually believe it, even if we say it.

the narrative around AI right now is macro. it’s civilizational. people talk about it like a third industrial revolution, like the steam engine, like electricity. and that framing does something to you. it makes the stakes feel enormous. it makes “not trying every new product” feel like falling asleep at a historical turning point.

but here’s the thing about the steam engine: people didn’t interact with steam directly. they interacted with specific machines that happened to run on steam. and different trades used different machines. a tailor didn’t need to know how to operate a locomotive. a carpenter didn’t need a textile loom. each person just needed to know: what am i trying to make, and what’s the best tool for that job?

that’s it. that’s actually the whole thing.

when i shifted to that frame from “i need to stay current with AI” to “what’s actually missing in my workflow right now?”, the anxiety didn’t disappear, but it got smaller and more specific. suddenly i wasn’t scrolling to keep up. i was looking for something. am i finding good inspiration? am i exploring enough directions before committing to one? am i communicating with engineers as clearly as i want to? those are real questions. and they point to real tools, not just the newest ones.

choosing a tool becomes a design problem. and design problems, i know how to sit with.

and when you pick the right tools - the ones that map to what you’re actually trying to do - something shifts:

it no longer feels like AI is replacing what makes you good, it’s more like AI is augmenting what you’re good at.

i heard Jamey Gannon describe this recently: she's using AI not just to do her job faster, but to go deeper into her own style, to expand what was already distinctly hers, and to articulate her style in a more visual way. that reframe stuck with me. that shows a different relationship with the tools, and a different relationship with yourself.

the posts are not the work

but there’s a second layer to this, and it’s the one that’s honestly harder to admit.

a lot of the anxiety isn’t really about the tools. it’s about the posts.

the people online who are constantly sharing their AI experiments, their new workflows, their “vibe-coded this in an afternoon” projects. watching them makes you feel like you’re behind. like they’re living in the future and you’re still catching up.

my friend put it simply: those posts are like people wearing lululemon at the gym and posting about it.

not everyone who posts their workout outfit is the most dedicated athlete. and plenty of serious athletes never post anything at all. the post is a signal - part personal brand, part performance, part just... how some people process their enthusiasm publicly. it’s not an accurate map of who’s actually putting in the work.

and when i actually sat with that and really reflected on it, i realized: i am learning. i am trying new things. i use AI in my process more than i did six months ago, more than i did last year. i’m just not documenting it publicly. i’m not building a brand around it. and somehow, somewhere along the way, i started confusing visibility with effort.

it’s the same trap as comparing your worst to other people’s best. just a new context.

be more intentional, not more informed

i don’t think the feeling fully goes away. the pace is genuinely fast, and some of the uncertainty is real, not imagined.

but what’s actually helping me is getting more intentional about it. less doomscrolling about “what is AI doing to the industry” and more reflecting on “what do i need to make better work this week.” less scrolling for coverage and more asking what’s actually missing.

and i want to be clear - this isn’t about stepping back from AI. i’m still curious. i still want to explore, experiment, try new things. that part hasn’t changed.

what i’m trying to change is the energy i bring to it. less frantic, more grounded. less “i have to try this or i’ll fall behind” and more “i wonder if this could help me do what i care about better.” that shift is small but it changes everything about how the exploration feels.

the goal was never to keep up. it was always to do good work. AI doesn’t change that. it just gives us more to be intentional about.

and if you’re feeling tired right now, same. but i don’t think that means we stop. i think it just means we get to choose how we move forward.

now to the new article:

I’ve been thinking about the phrase “design process” a lot lately, and why the “HCI way” is failing designers in practice. I keep hearing the same story from portfolio critiques, interviews, and friends who graduated from great HCI programs: the methods are useful, but the promise doesn’t match the job.

You know the diagram:

Research → Personas → Ideation → Wireframes → Testing → Hi‑fi → Ship.

And I get why people love it. It’s clean. It’s comforting. It makes design feel predictable.

But the longer I work in industry, the more I think that diagram is being taught wrong. School gives you real methods, then sells them like a linear recipe - when in real life they’re a toolbox. And if you internalize the recipe, you start to feel like you’re “doing it wrong” the moment reality gets messy.

The tension: methods are real, the recipe is not

I don’t want to do the edgy “school is useless” take. I actually think design education is valuable.

It gives you the tools. It shows you what exists:

• interview techniques

• usability testing

• heuristic evaluations

• journey maps

• personas

• competitive analysis

• prototyping

• experimentation frameworks

• design principles and conventions

Even if you never use all of them, it matters that you know they exist. You can’t pull a tool you don’t know is in the drawer.

So that’s part one of the solution:

Part 1: You need the tools

You need the vocabulary, the methods, the fundamentals. You need to understand why conventions exist. You need to be able to look at a problem and go, “Oh, this is the kind of situation where talking to users could actually change the decision,” or “This is the kind of problem where I need to prototype because nobody can reason about it in words.”

Design education helps with that. It builds your toolbox.

But there’s a second part that matters just as much, and it’s the part I think school is way worse at teaching:

Part 2: You need to know when and why to use each tool

And the word I keep coming back to for that is intentionality.

It’s the part where you’re clear about:

• Why you’re doing something

• What you’re trying to learn

• What decision it unlocks

• What risk you’re trying to reduce

• What would change your mind

Intentionality is basically the difference between doing research because “process says research comes first” and “we’re about to commit engineering time and we’re missing a key piece of truth”

Same method. Totally different energy.

And honestly, without intentionality, the toolbox doesn’t work. You just end up making artifacts because artifacts are what you’re supposed to make.

The contrast: the diagram vs. how work actually shows up

Traditional HCI teaching loves the clean storyline. It’s neat. It’s presentable. It’s portfolio-friendly. But real work, at least the real work I’ve experienced - usually starts as confusion.

It starts as messy prompts like:

• “We need onboarding.”

• “Users don’t get it.”

• “Sales is losing deals because of X.”

• “This feature is table stakes now.”

• “Retention dipped, can you look into it?”

None of that is “step one: research.” It’s just… a foggy situation someone wants you to un-fog.

And this is where intentionality changes everything.

Because when you start in confusion, “process” isn’t about producing the right artifacts in the right order.

It’s about moving from fog → clarity.

If confusion is the starting point, then step one isn’t personas.

Step one is questions.

Not performative questions. Not “for the workshop.”

The slightly annoying questions that force the situation to become real:

• Why are we doing this now?

• What problem are we actually solving?

• Who is this for, specifically?

• What does success mean?

• If we ship nothing, what breaks?

• What are we assuming that might be wrong?

• What decision are we trying to make by Friday?

This is what I mean by intentionality: you’re not just “following process.” You’re trying to unlock the next decision.

And then, and only then, you choose a tool.

Sometimes the right tool is interviews. Sometimes it’s competitive teardown. Sometimes it’s analytics. Sometimes it’s prototyping. Sometimes it’s just writing down the decision tree and getting alignment.

The point is: intentionality is the bridge between “I know methods exist” and “I know which one to use right now.”

What intentionality looks like in different orgs

Once I frame it this way, the differences between agency/startup/big tech stop feeling like “they don’t follow process” and start feeling like: they’re using the same toolbox for different reasons.

Agency: intentionality is narrower (because upstream decisions are pre-made)

In an agency, the “why” is often already decided.1

The client or founder gives you a prompt, the constraints, the timeline, sometimes even the opinionated direction. You’re not there to question the existence of the project. You’re there to execute.

So intentionality becomes narrower and sharper:

• How do we turn this brief into something coherent quickly?

• How do we make it feel high quality?

• How do we translate someone’s vision into something real?

The toolbox is still there, but you’re mostly living downstream - craft, speed, clarity, presentation.

And honestly, it can be an amazing craft bootcamp.

Startups: intentionality is about reducing guessworks under uncertainty

Startups are where the fog is thickest.

Prompts are vague. Context is missing. Everyone is moving fast. Everyone is guessing. And the company can’t afford long ceremonies that produce pretty decks but don’t change outcomes.

So intentionality in a startup starts with questions and rapid validation:

• What are we actually trying to prove?

• What’s the smallest thing we can ship to learn something real?

• What would “good” look like in user behavior?

The process becomes less about formal steps and more about reducing guessworks.

Opinions are cheap, prototypes are semi-cheap, but real user behavior is the expensive truth needed. So a lot of “research” in startups becomes things like:

• playing with competitors deeply (not just screenshots)

• reading user complaints and tickets

• watching funnels and retention

• shipping and measuring

• iterating fast without getting emotionally attached

The goal isn’t to do research “properly.” The goal is to make the next decision with less fantasy.

Big tech: intentionality is de-risking at scale (methods as insurance)

Big tech is basically the same toolbox, but used with a different intention.

At scale, mistakes are expensive. A tiny UI change can move real money. It can create PR issues. It can break trust. It can confuse millions of people.

So intentionality becomes: de-risk.

• How do we validate without blowing up the product?

• What’s the smallest rollout we can do?

• What do we need to be confident enough to ship?

This is why big tech can spend weeks (or months) on changes that feel “small.” The process is not discovery for discovery’s sake. It’s often insurance.

Same methods. Different reason.

Intentionality on a project: the onboarding example

Onboarding is the example I keep coming back to because it looks simple on the surface, but it’s secretly a perfect “intentionality test.”

The prompt always sounds like:

“We need onboarding.”

If you treat process like a recipe, you’ll jump to the standard onboarding artifacts and flows, because you’ve seen them a thousand times.

But if you apply intentionality first, you start by asking:

• Why do we need onboarding right now?

• What problem are we seeing - activation, retention, confusion, trust?

• What does success look like? (Completion rate? Activation metric? Fewer support tickets?)

• What do we want the experience to feel like?

• What’s the first impression after the marketing site - do we match that promise?

And those questions unlock a very different space.

Because “onboarding” isn’t just “screens you tap through.” It can be:

• a typical wizard (safe, familiar, efficient)

• a guided tour (more hand-holding)

• progressive disclosure as you explore (less friction, more autonomy)

• a chat-like guide or assistant (more human, more conversational)

• an avatar / character (brand personality)

• a map or “mission” structure (game-y, directional)

• something playful (if your brand can support it)

All of these can technically satisfy “we need onboarding.”

But they communicate completely different things about the product: how confident it is, how serious it is, how human it is, how it sees the user.

Same prompt. Different questions. Different intention. Different outcome.

That’s intentionality in action: you’re not choosing a pattern because it’s the next step in a process - you’re choosing it because it’s the right lever for what you’re trying to accomplish.

Where I’m landing (for now)

I think “design process” is not the steps.

To me, the real structure is:

• You learn the tools (education matters).

• You build intentionality (why am I doing this, what decision does it unlock?).

• Then the toolbox actually becomes useful.

And maybe that’s the whole point:

I’m sure I’ll refine this take later. But right now, this version feels true enough to write down.2

footnote:

i’ve been sitting on this question for a while, and i keep coming back to the same discomfort: most people treat a founding designer offer like it’s a puzzle you can solve with a spreadsheet.

comp, equity, title, remote vs. hybrid.

those things matter, but they are rarely the thing that decides whether the next year of your life feels expansive or quietly miserable.

the question underneath is simpler and harder:

is this a place where my best work is actually possible?

i tend to sort it into five buckets:

1. the founder

2. the team and culture

3. the product and the opportunity

4. the actual role (not the one in the job post)

5. the questions and red flags that cut through the vibe

1. start with the founder, not the product

in early stage, you are not joining “the app” (early-stage startups pivot a lot.) you are joining a founder’s brain, habits, and values.

the quality founders checklist

let’s not focus on the mythic “visionary” sense. instead, focus on things like:

• are they a clear thinker and a good communicator?

• can they share context on why certain decisions are made?

• can they give clear, constructive feedback?

• can they own mistakes and course-correct?

• do you respect them as a person, or only because they are your boss?

it’s more about the fundamental qualities the founder holds, because those qualities will shape your day-to-day work culture: what gets written down, what gets ignored, what counts as “good,” how conflict works, and how decisions get made when the data is messy and everyone is tired.

note on second-time founders

one of the cleanest green flags is a founder who has already been through the first-time mistakes.

not because experience magically makes someone kind or competent, but because they tend to have scar tissue in the right places: they document more, they ship more deliberately, and they know where they tend to get emotionally weird.

i’ve talked to founder friends who made me realize being a founder is like any occupation: you learn a certain set of skills over time that makes you better and better at the job.

“design-aware” founders

i’ve started using “design-aware” as shorthand. it’s not about taste. it’s about respect.

design-aware founders usually:

• see design as a business lever (brand, marketing, product)

• don’t make you fight for the concept of design

• intuitively understand how design debt compounds

• understand where their role ends and your role begins

if early conversations feel like you’re defending the value of design, assume that is the baseline. it does not get better after the honeymoon.

questions i ask founders

• “walk me through a recent hard product decision. how did you make it?”

• “what did you ship that didn’t work? what did you learn?”

• “what do you need from me as your first designer?”

it forces the relationship out of the “deliverables” frame and into the “working system” frame.

2. the team and culture you’re walking into

even at five people, culture already exists.

how do i know if a team has good culture? i listen for how decisions get made:

• do they talk about customers and trade-offs?

• how are decisions documented, shared, and revisited?

• do they make space for disagreement early, or do they override late?

the best teams i’ve been around have one quiet trait: they create shared reality. the work feels hard, but not confusing.

of course, the premise is that you’ve established trust with the team. the core difference to figure out is whether the team trusts you by default, or forces you into constant self-defense and validation. the former creates safety. the latter creates uncertainty and self-doubt.

patterns of dysfunction i watch for

• role churn without clarity. designers get moved around like a spare part.

• leaders overriding months of work late, especially if they were not involved earlier.

• isolated designers. standups shrink. “huddles” happen without you. you become an execution layer.

if you are going to be the designer, social and structural isolation is not a minor issue. it is a slow suffocation.

and most importantly, not being involved in those conversations means you will not have the context you need to build the best product.

questions i ask about team and culture

• “who is in the room when design trade-offs are decided?”

• “can i talk to an engineer and a pm about what it’s like to work here?”

• “what is the team struggling with right now?”

• “how often do you talk to customers, and who leads that?”

3. don’t ignore the product, but don’t overweight it

the product matters. but remember that you are most likely not going to work in one industry or product space forever. you need to think about what you can get out of the experience.

what i actually care about:

• does it have real users with real pain?

• is there room for end-to-end ownership?

• will i develop portable skills, not just company-specific context?

figure out if the experience will be meaningful to you

a meaningful startup journey isn’t “i worked in a big market.” a role can look impressive from the outside and still feel strangely narrow from the inside.

i try to ask myself these questions:

• will this domain still feel interesting after the novelty fades?

• do i deeply resonate with the problems my users face every day?

• is this work i will be proud to explain in detail two years from now?

• does this let me practice end-to-end product thinking, or am i decorating fragments?

and a couple of things to ask yourself now to evaluate your current role:

• what did i own?

• what changed because of me?

• how did i handle ambiguity?

if i can’t tell a coherent story in my head, it’s a sign the scope might be noisy rather than meaningful.

4. get clear on the role you’re actually signing up for

founders say “founding designer” and mean:

brand designer + marketing designer + product generalist + design lead + “someone who can make it look good fast”

if you don’t force clarity early, you will do all of them with no boundaries.

two axes i keep returning to

→ type of design

• brand and marketing: systems, narrative, web, decks, coherence

• product: either strategic and user-focused, or visual and systems-focused

→ type of impact

• capacity: someone to handle volume

• craft: someone to raise the bar

• future leadership: someone to build a function and eventually manage

when a founder says “we need a founding designer,” i want to hear which box they are actually trying to fill.

the growth ceiling question

this is the one people avoid asking because it feels awkward. ask it anyway.

• “if things go well, what does my role look like in 12 to 24 months?”

• “what would have to be true for me to become head of design here?”

• “have you promoted someone into leadership internally before?”

if the answer is vague, treat it as a real answer.

5. due diligence that isn’t just vibes

a founding designer role is a risk. sometimes it is a good risk. but i want it to be a seen risk.

talk to people inside the company

• “what happens when you disagree with the founder?”

• “how is success measured here?”

• “show me something important you shipped in the last six months. why did it matter?”

• “is there a roadmap i can see? how often does it change?”

• “what did you plan but not ship, and why?”

i listen for shared priorities, respect for design, and whether people sound depleted or energized.

talk to people who left

this is where the real story usually lives.

• why did they leave?

• what was the founder like under stress?

• did they feel listened to?

• would they work there again?

if you join: how to make the role survivable (and good)

choosing the environment is half of it. the other half is how you operate once you’re in.

collapse ambiguity through daily collaboration

early-stage misalignment is expensive. i try to keep the feedback loops tight:

• show progress daily (even rough)

• iterate in small segments, not big reveals

• get real customer feedback early

it builds trust. it surfaces disagreements before they calcify.

build product sense by using real products

i don’t think you can develop taste or intuition purely from screenshots.

use competitors end-to-end.

notice where they over-promise and where the product actually delivers value. capture patterns you like, but also where those patterns break under real usage.

protect long-term trajectory

i keep coming back to career compounding.

each role should do at least one of these:

• deepen craft

• expand scope

• set you up for the next step

even without a ladder, you can still create one for yourself by documenting impact and setting clear expectations about growth.

closing

being a founding designer can be one of the fastest ways to grow. you touch everything. you see how decisions are really made. you build a body of work that reflects both craft and judgment.

but it only works if the environment is one where your best work is possible.

you will never have perfect information.

still, you can have better questions.

use your design instincts on the company itself. treat the founder and team as your “users,” and the job as a product you’re about to adopt.

saying no to a misaligned role is not cowardice.

it’s just good design.

Six Years In

This year marks my sixth year as a designer. That’s almost a quarter of my life spent doing this. I still remember when I first started—those early days felt like a honeymoon phase. I was so happy, so hopeful. Every day brought new challenges, new things to learn, and I felt like I was on a one-way track to getting better and better. I was hungry. I wanted to be the best—literally. I imagined becoming the next Jony Ive, Paula Scher, or Paul Rand. I pictured myself at Apple, defining the interface trends of the next decade. Or at IDEO, bringing design thinking into Fortune 500 boardrooms. Or maybe at Pentagram, crafting the visual system for the next Public Theater.

Fast forward to today. I’ve worked at tech giants and startups. I’ve shipped products that drove real revenue. I started my own design studio and collaborated with startups around the globe. Objectively speaking, I’m on the right track. I should be proud of myself.

But somehow, this year, I’ve been carrying around a lot of negative feelings. And what surprised me most was realizing that you can feel lost and frustrated even when doing something you’re deeply passionate about. I couldn’t make sense of it, so I needed to write these emotions down and start unpacking them.

👨🏻‍💻 The feeling that I’m not trying hard enough

I’ve always thought of myself as a pretty hard-working person—and I think my friends would agree. I used to spend tons of time outside of work on side projects, just because I wanted to.

But lately, this gnawing feeling of not working hard enough has been creeping in—and it only gets louder when I scroll through Design Twitter. There are all these insanely talented people in their early 20s, building impressive things, constantly experimenting, trying new tech, and sharing openly online. I’m genuinely amazed by their energy, their consistency, and the growth they’re showing.

It’s like I’m being teleported back to 22-year-old me, sitting in a quiet corner of the school library, watching a group of peers who seemed years ahead, thinking: Dude, you’re falling behind. If you want to be great, you’ve gotta push harder.

It’s a strange blend of anxiety and motivation. And then I snap back—now 27, working full-time, dealing with adult responsibilities, chores, and a much different reality.

I can’t help but feel a little defeated. If I felt behind when we were the same age, how should I feel now that I’m five years older than some of them? How do I catch up? When will I become the designer I once dreamed of being? Is that dream still feasible? Should I stop dreaming and be practical? But what does being "practical" even mean?

And perhaps the hardest part: I feel frustrated that I can’t just flip a switch and change everything. It feels like my current reality no longer supports the version of me I wanted to become.

💞 The lack of design companionship

What is design companionship? To me, it’s a group of people you feel comfortable sharing your works in progress with—not just the polished end results. It’s the people you build things with, feel inspired by, and spend enough time around that you don’t need to explain yourself anymore. It’s kind of like your best friend from the art studio.

Don’t get me wrong—I genuinely enjoy solitude. I love riding my bike, reading, listening to podcasts, watching movies. In those moments, I feel like a sponge, soaking up thoughts, emotions, and everyday beauty. But the creative process is different.

Being creative isn’t easy. Sometimes I’m not motivated. Sometimes I feel stuck on a project. Other times I get so deep down a rabbit hole that I lose all perspective. And there are days when I’m just tired and want to skip the work altogether. This is when that companionship keeps us motivated, by believing in others we believe in ourselves.

However, moving to a new city and working at a startup definitely doesn’t help build that companionship. And in work settings, it’s hard to form that level of connection—people are busy, and even if they share the same passion, the time just isn’t there.

Right now, design companionship almost feels like something that comes from either your partner or your closest friend. But then again, is it too much to expect that from a life partner? How likely is it that someone could be both a good partner and a creative collaborator? Judging by some of the well-known design couples and my personal relationship… the odds seem low.

So honestly, I don’t know if that’s something I’ll find again. It feels like one of those past lives I can’t quite return to, and I just need to get used to it.

💭 The feeling of not being creative enough

Let me clarify: I don’t mean I’m not creative. I just mean that lately, I haven’t been impressed by my own creativity.

Scrolling through social media feels like self-inflicted torture. All these brilliant creators—their work screams genius. And there I am, feeling like a kindergartener holding a crayon. The self-doubt tornado hits hard. Am I just fooling myself? Is this whole “unique voice” thing just a comforting lie I’ve been telling myself?

But then i wonder: can creativity really be a competition?

I started breaking it down. Creativity has two parts: the spark and the flame. The flame is the act of creating—it’s like meditation. Pure. Quiet. Focused. Whether you’re painting the Mona Lisa or doodling in a notebook, that process is sacred.

What I was actually envying wasn’t other people’s work—it was their spark. Their ability to connect dots I hadn’t even noticed. Their clarity. Their perspective. Their imagination.

Then I remember this quote I once stumbled upon:

So instead of drowning in the comparison quicksand, why not build my own creative muscles?

And just like that, the fog started to lift. I could learn how to think more creatively, train my perception, sharpen how I express ideas. That became my North Star. As long as I keep moving forward, I’m not just admiring others—I’m becoming someone I’d admire.

That “uniqueness” I was chasing? It’s not some mythical unicorn anymore. It’s real. It’s built one small step at a time, and I guess I already started running.

🌱 I don’t have all the answers… yet

If you’re hoping for a motivational ending where I’ve solved everything—sorry. This isn’t that kind of post. These are just emotions I’ve been carrying, finally starting to unpack.

But here’s what I’ve realized:
Most of these feelings come from comparison. Comparing my progress, my skills, my life to someone else’s. And honestly? That comparison isn’t fair. I might be the best Formula 1 driver out there—but I’m not winning if I’m driving a Formula 3 car.

So yeah, I still feel these things. But they don’t destroy me anymore. I used to spiral into self-criticism. Now, when those feelings surface, I try to take others out of the equation. I ask myself: Am I a better version of me than I was a year ago?

I try to evaluate myself as a whole human being—not just a designer. And honestly? I’m proud of the progress I’ve made, considering the circumstances.

I’m starting to understand that the emotions we have around our careers are never just about work. They’re reflections of our whole lives. We wear many hats. Our professional identity is only one of them. And it’s impossible to get everything right all the time.

So if there’s one takeaway here, maybe it’s this:

Never evaluate yourself by just one label. When you feel defeated in one area of life, look at the other parts of you that have grown. Ask yourself how you’ve shown up as a person. How you’ve lived.

I don’t have all the answers. But at least I’m naming the feelings.
And I’ll keep going on this journey of figuring it out.

End note: If these thoughts and feelings resonate with you, feel free to reach out via twitter, I would love to connect and talk more! If you have a designer friend, share this post to them and it might help them know they are not alone in this journey <3

Share

Hi there! I’m a senior product designer and creative director at Rootly, a YC-backed SaaS startup working on the incident management solution for tech companies. In the past year I led design of our On-Call product from 0 to 1, and now Rootly On-Call is used by companies like NVIDIA, Rivian, and LinkedIn. I learned a lot along the way and want to share some key learnings with you. I hope these are helpful for designers who are also working in startups or building 0 to 1 products <3

For those unfamiliar, Rootly On-Call is an alerting tool that helps engineering teams quickly identify and respond to system issues while improving overall reliability. Just like how hospital teams coordinate schedules and receive urgent patient alerts, Rootly On-Call ensures the right engineers are notified and can respond immediately when systems need attention.

A "good enough" product that's out there collecting real feedback is worth infinitely more than that perfect masterpiece sitting in your Figma.

"I never have time to perfect my design, it's frustrating." This is what I’ve heard from many designers. Well, I’m kind of a designer myself, and imo “perfection” can be your worst enemy, especially when building a 0-1 product.

Consider this: If you're just starting to build a product with no users, how can you know what "perfect" means? Imagine spending a year crafting your "perfect" product, only to discover that potential customers are locked into long-term contracts with competitors—or worse, that users don't even need what you've built. Therefore, getting users is the key here. Get your product out quickly, gain some early traction, collect real user feedback, and iterate. This process will validate your early assumptions, help course-correct, and take your product to a level you couldn't even imagine.

In practice you might still have the urge to try the million brilliant ideas swimming in your head. To be clear, I’m not saying you should not explore at all, but you are no Doctor Strange, and customers won't wait forever for your product launch. In this case, it’s important to remember getting your creation into users' hands ASAP is the way to bring the most value to your team, and it takes practice to find that balance between quality and velocity.

Think of product development as an exciting journey rather than a search for some elusive "perfect" solution. Be bold, make decisions, ship features, and let your users guide the way. Your success isn't about getting everything right on day one - it's about how quickly you can learn, adapt, and itearate based on real customer feedback. Many of our most impactful and game-changing features in On-Call was far from perfection in the first attempt, they emerged from this iteration > perfection mindset.

You don’t need to be the smartest in the room. Be humble, be curious, ask questions.

When I first started designing our on-call product, I had no idea what on-call or alerting was. I felt like the least knowledgeable person in the room. But I wasn't ashamed of not knowing—after all, I'm not an engineer and have never been on-call. What would have been truly shameful was pretending to know and building a product based on guesses and assumptions.

We all experience imposter syndrome. Especially when surrounded by domain experts, it's tempting to pretend we understand things to avoid looking inexperienced and dumb, or being judged.

From my experience, though, people actually appreciate fresh eyes and new perspectives. Deep familiarity with a domain can sometimes create blind spots, and "dumb questions” help us take a step back and think about why we build things in the first place. It keeps us grounded.

Be comfortable to admit what you don't know and embrace curiosity and humility. Ask questions. Ask the magical "why." I've gained countless valuable insights from our customers, founders, and sales teams just by asking questions. These conversations helped me paint a more complete picture of the problem we're solving, the challenges of the existing tools, the market sentiment, and opportunities we have.

Also asking questions shows you truly care, and your team will love you! — what is more lovable than a good listener?

Hand off collaborate with your engineers

I’ll say it: there should never be a "handoff." The term implies that once you pass your design to an engineer, it's no longer your concern and entirely their responsibility. This creates an unnecessary divide between designers and engineers.

Instead, we should view the engineer-designer relationship as a true collaboration. While our expertise and responsibilities differ—and our involvement naturally shifts as projects move from ideation to implementation—I've found it invaluable to stay engaged in the engineering process. This means understanding which parts of my design cause confusion, what lacks documentations, what design is hard to implement, etc. These moments provide opportunities to reflect on product and design decisions, learn about technical constraints, and build trust with your engineers (after all, you're building buddies!).

When you start truly collaborating with engineers, you'll naturally begin considering things like implementation complexity, potential points of confusion, and what design decisions need clearer documentation. You will find the collaborations is smoother, the implementations are more precise, and everybody is having fun along the way :))

Go-to-market (GTM) matters just as much as building

Over the past year I've built tremendous respect for our GTM and sales team. They excel at demoing our product and providing insightful feedback for improvements. What impresses me most is their ability to help customers recognize their challenges and understand how our product adds value to their team—whether through cost savings, vendor consolidation, or specific features. This has taught me that communicating your product's value to customers is just as crucial as building the product itself.

If building a product means creating solutions, then GTM is about finding people who need those solutions. As ppl say, “you can't help someone who don’t think they need help”. That's where GTM shines — they help potential customers understand their challenges, identify their core needs, and see how your product could bring value to them. This process helps you find the customers who will actually pay for your solution. With good product and good GTM motion, you get your growth flywheel!

GTM is equally important for existing customers. When you already have users, retention depends on delivering lasting value. By effectively communicating new features and their benefits, while showcasing your product's continuous evolution, you build enduring trust with your customers.

But how does this impact product and design? When defining problems and designing solutions, we should put ourselves in the GTM team's shoes. Ask: What value does this feature bring? How will customers benefit? Can we make it more appealing to sell? Having early conversations with the sales team is crucial—the closer you are to understanding the problem, the better solution you'll create.

This mindset also reveals an often overlooked opportunity in design: in-app product updates. While we commonly see changelog updates and website hero sections, what about the product interface that people use daily? There's huge potential here. Communicating feature updates and value within the product itself is incredibly effective since that's where users spend most of their time.

Focus on the outcome, not the responsibilities

Early days in my career i got caught up in debating job titles and specific responsibilities. But I've learned that these labels can actually limit our potential and impact. What truly matters is the outcome we deliver - creating exceptional products that solve real user problems. When we focus on the end result rather than rigid role definitions, we free ourselves to learn new skills, cross traditional boundaries, and do whatever it takes to achieve success. This mindset shift has been transformative for me. Instead of asking "Is this part of my role?" I ask "Will this help create a better product?" This approach not only leads to better results but also accelerates personal growth and learning.

Building a 0-1 product is an incredibly humbling journey. Every day, I'm designing the most impactful product I've ever created and solving the most complex problems I've encountered. These experiences have fundamentally shifted how I work, what I value, and the mindset I bring to work each day. They've helped me navigate the ambiguity and fast pace of building something new. I hope you find these insights helpful as you build the next big thing. You got this!!!

PS: Shout out to the many designers whose stories help me realize I'm not alone in facing these challenges. Their perspectives illuminate where we are as an industry and how our mindset evolves with it. I'm grateful to those who share their experiences, and I strive to become someone who shares and inspires as well <3

Also attaching some Dive Club episodes that I find echoes the main points of this essay: