What I Learned From Shipping Faster Than I Could Verify

I spent years building a career on the logic that speed always wins. I wore "solo designer" like a badge of honor for three roles in a row. It meant I was hireable: one person who could handle everything so the company didn't have to build out a whole team. I could take a vague problem and have something in front of engineers in a few days. Success was measured by meeting deadlines. We'd ship, move on, start the next thing. That's how startups work, right?

Except in my last role. I was the only designer, hit every deadline, and yet, a year in, I got laid off.

While I can't trace the outcome to a single cause (startups are complicated, and so is failure), I do think there's something in this: I was doing a lot of work, but most of it never shipped.

I’d get what seemed like a clear ask, dig in, and find it was messier than anyone thought. Then something new and urgent would come up, priorities would shift, and… it just wouldn't go anywhere. Almost every sprint.

I still think about one feature I worked on off and on for almost my entire tenure. The company helped retail sellers list excess inventory across platforms automatically. Sellers needed a way to pause their memberships while on vacation. Seems straightforward. But the more we looked into it, the more complicated it got. What happens to inventory when a seller pauses? What if they're one of our largest? Do we cap how long a pause can last? What if they're not ready to relist when they come back? Every stakeholder meeting grew the scope. It never shipped.

Work that doesn't ship doesn't create value, no matter how many deadlines you hit. Had we talked to users early and mapped the business implications, we might have found the real shape of the problem sooner, and made a clearer call on whether it was worth building at all.

The shift: AI made the problem impossible to ignore

But AI tools arrived, and the same dynamic got harder to ignore. When I joined my current company, the team was already experimenting with AI tools. I was scared. Everyone and their dog was talking about what they'd built in Claude Code, meanwhile I hadn't even downloaded it yet. Suddenly I wasn't the fast one anymore. That was supposed to be my thing.

So I raced to catch up. And once I got the hang of it, I could spin up ideas faster than ever, producing prototypes in a fraction of the time. More ideas, more variations, more to show in every review.

The problem became clear the first time I put one of those prototypes in front of an actual user. I watched them struggle with something I thought was obvious. Then struggle with the next thing.

The prototype wasn't bad because it was quick. It was bad because I'd never verified any of my assumptions. I was moving faster, but I was building in the wrong direction. Fast didn't mean good. It just meant more wrong things, sooner. I was drifting, confidently and efficiently, in the wrong direction.

The data backs this up. A 2025 randomised controlled trial by METR found that experienced developers using AI tools actually took 19% longer to complete tasks than those working without them — despite believing they were significantly faster. The study focused on developers, not designers, but the pattern felt familiar: the speed was in the feeling, not always the output.

That's when my thinking about AI shifted. Instead of doing more with the time I got back, I wanted to use it to get things in front of real people before anyone committed to building them. To make sure what shipped was right, not just fast.

What evidence velocity actually looks like in practice

If the argument is that speed without evidence leads you the wrong way, the practical question is: what does evidence velocity actually look like in a fast-moving design workflow?

Getting a real person to try a real task before anyone commits to building it doesn't need to be a formal study. Even a quick session with a research panel will surface things that seemed obvious in the design but fall apart as soon as someone actually uses it.

Every single time I run a session, something comes up. Not most of the time. Every. Time. 

Recently I was designing a folder structure with drag and drop, a feature I thought was a no-brainer. But users were worried it would be too easy to accidentally drag things into the wrong folder. They were right. For the report they were building, that could mess up the whole structure. So I added guardrails before we built it. Easy fix, caught early.

It also changes how you handle stakeholder pressure. When someone insists a feature is critical, you can test it with a few users. If it doesn't even come up, you have traceable evidence to push back. That's conviction grounded in observation, not opinion.

The method matters too. Prototype testing surfaces what people actually do. Surveys and AI moderated research surfaces what they think they'd do. Both are useful, but they're not interchangeable, and the distinction matters when you're making a case for a decision. Many times, you need to include multimodal evidence capture in your research.

At my current job, talking to customers is actually a priority. I'm in feedback sessions sometimes twice a week. The value is learning fast. That shapes what gets built next.

After each session, an AI notetaker scans the call and automatically updates a doc with session notes. Those notes link to a main ideas and opportunities doc, which consolidates insights across sessions. From there, it links to tickets so nothing gets lost between research and build.