--- title: "Technical founders sell through diagnosis" description: "Technical founders sell well when discovery starts as diagnosis: understand the workflow, explain tradeoffs, and say what the product can and cannot do." canonical: https://prasad.tech/blog/technical-founder-sales.html source: html generated_at: 2026-05-26T13:56:27.812Z --- [Home](/) / [Blog](/blog/) / Founder-led sales Nov 2025 11 min read Founder-led sales # Technical founders sell through diagnosis Technical founders sell well when discovery starts as diagnosis: understand the workflow, explain tradeoffs, and say what the product can and cannot do. At Mainteny, a prospect once asked how our system would handle a scheduling edge case in their maintenance workflow. The question was too specific for a feature-list demo. It touched the data model, technician availability, recurring jobs, and what happened when a customer changed a request after dispatch. I could answer because I had built that part of the product. I explained the current behavior, the trade-off behind it, and a limitation they would hit if they used the workflow in a certain way. He signed the contract that week. The argument in one paragraph Technical founders sell well when they stop trying to act like salespeople. The advantage is diagnosis. Buyers in B2B want to talk to someone who understands their problem deeply and can have an honest conversation about trade-offs. Engineers can often go deeper on the product and the workflow than a rep who only knows the demo path. ## A sales call as an engineering loop Five steps that already feel familiar to engineers Observe**Ask about the workflow**Where does the current process break? Model**Name the constraint**Integration, timing, data quality, risk, budget. Test**Map product to reality**Show only the parts that matter to their case. Handle**Discuss gaps plainly**A limitation is easier to trust when you can explain it. Follow**Send the summary**Repeat their words and next steps back to them. > Good sales calls help the buyer make a decision. They do not make the buyer feel handled. ## Why technical founders underrate this skill I disliked sales for years because I associated it with pressure, vague promises, and performance. The version that actually works feels closer to engineering: a buyer describes a workflow, you ask for the current state, you find the constraint, you test whether your product fits, you explain the trade-offs, you write down what you heard and what happens next. Engineers can be good at this because the work rewards precision. The strongest calls are demand calls, not pain-point interviews. I am listening for four things: the project the buyer already owns, why it matters now, which options they have tried, and why those options are not enough. If those four things are missing, a great demo usually turns into polite interest. When I was at Bain building Aura, I watched how the most successful internal sales happened. The work was deeply understanding someone’s problem, showing exactly how the solution worked, and being honest about trade-offs. Partners who adopted Aura most enthusiastically were the ones who felt genuinely helped. ## Deep product knowledge beats sales technique | | Career sales rep | Technical founder | | --------------------- | ---------------------------------- | -------------------------------------------------------------------------------------------------------- | | Edge-case question | 'Let me get back to you on that.' | Walks through the actual code path, the trade-off behind it, and the workaround for their specific case. | | Architecture question | Has to check with the product team | Is the product team. Has opinions about the design and can defend them. | | Limitation discussion | Avoided or spun | Named upfront, with a workaround the buyer had not asked about | | Buyer's reaction | Delay, uncertainty, no decision | Trust, fast follow-up, signed contract | The Mainteny call where we beat two competitors. Same buyer. Same use case. Different sellers. This is the practical advantage. You are the product team. You can have real conversations about architecture, integrations, and implementation. In B2B software, those conversations often matter more than anything else. ## The consultative mindset The mental shift was simple. Stop treating sales calls as opportunities to pitch. Treat them as opportunities to understand. Your job is to help the buyer figure out whether what you have is a fit for what they need. If it is, the next step becomes obvious. If it is not, that is also useful information. Three small language swaps that change the call - **Instead of** “Let me show you our features.” **Try** “Tell me about what you are trying to accomplish.” - **Instead of** “Our product does X, Y, and Z.” **Try** “Based on what you have described, we could help with X. Y might not be the right fit. Let me explain why.” - **Instead of** “What would it take to close this deal today?” **Try** “Does it make sense to keep talking, or is this not a priority right now?” When you give people permission to say no, they listen with less defensiveness. When you are honest about limitations, they believe you when you talk about strengths. When the product is a poor fit, you learn that early. ## Discovery: the engineer’s natural strength Weak sales calls break during discovery. The seller rushes to the pitch before understanding the work. Engineers are almost pathologically inclined toward thorough discovery. We want to understand the problem before suggesting solutions. We are uncomfortable making recommendations without sufficient context. We ask follow-up questions because we genuinely want to understand the edge cases. That thoroughness is an advantage. Discovery questions that work for technical founders - Walk me through how you are handling this today. - Who owns this project internally? - Why is this coming up now? - What options have you already tried? - Where did those options break down? - What does your current tech stack look like? - Where does the process break down? - If this worked well six months from now, what would be different? - Who else is involved in making this decision? Ask with genuine curiosity. The best sales conversations feel like technical design discussions. You are both trying to figure out the right solution to a real problem. Sometimes that solution is your product. Sometimes it is something else. ## Handling objections with technical honesty Traditional sales training teaches you to overcome objections with clever rebuttals. Engineers often struggle with that because it feels manipulative. We can see through our own tricks. The good news is you do not need tricks. Honesty is more effective. When a prospect raises an objection, they are telling you something important about their needs or concerns. Take it seriously. If the objection is valid, acknowledge it directly. Then do three things: explain why that limitation exists, describe what you are doing about it, and help them evaluate whether it is a dealbreaker for their specific situation. > Prospects do not trust salespeople who have an answer for everything. They trust salespeople who are honest about trade-offs. At Luminik, prospects sometimes ask about features we do not have yet. Instead of pretending we are working on it, I tell them exactly where it is on the roadmap and why other things are prioritized higher. Sometimes they are fine waiting. Sometimes it is a dealbreaker. Either outcome is better than setting false expectations. ## Follow-up answers build trust A clear gap in the call can build credibility when the follow-up is precise. Pretending to know creates future trust debt. Send the answer within 24 hours, ideally with more detail than they expected. The follow-through turns the gap into a trust-building moment. ## Practical tactics | | Tactic | Why it works | | ------------------------------ | ---------------------------------------------------------- | -------------------------------------------------------------------------------------------- | | Structure your calls | Opening, discovery, demo, next steps | Keeps you on track without making the conversation feel scripted | | Demo less, talk more | Targeted 10-minute demo of relevant pieces only | Beats a comprehensive 45-minute feature tour every time | | Take detailed notes | Write their exact words down | Lets you reference their language later, not generic feature descriptions | | Send a summary in 24h | What you discussed, what you understood, agreed next steps | Demonstrates professionalism, gives them something to share with stakeholders | | Negative close | 'Is this worth continuing, or not the right fit?' | Removes pressure and paradoxically increases yes rate | | Useful follow-up | Specific next thought, not 'just checking in' | Engineers fear being pushy and under-follow-up. The opposite of pushy is useful, not silent. | | Get comfortable with silence | Wait after the question | Silence prompts prospects to share more than they planned to | | Record calls (with permission) | Review the recording later | You will hear bad questions, places where you talked too much, objections you handled poorly | Eight tactics that have worked across Mainteny, Aura, and Luminik. None of them are sales tricks. All of them are about being precise, useful, and following up. ## When to keep selling vs when to hire Conventional wisdom says hire a salesperson as soon as possible. I think that is wrong. Founder-led sales has enormous advantages early. You learn directly from customers. You understand objections firsthand. You can make product decisions based on what you hear in calls. You build relationships with early customers that pay off for years. More practically, you have not figured out the sales motion yet. Ideal customer profile, messaging that resonates, the right price point, repeating objections, typical sales cycle. You need to answer those questions before hiring someone to execute a process that does not exist yet. | | Keep selling yourself if | Consider hiring when | | ---------------- | ----------------------------------------------- | ---------------------------------------------------- | | Customer count | Closed fewer than 10 to 15 customers personally | You have a documented, repeatable sales process | | Sales process | Cannot articulate it cleanly yet | It is repeatable enough to teach | | ICP | Still evolving | Stable across multiple closes | | Pricing | Still moving | Predictable across deals | | Time consumption | Sales is not yet overwhelming | Sales is consuming more than 50% of your time | | Product needs | Product needs your attention more | Pipeline is dropping deals because you are stretched | Two checklists. The hiring decision becomes obvious when most boxes flip. Even then, the first sales hire probably should not be a quota-carrying rep. An SDR who handles outbound and qualification leaves you doing the actual selling. A customer success hire frees you to take more first calls. The goal is to extend your capacity, not replace yourself. ## The practical advantage Modern B2B buyers need help making a good decision. They want to talk to someone who understands their problem deeply and can have an honest conversation about solutions. They want technical credibility and clear tradeoffs. As a technical founder, you have all of that. You just need to stop thinking you need to be something else. What I learned A technical founder who knows the workflow can often create more trust than a polished demo script. Ask thoughtful questions, give honest answers, and follow up reliably. The prospect you helped today, even if they did not buy, remembers that experience. ![Prasad Subrahmanya](/assets/images/header/prasad.jpeg) ## Prasad Subrahmanya Builder and operator at Luminik. Built Aura at Bain to $3.6M ARR, co-founded Mainteny through its $2.7M seed, and helped build the initial product and team. [LinkedIn](https://linkedin.com/in/prasadus) [GitHub](https://github.com/prasadus92) [ Back to blog](/blog/) ## Filed under Founder-led sales technical founderssalesdiscovery ## Related notes [**Selling the workflow before the software**I delivered Luminik manually before building the product surface. That work showed which event workflows repeated and which steps belonged in software.](/blog/selling-before-building.html)[**Alfred: how I run repeated work as a solo founder**How I use Alfred to turn repeated company work into plans, summaries, draft replies, and pull requests I can review before anything ships.](/blog/alfred-solo-founder-operating-system.html)[**Separating agent work from founder work**Why I moved recurring agent work out of my daily workspace, what the boundary controls, and which approvals still stay with me.](/blog/dedicated-mac-mini-solo-startup.html)