Uncategorized

I sales chatbot prototype built with Claude Code and Resend

I Built an AI Sales Chatbot Prototype and Threw It Away. The Client Loved It.

Marcus, one of my client’s sales reps, texted me at 8:14 am on a Wednesday.

“Did you just email me about a lead?”

I said yes.

“I haven’t touched the website in weeks. How did you know someone was there?”

That was the moment I knew my AI sales chatbot prototype had done exactly what it needed to do.

What Was Actually Broken

The client ran a five-person sales team for a B2B SaaS product. Workflow automation software for field operations teams. Good product. Solid pricing. Real customers.

However, their problem was not the product. It was the gap between a visitor showing interest and a rep picking up the phone.

Average response time to inbound inquiries: five to six hours. By then, half the leads had already moved on. The sales team was not lazy. They were busy. Nobody was watching the website waiting for someone to ask about the Enterprise tier.

The solution everyone kept suggesting was a chatbot. I had heard that conversation three times before a single requirement was written. That is usually a red flag. Because it means people have already decided on the solution before defining the problem.

So before writing a single spec, I built the thing.

How I Built the AI Sales Chatbot Prototype

I opened my terminal on a Tuesday morning and typed what I wanted to build. Plain English. No boilerplate, no scaffolding, no Stack Overflow tabs.

Claude Code did the rest.

A Node.js chatbot backed by the Anthropic API. The knowledge base came from the client’s entire Notion workspace. Product docs. Three pricing tiers. Thirty-five integration guides. Six case studies. A 55-question FAQ covering onboarding, billing, security, and compliance. About seventy pages of content, none of it formatted for a chatbot.

It did not matter. Claude Code scaffolded the project, wired up the API calls, loaded the knowledge base into the system prompt, and had a working local version running in under an hour.

Then I started breaking it immediately.

The Agentic Layer: Where the AI Sales Chatbot Prototype Got Interesting

A chatbot that answers questions about pricing is essentially a FAQ with a chat interface. Useful. Not interesting.

What I wanted, therefore, was a system that knew when someone was actually ready to buy. Not based on a form they filled out. Based on what they said.

I added an intent detection layer. Every visitor message went through a prompt that evaluated buying signals. Specific ones. Mentioning team size. Asking about a particular integration they already used. Bringing up a competitor by name. Asking about onboarding timelines.

When those signals fired, the system did not wait for anyone.

Using the Resend API, it sent an automated email directly to the relevant sales rep. The email included a plain-English summary of the conversation, the exact signals detected, context the visitor had shared about their role, and a suggested opening line for the follow-up call.

Not a notification. Not a ping. A brief, useful message that said: someone is here right now, here is what they care about, here is how to open the conversation.

That is what Marcus received at 8:14am. A lead who had spent twelve minutes asking detailed questions about the Enterprise tier and mentioning a team of forty field technicians. Handed to him, warm, with full context.

He called within four minutes.

Then I Threw the Whole Thing Away

The prototype never shipped. It was never meant to.

The code was not production-ready. There was no authentication. No rate limiting. No error handling worth mentioning. Because the knowledge base was injected raw into a system prompt, it worked fine for a demo but would fall apart at scale.

None of that mattered. The AI sales chatbot prototype had already done its job.

It found the things I would have gotten wrong in a spec. The intent detection fired too aggressively on questions that were curiosity, not buying signals. The email had too much text. Reps wanted the pricing tier in the subject line before they even opened it.

I found all of that before engineering touched a single line.

The PRD I wrote afterward was the tightest spec I have written in years. Every requirement came from something I had already tested. Every edge case came from a failure I had already found. As a result, engineering had almost no clarifying questions going into the first sprint.

That is what a prototype is for. Not to ship. To make you wrong fast, cheaply, and before it costs anyone else anything.

What This Means If You Are Hiring a PM

A product manager who can build an AI sales chatbot prototype before writing a spec is not a developer who wandered into product.

They are a PM who shortened the feedback loop between an idea and a validated requirement by days or weeks. Someone who walks into sprint planning having already been wrong once. Quietly. On their own time.

That makes requirements tighter. Engineering conversations shorter. The shipped product closer to what users actually needed.

Marcus closed that lead. The chatbot the engineering team built three weeks later looked almost exactly like the prototype, except it actually worked properly.

That is the job.

AI in PM workflow changing discovery prioritization and decision cycles

How AI Changed My PM Workflow and Decision Cycles. Two Years In, Here’s the Truth

Two years ago, AI felt optional in my PM workflow. Today, working without it feels like trying to ship with one hand tied behind my back.

Not because AI replaced product thinking. Because it removed friction everywhere else.

Over the past two years, working as a product consultant across SaaS, marketplaces, and AI-heavy teams, my workflow quietly rewired itself. No big announcement, no magic moment. Just a slow realization that decision cycles were getting shorter, opinions were mattering less, and signals were mattering more.

This article is about how AI changed how I work as a Product Manager. Not theory, not trends. Just what actually shifted in practice.

What PM Work Felt Like Before AI

Before AI entered my PM workflow, everything followed a familiar and exhausting rhythm.

Discovery took weeks. Docs took days. Alignment took meetings. Decisions waited on artifacts. Most of my time went into preparing inputs for other people, including decks, docs, summaries, and variants. By the time a decision landed, the context had already aged.

I remember waiting weeks for research synthesis, only to realize the question itself was wrong. That hurt every time. Not because the work was bad, but because the loop was slow.

AI did not fix thinking. It fixed waiting.

What AI Actually Changed First

The first shift was not decision quality. It was speed to clarity.

AI compressed the messy middle. Things that used to block progress suddenly stopped blocking, including first drafts of PRDs, research summaries, competitive scans, and user interview synthesis. None of these tasks disappeared. They just stopped costing so much time.

That freed up mental space, and mental space changes decisions. When exploration feels cheap, you explore more. That alone was worth the shift.

How Discovery Cycles Shortened

Discovery used to feel like a phase with a start date and an end date. Now it feels continuous.

I stopped treating discovery as a separate lane. Instead, AI made it easier to pull insights whenever they were needed. After a few user calls, I would drop notes into AI and ask for patterns, not conclusions. Sometimes it got things wrong. Often, however, it surfaced angles I had completely missed.

The key change was timing. Instead of waiting weeks for synthesis, I reacted within days. Sometimes within hours. Decisions stopped stacking up and started flowing.

How Prioritization Stopped Being a Political Fight

Prioritization used to feel political. Everyone came with opinions, everyone had context gaps, and alignment took time.

AI changed the inputs. I started stress-testing ideas faster, asking what assumptions drive this feature, what user segment benefits most, and what metric moves first. AI helped me model tradeoffs early. Not perfectly, but fast enough to expose weak logic before it reached a meeting room.

Bad ideas died sooner. Good ideas survived fewer meetings. Decision cycles shortened because fewer ideas reached escalation in the first place.

How Prototyping Rewired the Way Teams Decide

Prototyping became the biggest single shift in my AI-assisted PM workflow.

Before AI, prototypes arrived late, too late to change minds without friction. With AI, prototypes arrived early, before opinions hardened. I could test flows, copy, and concepts in days, sometimes hours.

That changed conversations completely. Instead of debating hypotheticals, teams reacted to real behavior. Decisions moved from “I think” to “users did.” Decision cycles collapsed because evidence showed up early enough to matter.

How Documentation Quietly Changed Too

This part surprised me more than anything else.

I write more docs now, not fewer. AI lowered the cost of writing, so I started writing earlier and more often. Docs stopped being deliverables and became thinking tools instead. I used AI to draft outlines, reframe problems, stress-test narratives, and clarify tradeoffs.

Writing earlier made decisions easier later. Context stayed fresh. Alignment stayed lighter. It sounds small, but it compounded quickly.

How Meetings Lost Some of Their Power

Meetings still exist. Sadly.

They matter less now, though. AI reduced the need for syncs by improving async clarity. When everyone starts from the same synthesized context, meetings stop being discovery sessions and become decision moments instead. Shorter meetings, fewer repeats, less explaining. Decision cycles tightened because understanding arrived before the call.

How My Role as a PM Shifted

My job changed shape over these two years.

Less time producing artifacts, less time chasing inputs, more time framing problems, and more time interpreting signals. AI amplified clarity and exposed confusion at the same time. Vague thinking broke faster, which was uncomfortable and also genuinely helpful.

The PM role moved closer to judgment and further from coordination. That shift felt uncomfortable at first. Now it feels like the job I actually signed up for.

What Did Not Change

AI did not replace accountability. I still own decisions. I still get things wrong. AI does not save you from judgment calls, and it accelerates bad thinking just as fast as good thinking.

The quality of decisions still depends entirely on the quality of questions. That part stays stubbornly human, and honestly, it should.

Takeaways: What Actually Changed My PM Workflow Over Two Years

Use AI to reduce waiting, not thinking
Treat discovery as continuous, not a phase with a start and end date
Synthesize early and revise often
Stress-test assumptions before escalation, not during it
Prototype before opinions harden
Write earlier to think better
Bring evidence into conversations fast
Make uncertainty visible early so decisions do not stall
Decide with direction, not perfection
Remember that judgment stays human no matter what

AI changed my PM workflow by compressing time and changed decision cycles by removing friction. Not because AI makes better decisions, but because it helps you reach decisions while the context still matters.

Two years in, working without AI feels slower, louder, and more political. The work did not get easier. It got sharper.

AI product value vs hype framework for product managers evaluating AI features

How to Tell Where AI Adds Real Value and Where It’s Just Hype

Last week I joined an online product meetup. Camera off, mic muted, Slack half open. You know the setup.

Someone dropped a question in the chat: “How do you know where AI adds real value versus just hype?”

The chat exploded. Hot takes everywhere. Everyone had shipped something “AI-powered.” Very few people sounded convinced by their own answers.

That question shows up every time AI enters a roadmap conversation. Teams feel pressure to add AI. Leaders want AI stories. Users, on the other hand, want better outcomes, not buzzwords. So here is how I learned to separate real AI product value from hype, based on two years of shipping AI features as a product manager and consultant.

Why This Question Matters More Than Ever

AI shows up everywhere now. Decks, roadmaps, sales calls. The problem, however, stays simple. AI raises expectations before value exists.

When teams pick the wrong use cases, trust drops fast. Users feel tricked, engineers feel burned, and PMs feel defensive. Picking the right AI bets is, therefore, what decides whether a product feels genuinely helpful or quietly embarrassing.

How Hype Usually Enters the Room

Hype follows patterns. A leader says “we need AI here,” no user problem gets named, a demo looks impressive, and nobody explains the daily impact. That path ends badly, consistently.

AI hype focuses on capability. Real AI product value focuses on outcomes. If a team starts with “the model does this,” that is a danger sign. If a team starts with “users struggle here,” value stays possible.

The First Question I Ask Now

When AI comes up in any roadmap conversation, I ask one question before anything else.

“What gets better for the user on a bad day?”

Not a good day. Not a demo day. A bad day.

If AI helps only during perfect conditions, hype wins. Real AI product value shows up during mess, edge cases, and stress. This single question kills many AI ideas early, which saves time, money, and honestly a fair amount of dignity.

Where AI Adds Real Product Value

Across the products I have worked on, AI added genuine value in three clear zones.

The first zone is speed on repetitive work. AI performs well when users repeat tasks and dislike every minute of them, including sorting, summarizing, and categorizing. The second zone is pattern detection at scale, where AI shines when humans miss signals across large data sets, such as fraud detection, anomalies, routing, and recommendations. The third zone is decision support, not decision replacement. AI helps users decide faster without deciding for them.

Every successful AI feature I shipped lived inside one of those three zones. Anything outside them usually struggled.

Where Hype Hides Best

Hype hides in features that look impressive but change nothing in daily use.

Common red flags include AI added to dashboards nobody checks, smart suggestions users consistently ignore, explanations nobody trusts, and features nobody actually asked for. If a feature needs a demo to feel valuable, danger lives nearby. Users judge AI product value by daily friction, not novelty.

The Test I Run Before Greenlighting Any AI Feature

Before committing to an AI feature, I run a simple test. Remove AI from the idea and ask what remains.

If the remaining experience still helps users, AI adds leverage to something real. If the experience collapses without AI, then AI is simply propping up a weak idea. Strong products stand without AI. AI amplifies strength rather than creating it.

This test has saved me from shipping several shiny disasters.

How I Evaluate AI Ideas Now

My evaluation checklist stays boring on purpose. A clear user pain exists today. Manual or rule-based solutions are struggling to keep up. Data quality supports the use case. Failure modes stay acceptable. Users retain meaningful control throughout.

If any item on that list fails, a pause follows. No fancy scoring model needed. Clarity beats complexity every time.

Why “Cool” Never Makes the List

Cool fades fast. Users remember outcomes: reduced effort, fewer mistakes, saved time.

Every AI feature that shipped successfully felt boring in demos. Every flashy feature caused regret later. Excitement peaks early. Utility compounds quietly. That pattern has been consistent enough that I now treat “this looks cool in the demo” as a mild warning sign rather than a green light.

How This Changed My PM Instincts

Two years ago, I chased AI opportunities. Now I filter aggressively.

AI stopped feeling special and became another tool, a powerful one, but also a dangerous one when applied carelessly. My decision cycles improved once hype lost its authority in the room. I also learned to disappoint people early by killing weak AI ideas before they gained momentum. That built more trust later than shipping anything flashy ever did.

Takeaways: Questions to Ask When AI Enters the Roadmap

Start with user pain, not model capability
Ask what improves specifically on a bad user day, not a demo day
Favor speed, scale, or decision support use cases over novelty
Avoid AI that exists primarily for demos or announcements
Remove AI from the idea and test whether the product still holds up
Watch failure modes before you celebrate success cases
Keep users in control at every step
Kill ideas that need hype to survive the first honest conversation

Back in that meetup, the chat kept scrolling without a clear answer. The truth, however, feels less dramatic than the question suggests. AI adds real product value when teams stay grounded. AI becomes hype when teams chase novelty.

The difference shows up early if you ask the right questions. I still get excited about AI. I just trust the boring ideas more now.