More than 90% of Fortune 500 companies deployed Microsoft 365 Copilot. Then Microsoft slashed its own AI agent sales targets by up to 50% in a single year, citing weak demand. Copilot now holds just 14% of the AI assistant market in a category where ChatGPT commands 61%.
The deployment data and the usage data tell two different stories. IT teams bought Copilot because the feature demo was impressive. The feature pitch closed the enterprise deal.
Nobody confirmed which specific workflow was actually broken before signing the contract. Nobody asked whether the people who would use it agreed the problem was urgent enough to act on today. The product sat in the stack while the licenses ran.
Microsoft’s IT teams skipped the diagnostic on behalf of their users. Solo founders skip it in their very first customer conversation. The outcome is identical: a product that works, sitting unused.
I recognized that failure from my own conversations after DraftKit launched. I published about it every week. The content worked. When someone from my audience reached out asking to learn more, I described the async workspace, the AI topic matching, the booking calendar. I covered everything the product did.
They replied once, said it sounded interesting, and went quiet.
That happened more than a few times before I understood the sequencing. The content had done its job. It brought someone to my door who already believed the problem was real. The first thing out of my mouth had to be a question. Confirm the problem first, describe the product second.
That gap is what this post is about, and it is where David Roy comes in.
David runs ENG Sales, a weekly newsletter on sales systems for technical founders who are still their own first sales rep. His Revenue Flywheel maps the full journey from first contact to compounding revenue. For today’s post, we are focusing on Driver 1 only, Customer Engagement, because that is where technical founders lose the sale before it starts.
The most important claim in this post: Most technical founders who publish about their builds are already executing step 1 of David’s flywheel. The content evangelizes the problem every time it ships. The flywheel stalls at step 2, the moment someone shows up ready to act and the builder starts describing features instead of confirming the problem.
Your Technical Content Is Already Step 1. Here Is Where It Stops.
The Prompt-Led Product audience knows about DraftKit before they ever visit the app.
I have shared every part of the build: the SMART Match AI that generates collaboration topic ideas from both writers’ RSS feeds before a booking is confirmed, the shared workspace editor, the async calendar. When someone reaches out asking about it, they are not discovering the product. They arrived already believing the problem of coordination chaos in newsletter collabs was real.
That is what David calls evangelizing the problem. It is the first move in his Revenue Flywheel, Driver 1. And most technical founders who publish about their builds are doing it every single week without realizing it.
Here is where it breaks down. Once someone shows up, the builder’s instinct is to keep describing. The content created the opening, so more content should close it. More features. More detail. More proof of what the product does.
❌ What most builders do when a prospect engages: Walk through the product. Share the demo. Describe the workflow. Explain the differentiator. Assume the quality is evident.
✅ What actually moves the conversation forward: Ask one question before describing anything. Confirm the problem is real for this specific person, in their specific situation. Then show them the part of the product that solves it.
Your content brought them here because they recognized themselves in the problem you described. Your first conversation has to confirm that recognition before it does anything else.
Strategic advice: Publishing about your build is not a vanity exercise. It is the evangelism layer of your sales system. Every post that names the problem your product solves is doing Driver 1 work. The issue is that most builders think publishing is the whole job. It is the first third.
The Roadmap for Today:
Your Content Is Already Step 1: Why what you publish evangelizes the problem, and where the flywheel stalls
Diagnose First. Pitch Never.: David’s Revenue Flywheel Driver 1 in full
The PM Diagnostic Advantage: What I did differently with DraftKit once I understood this
One Action Before Your Next Prospect Call
Let’s get into it. 👇
Diagnose First. Pitch Never.
Your product is ready. When you get on the discovery call, you start talking features. I know I’ve done it.
That’s the move that stalled so many of my first sales.
Early in my career, a senior rep brought me along on a “training call”. He knew the product inside and out and it showed in the meeting too. The moment the engineer on the other side said hello, the rep dove in on features, capabilities, how it all worked, what it could deliver. He was thorough, for sure.
The engineer went quiet.
Not the quiet of someone absorbing information. The quiet of someone who’d already checked out. He’d come with one question. What could this cost? He was just trying to build out a project budget. We spent forty minutes talking about everything except that.
We left without a next step.
The rep didn’t notice. I couldn’t stop thinking about it.
The instinct to show is natural for builders. You know the product better than anyone. You built the product to solve a specific problem. Walking someone through your product feels like helping. But your buyer isn’t on that call to learn what you built. They are there because something in their world is broken. Show them you see the problem and confirm they want to fix it.
3 Things Before Your Pitch
Before you describe your product, before you open a deck, share your screen, or walk through anything, you need three confirmations.
They have a problem you can actually solve.
Yes, this sounds obvious. But buyers often come with a symptom, not a diagnosis. Your job in those first few minutes is to hear what they’re describing and confirm it maps to what you do.
If it doesn’t, say so. That honesty builds more trust than any demo.
Ask Things like: ”What would be different if that was not a problem you had?” ”How much time do you waste doing that every week?”
They’re ready to solve it.
A real problem and a willingness to act are two different things. You can sit across from someone who knows exactly what’s broken and has no intention of changing it this quarter.
Readiness is a signal, not an assumption. Ask for it directly.
Ask: ”Are you ready for that workflow to be different, but do not know where to start?” ”Is this a ‘Nice to have fix’ or something you ‘Have to fix today?’”
They have the budget to solve it.
This one makes builders uncomfortable, but you have to ask. A prospect who can’t fund a solution isn’t a prospect yet.
Finding out in the first conversation saves both of you.
Ask: ”Do you have this improvement already budgeted?” ”If the right solution came to you today can you afford it?”
Three confirmations. That’s the diagnostic. Only after you have all three does it make sense to show them anything.
Make Them Work for the Call
There’s a filter built into every serious sales conversation.
Before I get on a discovery call, I ask prospects to complete my Revenue Flywheel Diagnostic. It’s not long. But it asks real questions: Where are you losing deals? Where does follow-up break down? What does your current sales process actually look like?
Some prospects skip it. That tells me something.
The ones who complete it show up to the call differently. They’ve already thought about the problem. They’ve named things they hadn’t named before. By the time we’re talking, they’re not warming up...they’re ready. And when I walk them through their answers on the call, I’m not guessing at their situation. I’m confirming it and getting more details.
That’s the diagnostic in action. Required friction filters out curiosity and surfaces intent. A prospect willing to put in the work before a call is a prospect willing to put in the work after one.
You don’t need a formal tool to do this. Ask one question in your first email:
“Before we connect, can you walk me through your current process for [the problem your product solves]?”
The answer starts your diagnosis and helps you see that they understand the problem. The absence of one tells you they are likely not serious.
A question like this would have saved me (and the rep training me) a pointless meeting with the engineer that just wanted a budgetary number.
Before Your Next Prospect Call
Write down your 3 diagnostic confirmations before you get on any call.
Do not open your demo until you have all 3.
Send one question before you schedule: “Can you walk me through your current process for [problem your product solves]?”
Use the response (or the silence) as your first data point.
If they complete your pre-call homework and show up ready, run the diagnostic.
If they skip it, ask yourself whether this conversation is worth your time before you accept the invite.
David Roy “These are the concepts I shared with Elena, and here’s how she applied them to DraftKit.”
The PM Diagnostic Advantage You Are Not Using
When I stopped explaining DraftKit and started asking questions, the conversations changed immediately.
The problem DraftKit solves is specific: newsletter creators spend close to 8.5 hours coordinating every collaboration from first outreach to published post. DMs that get lost. Google Docs links shared over email with no version control. Calendar back-and-forth that stretches four weeks. Collabs that fall through because one person forgot the other existed. I know this because I built the product to fix exactly that workflow.
That product knowledge is the diagnostic advantage David described. I didn’t need to guess at the problem. I needed to confirm they had it.
The question I started asking before describing anything: “Walk me through how you currently manage collaborations, from first outreach to the post going live.” That’s it. One question. Their answer either maps to the problem DraftKit solves or it doesn’t.
When it does, all three of David’s confirmations land inside one response. They described the problem themselves. They explained it unprompted, which signals readiness. They reached out to me, which means they are already considering a solution.
At that point I stop describing and start confirming. Then comes the step most builders skip entirely: setting the outcome expectation before anything is agreed.
For DraftKit, that sounds like this:
“If we set this up, you go from spending close to 8 hours coordinating every collab to spending closer to one. The platform handles the booking, the shared draft, and the follow-up. You just show up.”
That is one sentence. The before and the after. That outcome expectation does more work in a first conversation than any feature list, because it answers the only question the buyer is actually asking: what will my situation look like after this is solved?
One translation note for founders selling to indie creators rather than enterprise teams: David’s budget confirmation sounds different in your context.
There is no procurement line to check.
What you are actually confirming is whether this person has decided the problem is worth spending time and money to fix. “If the right solution existed today, would you pay for it?” gets you the same signal without asking for a budget that was never formalized.
Strategic advice: You are the most qualified person in the world to diagnose the problem your product solves. You built the product because the problem was intolerable. That experience is your diagnostic edge. The question is whether you use it as a conversation opener or save it for the pitch deck.
What did I learn? 🤔
The PM skill of translating user pain into product requirements maps directly onto David’s diagnostic framework. When you wrote the first user story for your product, you confirmed the problem existed. The diagnostic call is just doing that confirmation out loud, with the person sitting across from you, before they see a single feature.
The Truth About Why Builders Don’t Close Their First Deals
Most technical founders who publish about what they build have the most powerful sales asset available to them, and they are not using it.
They know the problem at a granular level no hired rep ever will. They built the solution because the friction was real. They can name the exact moment in the workflow where everything breaks. That knowledge is the diagnostic. The only shift is delivering it as a question first, then a solution.
👨🏻💼 The builder who stays stuck:
Launches the product.
Gets interest from the audience.
Describes features in every follow-up conversation.
Watches warm conversations go cold.
Assumes the product needs a better pitch.
👩🏼💻 The builder who closes:
Publishes to evangelize the problem (Driver 1, step 1).
Confirms the problem in the first conversation before describing anything (step 2).
Sets clear outcome expectations before any agreement is reached (step 3).
Uses what they built to diagnose, not to perform.
Run this audit on your last three prospect conversations. Find the first message or sentence where you described a product feature. Now count how many exchanges happened before you asked what their current workflow looked like. If the feature description came before the workflow question, you skipped the diagnostic. Run it next time and watch what changes.
One question for you: What is the first thing you say, or write, when someone asks what your product does? Drop it in the comments. David and I will tell you exactly how to reframe it as a diagnostic question.
If you want me to run this diagnostic on your product, reach out at hello@elenacalvillo.com.
Subscribe to
David Roy — ENG Sales: weekly sales systems for technical founders closing their own deals.
Stop chasing AI certificates. You don’t need another badge to prove you know your stuff. You need to build the thing!
At Cozora, we focus on building the skills you actually use at work. These are the high-paying skills that matter right now. It’s about execution, not theory.
I want to make sure you have the right tools to build, so here is the deal:
Paid subscribers: 50% off (monthly or annual)
Free subscribers: 10% off
Stop collecting credentials and start building systems. 🚀