Today’s post is sponsored by Dazl — an AI platform purpose-built for product managers.
We’ve all been in some version of this meeting. A 60-minute UX review is running late. The team is poring over different approaches to the same problem. Each approach is plausible. None are provable. The meeting ends in frustration, without a decision.
In a previous post, You might be doing user research wrong, I argued that user research questions come in three flavors:
Recall questions: What did you do?
Imagination questions: What would you do?
Narration questions: What are you doing?
User research is trying to predict the future: what will customers do when we put our shiny new product in front of them? The temptation is to just ask them — what would you do? But imagination questions are the least reliable of the three. Users predict their own behavior about as poorly as we predict it for them.
Good product sense is one solution. It’s a kind of precognition that draws on pattern recognition from years of watching real users. But precognition has a failure mode. When the question is hard — no clear right answer, no obvious precedent, no behavior to recall — product sense devolves into guessing.
I had this type of question recently while working with a startup building an AI-powered news reader. The company has a cold start problem: they can generate great recommendations once they know what users care about — but they need to learn that during onboarding.
They had a taxonomy of over fifty topics across eight categories, and we were caught in a classic debate. Should we collapse topics into categories that users drill into, or show one long scrolling list? Both approaches were defensible. Static wireframes couldn’t tell us which would feel right. We were stuck in our own version of Minority Report — competing visions of the future, no way to verify which would play out.
In the past, we’d have disagreed, tossed a coin, and committed. That’s a guess in disguise. Now, in minutes, we can build prototypes of multiple variants. We can test them ourselves. We can put them in front of customers.
Dazl is one of my favorite new tools for exactly this. It’s purpose-built for product managers — designed to be a teammate across the full product lifecycle, from a first prompt to a handoff-ready prototype. Instead of bouncing between separate tools for PRDs, design, and prototyping, you stay in one place and keep everything in sync.
I gave Dazl a short prompt. Its plan mode generated an editable PRD — feature spec, layout, structure — that I could iterate on before any building started. Within minutes, both versions of the onboarding flow were live: a collapsible topic tree and a long scrolling list. The conversation leveled up from guessing to a discussion grounded in working software — software we could put in front of anyone on the team, or in front of customers.
Suddenly we weren’t guessing; we were validating.
That first prototype was just a starting point. As soon as we wanted something more sophisticated — a real design system, a brand voice, a second variant to compare against — the prototype needed more context than a single prompt could carry. This is where Dazl’s Documents feature earns its keep. You can bring in PRDs, brand guides, design systems, even competitor screenshots as first-class context the AI references while it builds.
In our case, the PRD already lived in Notion. Rather than copy-paste it into a prompt, I connected Dazl to Notion through its MCP integration and pulled the spec in live, so Dazl was working from the actual source of truth, not a stale snapshot. One instruction — update the prototype to match this spec — was enough for Dazl to reconcile what we’d built with what the PRD called for. The second variant, the brand’s tone of voice, and the full design system all landed in a single pass. The prototype stopped looking like a generic AI-generated screen and started looking like the product.
Skills are the other lever that matters as prototypes grow. They’re reusable mini-tools you define once and apply across the whole prototype. The brand guide called for witty, on-brand copy, so instead of hand-editing every headline and button label, we built a witty copy skill once and ran it across all the topics and categories in a single prompt. Once a skill exists, you can pull it whenever you need it instead of re-prompting the same intent over and over.
And then something better happened. While clicking through both variants on mobile, someone noticed neither was using horizontal space well. They suggested a third option: pills. Compact, tappable tags grouped under each category. We added it. Three variants, side by side.
Nobody had wireframed the pill version. It hadn’t appeared in the spec. It emerged from interacting with the first two. The act of building generated an option that no amount of arguing would have surfaced.
This is what painters have always known. They don’t compose in their heads. They sketch — fast, cheap, disposable — to find what works through doing rather than imagining. Sketching is how composition reveals itself.
Product builders haven’t had this. We’ve had specs, which are abstract. We’ve had static designs, which miss interaction. We’ve had MVPs, which are often neither minimal nor viable. So we’ve defaulted to talking (guessing) about what we’d build instead of building to find out.
AI has changed the math. AI prototyping lets us sketch with software. Building is finally cheap enough to use as a thinking tool.
One more thing made the whole loop feel sustainable: Dazl runs in both directions. Once the PRD was loaded as a Document, I could also ask Dazl to update the spec to match the prototype — pulling the new pills variant, the updated copy, and the latest UX details back into the PRD. The spec stopped being a snapshot from week one and started behaving like a living document that tracked what we were actually building.
The newsreader team picked the collapsible version. Sketching told us what we couldn’t have known otherwise: the expanded list felt overwhelming. The pill version was clever on desktop but no better than the long list on mobile. The exercise took less time than the debate would have. And because the variants were real working software, we could publish them and put them in front of users to measure which UI people preferred, which led to more topics selected, and which felt least overwhelming — turning a UX debate into a test we could actually run.
If you’ve prototyped before, you’ve felt this shift. If you haven’t, here’s the move: next time your team is locked in a UX debate, stop arguing and build both. Dazl is a great tool for this. Most AI tools work outside your process, making it difficult to keep everything aligned. Dazl is spec-driven, so as your PRD evolves the prototype stays true to it, and as the prototype evolves the PRD can be brought back in line. Its planning mode will feel familiar to any PM who’s written a PRD, Documents keep your real artifacts in the loop, and Skills let you turn one-off prompts into reusable levers. Engineers will appreciate the underlying code quality too — a clean component hierarchy and stable structure as the prototype grows make the eventual handoff to production smoother.
The goal isn’t a shippable prototype. It’s a better way to decide — turning guesswork into validation.
We used to build to deliver. Now we can build to discover, too.
Thanks to Dazl for sponsoring this post. Try Dazl the next time your team is locked in a UX debate.
