Building Fast Is Easy. Building for Someone Else Is Hard.
What happens when one person consolidates product manager, UX designer, and AI-powered development tools into a single role and why outside perspective matters more, not less, when you can ship at speed.
There's a specific kind of pride that comes from shipping something real. Not a Figma prototype someone has to squint at and imagine. Not a slide deck with a screenshot. A thing, a product that exists in the world, that runs on real data, that a real person opens on a real Tuesday morning when they're already behind.
That's what I felt when Maestro hit a state I was proud of. And I had every reason to feel confident. I've spent years in product management and UX design. I've dabbled in frontend development. Python isn't foreign to me. Cursor felt like a natural evolution from the tools I'd already lived in: Atom, Sublime, VS Code. I wasn't starting from zero. I was starting from a running start.
And then, right on schedule, came the reminder I knew was coming but needed to hear anyway.
Why My Background Was Both the Advantage and the Problem
Let me be clear about what AI-powered development tools actually unlocked for me, because it wasn't magic, and it wasn't a shortcut for people without skills. It was a force multiplier on skills I already had.
Because I understood UX, I could design intentionally. Because I'd dabbled in frontend development, I could read what Cursor generated, catch mistakes, and redirect. Because I'd managed products, I knew what questions to ask and what tradeoffs mattered. Cursor gave me the final piece: it collapsed the gap between thinking something up and seeing it exist. Work that would have taken me weeks now took hours. The iteration loop that used to span days compressed into a single afternoon.
One of the most meaningful changes: I skipped prototyping entirely.
That might sound reckless. And to be clear, speed in building doesn't mean skipping the work that happens before building. Market research, competitive analysis, user interviews to validate the problem space, that foundational work is still non-negotiable. What changes is what comes after. Once you've validated that the problem is real and worth solving, why show someone a click-through mockup when you can give them the working product, connected to their actual data, embedded in their actual day?
“If you’re building something where speed is possible, push for working software earlier than feels comfortable. Real-world feedback, the kind where someone is using the thing on a Wednesday when they’re stressed and distracted, is categorically different from prototype feedback given in a calm usability session. It surfaces problems that controlled environments hide.”
My early adopter process reflects this. I run an onboarding interview to capture initial qualitative impressions. I hold ongoing feedback sessions to gauge whether the product is delivering real value over time. And I watch quantitative usage data to see where people go, where they stop, and what they quietly avoid. The combination gives me a three-dimensional picture that no prototype ever could.
Who You Need in the Room
The fastest way to close the gap between what you built and what your users need is to get the right people involved early. Not cheerleaders. Not people who know the product already. People who feel the pain of the problem you're solving and will tell you honestly when the solution doesn't land.
For Maestro, that meant being deliberate about who I invited into the early adopter process. I looked for people who fit the target persona, who lived the problem in their actual day-to-day, and who could give feedback grounded in real use rather than imagined scenarios. One of those early adopters was Deb Biggar, a network contact from my Zipcar days where she consulted on UX and I was on the product side. She brought something particularly valuable: training in human factors. She doesn't just experience friction, she can name it, locate it, and explain why it exists. She spots problems that most users feel but can't articulate.
Not everyone will have access to someone like Deb. But everyone can find users who genuinely feel the pain, sit with them, and listen without defending. That's the core of it.
The Reminder
Any experienced product person knows this: you are not your user. The closer you are to what you've built, the harder it is to experience it fresh. It's not a flaw in your process. It's an inevitable consequence of doing the work.
What Deb's feedback reinforced was exactly that. Not that the product was broken, but that there's always a gap between the mental model of the person who built something and the mental model of someone encountering it for the first time. I'd made hundreds of small decisions about what to show, what to hide, what to leave implicit, all of them reasonable, all of them made from the inside out. Outside perspective is what makes those decisions visible again.
This is why structured feedback isn't a nice-to-have. It's the mechanism that keeps you calibrated to the people you're building for, not the product you've built.
“Find someone who fits your target persona and has no prior context, no briefing, no “let me just explain what this does.” Put the product in front of them and be quiet. This is harder than it sounds. Every instinct you have as a builder will tell you to jump in, to clarify, to save them from the wrong turn. Resist it. That wrong turn is the data. Watch where they hesitate. Watch what they re-read. Notice what they skip. You’re not looking for opinions yet; you’re looking for the places where your mental model and their mental model diverge. Those gaps are your real product backlog.”
What Building for Someone Else Actually Means
Most of us, even experienced product people, design for a version of the user that's a little too patient, a little too curious, a little too willing to figure things out. We know what the product can do, and we unconsciously assume users will discover it. They don't. They scan, they pattern-match against everything else they've used, and they move on when it doesn't resolve quickly.
I leaned heavily on familiar UX patterns to reduce this friction, common conventions that users already know from other products, so the learning curve has less to climb. But even with that foundation, any new product introduces some irreducible novelty. There's always a gap between what feels obvious to the person who built it and what feels obvious to someone encountering it fresh. The goal isn't to eliminate that gap entirely. It's to know where it lives, so you can close it deliberately rather than discover it through churn.
“At every screen, ask not “what do I want users to do here?” but “what does someone expect to happen when they arrive here?” Design for the expectation first. Introduce anything novel second.”
Speed Is the Superpower. Perspective Is the Safeguard.
Having a PM and UX background, some dev experience, and the right AI-powered development tools made it possible to build Maestro faster than I ever could have before. That's a genuine advantage and one that's becoming more accessible to more people every day.
But speed concentrates risk in a way that's worth naming. When one person can design, build, and ship, you gain velocity. You also lose the natural friction of collaboration, the designer who questions an assumption, the developer who flags something confusing, the PM who asks "but why would a user do that?" Fewer perspectives in the room during design and build means fewer chances to catch what you're too close to see.
This is a broader dynamic as roles collapse and solo building becomes more accessible. The efficiency gains are real. So is the risk. And the faster you can ship, the more intentional you need to be about building in the outside perspective that a team used to provide naturally.
Structured user research isn't a tax on speed. It's what makes speed sustainable.
How do you keep outside perspective baked into your process when you're building fast? I'd love to hear what's working.
Follow along as Deb and I go deeper: the AI-assisted build process, the research practices that keep it honest, and what it looks like when speed and rigor work together.
→ Try Maestro: www.maestroyourlife.com
