The Discovery Conversation: How Non-Technical Founders Should Qualify Technical Work
- 12 min read
You’re in a call with a software vendor or developer. They’re explaining database architecture choices, microservices vs monolith, deployment strategies. You’re nodding like you understand. You don’t.
Here’s the thing: that’s not your fault. You’re not supposed to care about those things. What you’re supposed to care about is whether the work moves the business forward.
The problem is most non-technical founders end up in two bad places. Either they defer entirely to whoever’s building (and hope they have good judgment), or they try to learn enough to evaluate the technical side (and get lost in the weeds).
Neither works.
The missing piece is this: you don’t evaluate technical work by asking technical questions. You evaluate it by asking business questions - and then listening to how the technical person responds. That’s what a real discovery conversation does. It gets you from “this sounds good” to “this is actually worth doing.”
The Problem With Not Qualifying First
Let me give you the expensive version of this.
I worked with a founder who had a lead generation problem. Organic was working fine, but paid campaigns weren’t converting. Their dev team (a freelancer, basically) heard “not converting” and immediately said: “We need to rebuild the landing page. Modern stack, optimize the funnel, A/B testing infrastructure.”
It sounded smart. Specific. Technical.
Six weeks and $45,000 later, the landing page was faster, prettier, more optimized. Conversion rate didn’t move.
Why? Because the real problem wasn’t the landing page. It was that their sales team wasn’t following up on leads within two hours. After two hours, the lead got cold. The landing page optimization meant nothing if nobody picked up the phone.
That freelancer never asked: “When you get a lead, what happens next?” They just heard “conversion problem” and jumped to the technical solution.
The founder spent $45k on the wrong problem because nobody in the conversation knew how to ask the right questions.
What a Real Discovery Conversation Looks Like
A discovery conversation has a different structure than a typical sales call. It’s not about selling you something. It’s about understanding whether something is worth building.
Here’s the actual process:
1. Define the pain point in business terms, not technical terms.
Not: “Our database queries are slow.”
That’s a technical descriptor. It tells you what broke, not why it matters.
Better: “Our operations team spends 20 minutes every morning pulling inventory data and manually consolidating it into a spreadsheet before they can see what’s in stock.”
Now you’ve got a business reality. Someone is spending 20 minutes on a repetitive task. That has a cost: their time, the risk of manual errors, the inability to see real-time inventory.
The right first question is always: “Walk me through what you do today when X happens.”
Let them tell you the actual workflow. Where they’re clicking, what they’re waiting for, where the workarounds are. The workarounds are gold. They tell you where the real friction is.
2. Quantify the impact.
Once you know what the problem is, ask: how much does this cost?
Not in fancy metrics. In reality.
- How many people does this affect?
- How much time does it cost them per week/month?
- What’s their hourly rate?
- What mistakes happen because of this?
- How many customers are affected?
- Are you losing revenue because of this?
If your operations team is 4 people, spending 20 minutes a day on manual data consolidation, that’s roughly 6.7 hours per week. At $50/hour fully loaded cost, that’s $335/week. Multiply that by 52 weeks: $17,400 per year.
Now you’ve got a baseline. A software solution that costs $20,000 to build and $2,000/year to maintain doesn’t make sense. A solution that costs $10,000 to build and saves $17,400 per year in labor? That’s a business decision.
You’ve gone from “sounds good” to “this has actual ROI.”
3. Understand what’s already been tried.
Before someone gets to the “we need software” conversation, they’ve usually tried something.
Ask: “What have you done to try to fix this?”
The answer matters. If they’ve tried building it internally and failed, that’s different from “we’ve never tried to solve this.” If they bought a tool and it didn’t work, that tells you why.
Listen for:
- What tools or solutions have they already tried?
- Why didn’t they work?
- Did the problem change since they tried, or did the solution miss the mark?
- How much have they already spent on this problem?
This saves you from proposing a $50,000 solution to a problem they already spent $40,000 failing to solve. It also tells you if they’re actually committed to fixing it or just exploring.
4. Map the timeline and decision process.
Software takes time. You need to know how much patience they actually have.
Ask these directly:
- When do you need this solved?
- What happens if you wait?
- Who else needs to sign off on this decision?
- When is that person available?
If the founder says “I need this fixed by next month” but it’s a 3-month build, you’ve got a misalignment problem that no amount of technical excellence fixes.
Also: if three people need to sign off, you need to understand whether the person you’re talking to is the decision maker. I’ve seen founders enthusiastically commit to $100k projects then realize they needed to sell the board.
5. Get clarity on what “success” looks like to them.
Not to you. To them.
In the inventory example: is success “inventory is updated in real time”? Or is it “the ops team spends less than 5 minutes a day on this”? Or is it “we get accurate numbers so we stop ordering twice”?
These aren’t the same.
Real success criteria are:
- Measurable (not “faster” - “15 minutes per day instead of 20”)
- Business-focused (not “system is more scalable” - “we can add three new locations without adding staff”)
- Tied to a current state (so you can actually measure the impact)
If you can’t agree on what success looks like, you can’t evaluate whether a solution actually worked.
Why Most Vendors Skip This
Here’s what you’ll notice: a lot of software vendors, developers, and consultants will not do this kind of conversation with you. They’ll want to jump straight to the solution.
“I think what you need is a custom API integration” or “We should rebuild this in React” or “What you really need is a microservices architecture.”
They’re skipping all the discovery work.
Sometimes that’s because they’re lazy. Sometimes it’s because they’re fishing - throwing solutions at the wall to see what sticks, then billing you for the work.
But sometimes it’s because they’re not trained to do discovery. A lot of developers were taught to code, not to understand problems. They default to technical answers because that’s their language.
A founder’s job in that moment is to push back.
“That’s interesting, but walk me through how that solves the inventory visibility problem. How much faster will our team actually work?”
Don’t let someone technical-talk their way past the business question.
The Questions You Actually Need
Here’s the checklist for a real discovery conversation. Write these down or bookmark this:
On the problem:
- Walk me through what happens today when X breaks down or needs to be done.
- How often does this happen?
- How many people does this affect?
- What’s the cost to the business (in time, mistakes, lost revenue)?
On their current approach:
- What have you already tried to solve this?
- Why didn’t those approaches work?
- How much have you already spent on this?
On the timeline:
- When do you need this solved?
- What happens if you wait?
- Who needs to approve this decision?
On success:
- What does “fixed” actually look like to you?
- How would you measure whether a solution actually worked?
- What’s the minimum improvement that would be worth the effort?
On commitment:
- Is this a priority or a “nice to have”?
- Do you have budget for this?
- Are you ready to start in the next 30/60/90 days?
If you can’t get clear answers to these questions, the work probably isn’t worth doing yet. And that’s valuable information - it means the pain point isn’t urgent enough to justify the cost.
The Founder’s Real Job in Discovery
Your job as a non-technical founder is not to understand the technology.
It’s to understand the business impact. To ask uncomfortable questions. To make sure the person proposing the solution actually understands your problem before they propose how to solve it.
A good vendor or developer will love this. They’ll appreciate that you’re asking hard questions because it means you’ll evaluate their work fairly. They’ll know the discovery conversation actually serves both of you - it’s not a sales tactic, it’s the work of figuring out if this is a sound investment.
A vendor who gets defensive or tries to skip discovery is usually a vendor who hasn’t thought through the problem clearly.
Trust that instinct.
The discovery conversation is the difference between a software project that moves the needle and $45,000 spent on a prettier landing page that doesn’t move anything.
Run the conversation. Ask the questions. Get clear on the business reality. Then decide if the work is worth doing.
If you’re not sure how to run this with your team or you’re about to make a big technical decision, that’s exactly what a fractional CTO conversation is for. Let’s talk through your specific situation and figure out if the work actually makes sense.