This post is sponsored by Rezonant. I accepted after running a real DraftKit product session through the tool and seeing what it caught before I built anything. Everything I write here reflects my own experience and editorial judgment. My opinion is not for sale.
The rate-limiting factor in AI product development is no longer code generation speed. It is PM spec quality, and most of the tools PMs use right now are designed to execute specs, not challenge them. Rezonant is the first product workspace I have tested that does the second thing.
The Roadmap for Today
The DraftKit feature I had been too scared to build for three months
Four things Rezonant caught before I wrote a single line of code
Testing whether it could follow my own user story template
Why every AI tool I use obeys (and why that is killing products)
What Rezonant actually is and what the team thinks is the best part
What actually shipped: 9 tickets, right priority order, a new DraftKit pricing tier live
Who this is for and who it is not
Hey, I’m Elena! 👋
AI Product Manager, builder, and founder of DraftKit.app and the AIAdventChallenge.com. I write Prompt-Led Product, a newsletter for PMs who are tired of just writing requirements. This is for the product leader who wants to actually ship. The kind where you stop managing tickets for a second, open a prompt, and build the logic yourself.
Built by you. Led by your product taste. 🚀
If you’re new here, welcome! Here’s what you might have missed:
Strategy: How Reforge Transformed From Education Company To Multi-Product Platform
Builds: I Built a Product Brain MCP to Stop Carrying Context in My Head
Join a community of builders from companies like Reforge, Product School, OpenAI, Lovable, Pendo, and Miro shipping AI products.
The DraftKit Feature I Was Too Scared to Build
One of my DraftKit power users has been asking for book project management for months.
The use case is real: she is coordinating a book with multiple chapter writers, peer reviewers, and editorial reviewers, and the current workaround is a mess of Google Docs folders, duplicate files with nearly identical names, and coordination happening across email chains and Google Chat simultaneously.
DraftKit handles newsletter collaboration beautifully, but a book is a different beast.
The feature has been sitting on my roadmap for at least three months. I kept deprioritizing it. Not because I did not understand the value, but because I was genuinely scared of breaking what already works in DraftKit.
Adding a project layer to an existing product with active users, a credits model, Row-Level Security policies, and a Stripe billing setup is exactly the kind of change that looks simple in a doc and creates four production incidents in practice.
I knew that. So I kept kicking it.
What made me finally open it was Rezonant. The pitch was simple: connect your codebase, describe what you want to build, and see what happens.
Honestly? I was a little skeptical.
I have run DraftKit planning sessions through Claude, ChatGPT, and Gemini. Even Lovable itself. They all produce PRDs. Good ones, even. But a PRD is not the same as a product thinking partner, and I did not know that distinction existed until this session.
Rezonant Flagged 4 Things I Missed Before I Wrote a Single Line of Code
I connected the DraftKit repository, fed Rezonant the product context, and described the book management feature.
I expected just a simple PRD. What I got was something closer to a principal engineer who had read my schema and had specific objections ready before I finished explaining the feature.
🚩 The first flag: my credits model would break immediately.
A book project with 10 chapters and 3 collaborators per chapter burns 30 credits before a word is written. The credit model was built for 1-to-1 newsletter collabs. Without that flag, my first book author would have hit a wall in her first session.
🚩 The second flag was on billing architecture.
I was planning to mix credits and subscriptions in the same feature. Rezonant named the problem directly: “Billing Cognitive Load.” A user should not have to check both their credit balance and their subscription tier in the same session. That is a documented UX concept with a name, and no other tool I have used has ever applied it to my own product unprompted.
🚩 The third flag was the one that genuinely changed how I think about this tool.
I had defined storage limits and completely skipped project count limits. Rezonant caught it: without a project count cap, an agency could spin up 50 projects at the $49 tier and the database cost becomes a real problem. That gap would have been a very expensive production incident.
🚩 The fourth flag came from a gap I had never thought to define.
I set a limit of 3 active projects. Rezonant stopped me with one question: what does “active” mean?
If there is no archive state, a user who finishes 3 projects is permanently blocked from starting a fourth. She cannot work around it. Her only move is to upgrade or stop using the product.
That is not a pricing tier. That is a retention cliff built into a missing definition. Without that flag, I would have shipped a churn event on day one for my best power users. Rezonant caught it before I opened a code editor.
None of this is what I expected. All four flags were correct.
Then I Tested Whether Rezonant Could Follow My User Story Template
After the planning session I tested something I did not expect to care about: Rezonant’s template system.
It ships with built-in templates for Issues, Projects, and User Stories. The default user story format covers the basics: user story statement, Acceptance Criteria, Definition of Done.
I used my own template for vertical user story slicing to break features into independently shippable pieces, which means my stories require error handling conditions, dependency mapping, and edge case acceptance criteria that most generic templates do not include.
I submitted my structure to Rezonant and asked it to generate the book project feature stories using my format. My team right now is Lovable.
The user stories Rezonant produced were not generic. They followed the error handling structure, called out the dependency on the is_project_workspace flag, and flagged the archive state as an edge case that needed its own acceptance criterion.
I was honestly shocked by how closely it followed my template and how much it knew about the codebase context underneath each story. That is the test that made me go from “interesting tool” to “I need to write about this.”
What did I learn? A user story template in Rezonant is not just a formatting preference. It becomes the quality standard that every generated ticket has to meet. If your template requires error handling, Rezonant includes it. If you require a Definition of Done checklist, every ticket gets one. For teams using Lovable, Cursor, or any coding agent, this is the difference between a ticket that produces the right output and one that produces a three-round back-and-forth.
Why Every AI Tool I Use Obeys (And Why That Is Killing Products)
I have been building with Lovable for over a year. In the planning and spec work alone I have run sessions through Claude, ChatGPT, Gemini, Cursor, and Lovable itself.
After I shared this Rezonant session with Gemini, it told me the analysis was “on point.” Even the competition agrees.
The problem is that every single one of those tools obeys.
You tell them what to build and they help you build it. You describe your plan and they refine it. They are optimizers, not challengers.
A PM who only hears yes from their tools is making product decisions inside a very expensive echo chamber.
The Veracode 2025 GenAI Code Security Report found that AI-generated code introduces security vulnerabilities in 45% of tests, and that number has not improved as models have scaled up.
The root cause is upstream: when no one challenges the specification, the implementation runs on a bad foundation and compounds with every sprint.
Build faster on a bad spec and you just ship the wrong product faster. Rezonant is the first tool I have tested that is explicitly designed to interrupt that pattern before it starts.
What Rezonant Actually Is (And the Part That Changed My Workflow)
Rezonant is a shared product workspace for teams shipping with AI coding agents.
You connect your codebase and product context during onboarding. From that point, everything it generates is grounded in what you have actually built, not a generic product template.
There is also a Chrome extension called Rezonant Alter. You open your live product, select any element on screen, hit record, talk through what you want to change and why, and the session comes back as a codebase-aware plan with tickets ready to push to Linear or Jira.
Here is Sam from the Rezonant team doing exactly that on his own Lovable prototype, Keystone: walking through a change, letting Rezonant read the codebase context, and watching it push the update through GitHub and back into the Lovable project.
Side note: use it in Chrome. Browsers with custom sidebar systems will require a manual workaround to access the sidepanel, and Chrome is just the path of least resistance.
The capability that changed my workflow most was not the extension itself. It was the planning intelligence underneath it: the part that does not just capture what you say, but challenges whether you are saying the right thing before you say go.
Alter is how you bring your live product into the thinking. The workspace is where the thinking gets challenged. Both matter. In my experience, the second one is where the flags that save you from production incidents actually live.
The next day proved it. I assumed every dropdown in DraftKit needed to switch to official Tailwind components because hover and right-click were broken. Rezonant stopped me before I filed a ticket.
The real issue was Radix UI’s position="popper" teleporting dropdowns into a portal at document.body. Not a component problem. A positioning default.
The fix was one line in one file: src/components/ui/select.tsx.
Ten minutes. Zero risk.
It also caught something I had stopped seeing. The hover state contrast was running at 2 to 3:1 ratio. WCAG AA requires 4.5:1. The orange-brown hover color against reddish-brown text was failing basic accessibility on every dropdown in the product.
Two tickets, both scoped precisely, both correct. That is not a tool flagging a visual preference. That is Rezonant reading the actual codebase underneath every screen element you select.
The whole team, including engineers, designers, and stakeholders, can work in the same live multiplayer workspace. It connects to GitHub, Notion, Figma, Lovable, Granola, Confluence, and more, so everyone is always working from the same version of reality instead of a stale doc.
“Multiplayer workspace” here means something specific. It is not a shared Google Doc that someone last edited three weeks ago. It is a live surface where every collaborator sees the same state of the plan at the same moment, connected to the codebase that is the actual source of truth. That is what Rezonant means when it says specs do not go stale.
The PM Is Not the Bottleneck. The PM Is the Quality Gate
Product Led Alliance’s 2026 product management research shows that 92% of product leaders now own revenue outcomes, more than double from just a few years ago.
The role is shifting from documentation-heavy execution toward product direction and quality ownership.
The bottleneck in AI product development is no longer writing the code. It is deciding what to build and specifying it accurately before a coding agent touches it.
Rezonant’s positioning is that it “prevents PMs from being the bottleneck to shipping new ideas, instead turning them into one of the most important people in the business.”
This is a tool built to elevate the value that PMs bring to the team.
The PM stays in control of intent and direction. The team stays in the loop. The codebase remains the source of truth.
And the coding agent gets properly-specced tasks with the full context it needs to run.
If you have been following the Build Series, Part 5 on keeping an AI product profitable was exactly about this tension: shipping fast is easy now. Shipping the right thing still requires someone to own the quality of the decision upstream.
9 Tickets. Right Priority Order. The Feature I Was Scared to Build Is Live
Rezonant generated 9 tickets in the correct build sequence: the project layer as the parent task, then database schema and data integrity, flag-based RLS policies, subscription gating, project container UI, role management, chapter lifecycle, image storage, and broadcast email.
The RLS ticket came with a specific note: no coding agent assigned, human eyes required on every line. Rezonant knew that one was too risky to hand off automatically.
I handled the Stripe connections for the new pricing tiers manually, which was the right call. Lovable took over from there, ran the queries in Supabase and Stripe, and the Project tier went live on DraftKit.
Before I finished writing this post, I had already used the same Project tier to organize my AIAdventChallenge.com 2026 content production. I built it for a book author’s problem and solved my own first.
My husband read the session afterward and said most PMs could not have guided that conversation to where it landed. I pushed back. Then I reread it.
None of this is what I expected. I did not think to ask about archive states. I did not know my credits model would break at scale.
I did not know I had a project count gap. Rezonant asked all of it.
My PM instincts helped me recognize each flag as real when it surfaced. But if I had run this session through Claude, ChatGPT, Gemini, Cursor, or Lovable, I would have gotten a well-structured PRD with none of those flags in it.
Those tools help you build what you planned. This one challenged whether the plan was right.
That is not a small distinction. That is four production incidents that did not happen.
This Is a Team Tool. Your Solo Builder Experience Just Proves It Works.
I tested Rezonant solo, with Lovable as my “team.” That is the most constrained version of this product’s use case.
If it caught four production-breaking issues in a one-person session, consider what it does for a team where the PM’s intent has to survive a handoff to three engineers, two stakeholders, and a coding agent.
This tool fits your team’s workflow if:
✅ Your team ships with AI coding agents and specs keep losing context between what the PM decided and what the agent received
✅ Your scoping sessions produce the right decisions but the ticket that follows never fully captures what was said in the room
✅ You need a single workspace where engineers, designers, and stakeholders all see the same version of what is being built, in real time
✅ You want a planning layer that challenges the spec before the agent runs, not just helps it run faster
It is a harder fit if:
✅ Your team’s primary bottleneck is still on the engineering side and PM spec quality has not yet surfaced as the limiting factor
✅ Your build cadence is slow enough that vague spec handoffs have not yet caused real coordination problems
Shipping Fast on Bad Specs Just Gets You to the Wrong Place Faster
I have been writing about building with AI since before vibe coding had a name. The tools that make teams faster are everywhere. The tools that make the product thinking better are rare.
Rezonant is the first product workspace I have tested that treats PM judgment as the most important input in the build cycle and builds actual infrastructure around protecting the quality of that judgment.
The DraftKit session produced four flags I missed. That is four production incidents that did not happen.
For a PM who is scared to ship a feature because of what might break, that is not a spec tool. That is a co-founder.
If you want to try it, use this link: Start with 3,000 free credits. Prompt-Led Product readers get triple the standard free tier, 3,000 credits instead of 1,000. That is enough runway to run a real planning session on your own codebase before you decide anything.
If you want me to audit your current spec-to-build workflow and find exactly where intent is getting lost before it reaches your codebase, reply to this email or write at hello@elenacalvillo.com.
Now it’s your turn, what is the feature on your roadmap right now that you keep deprioritizing because you are scared of what it might break? Tell me in the comments.
I usually need to set my long project per big feature to then explore, discuss and get specs about my products, this just convinced me to try Rezonant and see how better and faster I could get the same or more to my team 🤔