42:26
AI-native product management
Rags Vadali, founder of Floto, argues that once you're building an agent the real product to define is the experience layer on top of it, not UI — and because AI-accelerated engineering has outpaced PM planning, he has replaced PRDs with a 'Product Experience Document' (PXD) that specifies conversational guardrails, critical moments, and closing behavior, handed to engineers and coding agents after a prototype already exists rather than before.
As a PM, 'I don't know what I don't know' — foundation models and coding tools change so fast that pre-planned UX ideas are disjointed from what's actually possible by the time they're specced.
Floto has inverted the traditional PM-specs-first flow: engineers build a first prototype directly from a problem statement, and Rags crafts the product experience afterward by playing with what got built.
Rags no longer writes PRDs; thinking and crafting have become the bottleneck, so that work moved later in the process.
Engineers rarely collaborate with each other anymore — each runs Claude Code with parallel agents and owns an entire product end-to-end; a 3-engineer team can build 2-3 products in parallel.
About 50-60% of what gets built is thrown away once judged not to solve a real user problem — a workflow Rags says 'would never have happened' on any prior traditional engineering team.
This process feels capped at a team of about 3 engineers; at 6, Rags doubts he could hold enough context to manage it.
Other companies are adapting similarly: Roblox designers are now expected to ship code via Cursor; Rags predicts an eventual 'reckoning' pulling back from pure speed toward more deliberate consideration.
Discovery fundamentals haven't changed — every resonant feature traced back to actually talking to users — but AI now helps fill the same time-cost gap via Perplexity-mined Reddit/G2 threads and via Floto's own feedback-agent product used on its own users.
Synthetic (AI-simulated) personas are useful only for very early-stage feedback and only on negatively-framed questions, since positive questions trigger the model's 'please the user' bias and personas can't be trusted 'on the edges' because that output is hallucinated.
The PXD is structured as Why → Success Criteria (quant + qual) → Experience Principles → Critical Moments → Conversation Closing → Success Metrics, and engineers feed its 'experience principles' sections into Claude to generate the prompts used to build/tune the agent.
Because agent behavior is non-deterministic, you must specify ranges of good/bad/unwanted answers and explicit 'don'ts,' not fixed requirements — and you must design explicit 'breakpoints' where the agent stops its current line and digs deeper when something serious surfaces.
How an agent closes a conversation matters because it habituates the user toward or away from future engagement, even though it doesn't affect the current session.
This PXD approach fits agentic products but is a poor fit for interface/UI-heavy products, where Rags still prefers traditional designer+engineer close design sessions producing a Figma reference first.
Because specialization boundaries are being short-circuited, Rags plans to make 'product sense' a required interview component for every hire regardless of role.
Looking forward, an explosion of AI-built products/features will cause feature bloat, but the 30-year-old first principle hasn't changed: nobody uses a bad, irrelevant, or poorly-fit product, so the enduring advice is to keep a continual pulse on what users want.
Experience layer as the product — Rags's reframing that when building an agent, the actual product to define is the experience layer built on top of the agent, not UI. Apply: When scoping an agentic product, write requirements about the conversational/behavioral experience the agent delivers rather than screens or UI flows.
Engineering-first prototyping workflow — An inverted PM process where engineers build a first prototype directly from a problem statement instead of a PM writing a PRD first. Apply: Give engineers a problem statement and the contours of what's believed buildable, let them build a prototype on the codebase, then have the PM shape the experience by using it.
Process inversion (crafting after building) — Moving the PM's judgment/crafting work to after a prototype exists rather than before, because thinking-and-crafting had become the sprint bottleneck. Apply: When PM speccing capacity can't keep pace with engineering output, let engineers produce a first pass and reserve PM craft time for refining what already exists.
Claude Code parallel-agent engineering model — An engineering setup where each engineer runs parallel Claude Code agents, rarely collaborates with other engineers, and owns an entire product end-to-end. Apply: Structure small teams so a single engineer, leveraging parallel coding agents, is responsible for a whole product rather than splitting features across engineers.
Rapid experiment-and-discard cycle — A build-fast, throw-away-most validation technique where roughly 50-60% of what's built gets discarded after assessing whether it solves a real user problem. Apply: Send frequent 'can we do this?' experiments to engineers, get results in a day or two, and discard low-ego if it doesn't clearly solve a real problem.
Discovery closing question — A standard open-ended interview probe — 'What is the most frustrating thing for you day-to-day?' — used to surface adjacent problems beyond the current build. Apply: End user conversations with this question to leapfrog into new problem discovery rather than only validating the current feature.
Six-people pattern heuristic — A standard UX research heuristic that you need to talk to roughly six people before real patterns emerge from discovery conversations. Apply: Don't draw conclusions about a user problem from a single conversation; wait until you've spoken with about six people in the target persona.
AI-assisted problem discovery via Perplexity — Using an AI query tool to mine Reddit and G2 comment threads for citations that validate or invalidate a problem hypothesis, replacing manual thread-reading. Apply: Query Perplexity for Reddit/G2 discussion on a suspected user problem to quickly gather supporting or disconfirming evidence.
Dogfooding via own feedback-agent product — Using Floto's own feedback-agent product on its own users as a source of discovery insight. Apply: Deploy your own product as a feedback-collection tool against your own user base to generate discovery data.
Synthetic personas — AI-simulated user personas, built to actively deliver feedback (unlike traditional written personas that are created but rarely used), reflecting patterns the underlying model was trained on. Apply: Use synthetic personas only for very early-stage feedback before something is built, knowing they can't be trusted on edge cases because that output is hallucinated.
Negative-questioning technique for synthetic personas — The finding that asking synthetic personas negatively-framed questions (e.g., what would make you pause) surfaces more genuine insight than positive framing, which triggers the model's tendency to please the user. Apply: When probing a synthetic persona, phrase questions around hesitation or objection rather than justification for an action.
Interview workers — AI agents Floto is building to conduct async, roughly 6-minute conversations with real people and extract valuable insight, aiming to match the value of a scheduled call. Apply: Send users an async link to a short AI-led conversation instead of scheduling a traditional interview call.
Product Experience Document (PXD) — A named artifact replacing the PRD, structured as Why → Success Criteria (quantitative + qualitative) → Experience Principles → Critical Moments → Conversation Closing → Success Metrics, written partly to be fed into a coding agent. Apply: For agentic products, draft a PXD instead of a PRD, feed its experience-principles sections into Claude to generate build/tuning prompts for engineers.
Eval/guardrail-style spec-writing — A specification approach for agents that documents not just desired behavior but explicit 'don'ts,' using concrete good/bad/ugly example interactions pulled from real usage. Apply: Include real good, bad, and ugly interaction transcripts in the PXD as training material to set guardrails, and keep iterating the document as new failures surface.
Breakpoints — Explicit stop conditions in an agent's conversational flow that trigger when something serious or important is expressed, forcing the agent to abandon its current line of questioning and dig deeper. Apply: Define specific triggers ('if you hear this, stop everything and dig deep') in the PXD so the agent interrupts routine question flow when a critical signal appears.
Critical moments section — The core PXD section addressing how an agent, which normally pursues a fixed set of conversational goals, should deliberately break that goal-pursuit loop when a user surfaces something warranting deeper follow-up. Apply: Write explicit rules describing what counts as a critical moment and instruct the agent to override its default goal pursuit and go deep when one occurs.
Conversation closing design — Deliberate design of how an agent ends a conversation, since abrupt endings habituate users away from future engagement even though they don't affect the current session. Apply: Add a dedicated closing-behavior section to the PXD specifying how the agent should wrap up conversations to encourage future re-engagement.
Ranges framing for non-deterministic specs — A specification approach acknowledging that because the system is a non-deterministic model rather than a person, you must specify a range of good, bad, and explicitly unwanted answers instead of a single fixed requirement. Apply: When writing agent requirements, describe acceptable answer ranges and explicitly excluded answers rather than a single pass/fail spec, accepting the system may land anywhere in the acceptable range.
Product-sense interview for all hires — A plan to transplant the traditional Google/Meta-style product-sense interview into the hiring loop for every role (engineer, growth, etc.), not just PM, because specialization boundaries are being short-circuited. Apply: Ask every candidate, regardless of role, a product-sense question (e.g., name a product you love and why) as a required interview component.
Continual user-pulse discipline — The enduring first-principle practice of continually tracking what users want, using whatever AI/technology is available, framed as the one thing product people should not stop doing amid rapid process change. Apply: Regardless of which AI tools or workflow inversions are adopted, maintain an ongoing practice of understanding user needs so that shipped features are the ones that bring in users and revenue.
The single most counterintuitive tactical tip in the interview: ask synthetic personas negative questions ('what would make you pause before clicking buy?') rather than positive ones ('why would you click buy?'), because positive framing triggers the model's built-in tendency to invent pleasing justifications, while negative framing still triggers pleasing behavior but yields genuinely useful insight.
Floto's agents deliberately invert the standard LLM interaction pattern — instead of users asking an LLM questions to get answers, the agent asks people questions with no expectation of giving answers back, which Rags describes as a difficult mental shift to design for.
The PXD isn't really written for a person to read and align on (unlike a PRD) — Rags realized mid-writing that it's effectively written for a coding agent, since its 'experience principles' sections get fed into Claude to generate build prompts.
The 'critical moments' design pattern treats an agent's normal behavior as pursuing a fixed set of conversational goals (going deep/broad to satisfy them), and treats genuine insight-surfacing moments as requiring a deliberate interrupt of that goal-pursuit loop — a reframing of 'good listening' as an explicit control-flow override rather than a soft instruction.
Rags cites the ChatGPT GPT-4 to 4.5 tone change and the resulting user backlash ('I'm going to quit') as evidence that conversational feel is not a cosmetic detail but something users react to strongly, reinforcing why his team dedicates a whole PXD section to it.
The team's discovery efficiency lever isn't AI at all but scope: because all of Floto's products target the same persona (designers), weekly user conversations validate/invalidate current builds and surface new problems simultaneously, letting discovery insight transfer across product lines.
Rags frames the hiring shift not as 'find people who can do AI-native work' but inverted: find people with strong product sense who are also AI-native, and specialization splits (e.g., content vs. design) matter less than the ability to ask the model the right questions to get needed answers.
His closing advice is deliberately framed as 'what not to stop doing' rather than a new prescription — keeping a continual pulse on user wants is presented as the one constant that survives every process inversion described in the interview.
«What is a product? You're building an agent. My kind of conclusion is that product you're building is actually now the experience layer you build on top of the agent. So, that is the real product to define.»
— 00:00
«As a PM now, I don't know what I don't know.»
— 00:23
«We build agents that ask people questions with no expectation of giving people any answers.»
— 00:38
«We basically now start from engineering.»
— 04:29
«It is it is actually insane how much a single engineer can build.»
— 09:19
«We actually end up I think throwing away 50 to 60% of things that we build.»
— 10:13
«This would never have happened, by the way, in any engineering team that I would have been in.»
— 10:32
«Let's just give Claude to everybody and see what happens.»
— 13:53
«People will give you the problems that you need to solve with your products.»
— 17:55
«They do not give you anything on the edges. That and anything on the edges you cannot trust cuz it's hallucinated, right?»
— 19:31
«the really big the really cool insight we've had is that asking for synthetic personas negative questions is the best way to use them.»
— 20:04
«if you have an e-commerce site and you say, 'Oh, why would you click the buy button?' That's a very bad question to ask. They'll find you every reason to say why they click. But, when you ask the question, 'What would make you pause before clicking the button?' You actually get two or three insights...»
— 20:28
«The gold standard still remains people.»
— 21:18
«you cannot just specify a requirement and expect that it will be built. You really have to think about ranges here.»
— 28:16
«we build agents that ask people questions with no expectation of giving people any answers. That's a very difficult kind of like, you know, thing to think.»
— 32:20
«I think I would make product sense a required part of the interview process for everybody in the team.»
— 36:00
«nobody will use a bad product or an irrelevant product or a product that is not built for that.»
— 40:29
«I think the the core like first principle has not changed, right? Focus on the user and build something that they want.»
— 41:34
Reception
No comments are available, so audience reception cannot be determined.
The episode is a firsthand, single-founder field report — grounded in a few months of practice at a 3-6 person team — rather than an externally validated method, and its most concrete contribution (the PXD framework, breakpoints, negative-questioning of synthetic personas) is offered as what worked for Floto specifically, with Rags himself flagging that the approach doesn't transfer to UI-heavy products.
42:26