Last week, I sat in a conference room watching a user struggle with something we’d spent four months building. The feature worked exactly as we’d designed it. But she kept getting confused by responses and eventually gave up with a frustrated “I don’t think this is for me.”
We’d tested the designs extensively. Five rounds of feedback. Users loved what they saw. But a static prototype doesn’t have API delays. It doesn’t show you what happens when the algorithm returns messy results and how people behave when something goes slightly wrong.
We had to redesign about half the features all over again. The problem is that PMs tend to validate what users say they want instead of what they actually do.
Before we go deeper, here’s what’s been stirring in the world of AI.
Latest in Tech
Former OpenAI and DeepMind researchers raise whopping $300M seed to automate science
Periodic Labs came out of stealth with $300 million as a seed round.
Now, bringing it back to the question, why aren’t beautiful mockups enough anymore?
Teams are Moving Faster Than You Think
There’s a growing gap between what users say about designs and how they behave with working products. And that gap is costing us months of development time and credibility with our engineering teams.
I’ve been doing this for years now.
But teams around me are moving differently now.
Notion didn’t launch AI autocomplete by designing every state in Figma first. They shipped a working alpha internally, where the AI suggestions were often wrong. They got to know which suggestions they ignored.
Linear’s command palette went through seven functional iterations before they finalised. They tested the search algorithm. Users could tell them, “This search isn’t finding what I need” instead of “this button looks nice.”
Notice a pattern? They’re all testing user behaviour at the earliest. No one is asking, “Would you use this?”. Instead, they are watching people use something functional, even if it’s unpolished.
When Superhuman was building its keyboard shortcuts system, it built working prototypes and observed how people’s hands moved. They discovered things like how Cmd+K conflicts with browser defaults or how people forget shortcuts if the feedback isn’t instant enough.
Why Design Testing Fails at Behaviour Prediction
After running hundreds of usability sessions, I’ve learned that people are excellent at reacting to visuals.
They’ll tell you if a button feels misplaced or colours feel off. But they’re terrible at predicting how they’ll use something that doesn’t exist yet.
I tested a dashboard redesign last year. In our design testing, users kept saying they wanted everything visible at once. “Just show me all the data,” they said repeatedly. We built it that way. Three weeks after launch, the overwhelming feedback was that it felt.
Stripe learned this the expensive way with their payment form designs. Their design testing showed users wanted inline validation. Looked great in prototypes. But their instrumentation showed users found it stressful and distracting.
They shipped delayed validation instead, which tested worse but performed better in production. The difference was watching real typing behaviour versus asking people what they preferred.
Airbnb discovered its checkout flow design had a fundamental flaw that never appeared in design testing. Users said they wanted detailed property information during booking.
The friction of scrolling under time pressure, something invisible in design tests, was killing conversions.
The gap between “this looks good” and “this actually works for me” is huge. It’s a fundamental limitation of testing non-functional prototypes.
The Handoff That Works
The smoothest handoffs have always been the ones where I could show something that already worked, even barely.
When you hand a Figma file, you’re documenting 60% of the product. The other 40%, what happens when the API times out and how validation errors behave, are decided in implementation.
Sometimes, engineers make the same calls you would have. Often they don’t, because they’re optimising for different constraints.
But when you hand over something functional, even if it’s held together with duct tape, those decisions are already there. Engineers can see what you meant.
How I Turn Ideas Into Real Apps in Minutes
So here’s what I’ve started doing over the past few months, and honestly, it’s changed how I work.
I’ve been using Emergent. If you’ve never heard of it, it’s an Indian startup that’s growing insanely fast, over 1.5 million apps created in just three months, 1M+ users across 180 countries, and $15M ARR, with $23M in Series A funding.
You can build a full working app in under five minutes. Front end, back end, integrations, everything. No coding, no tech team, no Silicon Valley budget required. Just describe what you want to build in plain English, press enter, and your app is live. Production-ready, scalable from day one.
I’ve been using it to prototype functionality early, but more than that, it’s letting me ship ideas, something I could never do alone before. I deploy it, share it with my audience, and keep iterating. The coolest part is that you don’t need a technical background. Anyone can take an idea and make it real.
If you’re sitting on an idea you’ve been wanting to launch, try it.
Build it. Ship it. See it live. That’s how I’m working now, and it’s a game-changer.
I prototype functionality earlier now. Instead of designing everything first, I build rough working versions of the riskiest parts. If the core interaction doesn’t work, I want to know before we’ve designed all the edge cases.
I test with real data whenever possible. Connected to actual APIs, even if it’s messy. Users behave completely differently when they see their real information versus placeholder text.
And I’ve learned to scope ruthlessly. You don’t need to prototype everything. Just the parts where you’re genuinely uncertain. The parts where user behaviour might surprise you.
Airtable’s product team has done this for years, prototyping heavily in their own tool before building native features. Even Apple, despite its famous secrecy, does extensive internal testing with rough working prototypes before finalising designs.
My Challenge to You
Take something you’re working on right now. Something where you’re not completely sure your solution is right, but you’ve designed it and it looks solid on paper.
Go to Emergent and describe what you want to test, spend a couple of hours seeing what it generates.
Then put it in front of three people. Don’t guide them. Don’t explain anything unless they’re truly stuck. Just watch.
You’ll learn something that would’ve taken weeks to discover the traditional way.
The gap between what users say and what users do is always going to exist. But we can shrink it by testing things that work instead of things that look like they work.
P.S. If you end up trying this, whether with Emergent or another tool, I’d genuinely love to hear how it goes. What did you build? What surprised you? Reply and tell me about it. I read all your messages.
📍 Bengaluru | 🗓️ Nov 15 | 🎟️ Invite-only
The stage is set for the homecoming of the world's best product builders, with 350+ senior product leaders, tech founders, and growth executives, 50+ speakers, and 10,000+ registrations comes every year. Forget boring panels, here you'll get hands-on playbooks and raw conversations with the sharpest minds in product.
CXOs shaping billion-dollar strategies are coming together under one roof to learn and build. 🚀
If you're making product decisions that matter, this is where you need to be.
GrabChai South Bay Edition: AI Buildathon with Rocket 🚀
📍 South Bay, CA | 🎟️ Free (Invite-only) | 🗓️ Tue, Oct 14 | ⏰ 6–8 PM PDT A hands-on evening where ideas turn into prototypes. Build fast with AI, swap stories with peers, and wrap up with demos (chai included).
