Technical cofounder in customer discovery: what to own

Why this role gets misunderstood

Founders often pull the technical cofounder into customer calls too early, and for the wrong reason. If the job is only to collect feature requests, a shared note is enough. Anyone on the team can write down "they want SSO" or "they asked for exports."

The problem starts when every request gets treated as if it carries the same weight. It doesn't. A customer question only makes sense once you know what it costs to build, how it changes delivery time, and whether it adds security, data, or support risk.

A "small" ask often hides a bigger one. "Can you support on premises?" might mean a different pricing model, slower onboarding, and a harder support plan. "Can you integrate with our ERP?" might mean custom work, long testing, and promises the team should not make lightly.

That is where the technical cofounder matters. Not as a note taker, but as the person who hears the constraint inside the request.

There is also a difference between early discovery calls and deal shaping calls. In a first interview, the goal is usually to learn the buyer's workflow, pain, and language. You often do not need a technical founder there unless the product itself is highly technical.

A live deal is different. Once a buyer is deciding whether to move forward, details start to carry real weight. One answer about deployment, security, uptime, or implementation can shift price, scope, and trust in a few minutes.

This is where teams get into trouble. If the commercial founder says "yes, we can do that" without understanding the limit behind the ask, the call may go well and the account may still fall apart later. Buyers remember vague promises. They also notice when no one in the room can explain tradeoffs clearly.

Join when the conversation touches three things at once: what the product can really do, how fast the team can deliver it, and whether the buyer believes the team can carry the risk.

When you should join the call

The technical cofounder should join when the answer might change the deal. If the buyer needs more than a product tour, your presence can save time and stop bad promises before they leave the room.

The clearest trigger is technical risk that affects trust. Show up when the buyer asks how data moves, where it lives, who can access it, or how your product connects to the systems they already use. The founder can explain the problem and the vision. You should handle the parts where a wrong answer creates doubt fast.

Integrations are a common example. If a prospect asks whether you can sync with their ERP, import years of records, or support single sign on, that is not a note taking moment. Those answers affect setup time, support load, and sometimes whether the deal happens at all.

Dates matter too. Buyers often ask for a launch window before they sign. If that date depends on real engineering work, you need to speak for it. A loose estimate from the founder can quietly turn into a deadline your team never agreed to.

You should also be in the room when a promise might change price or contract terms. Some requests sound small but are not. A custom integration, special hosting setup, audit logs, or a new review process can add weeks of work. If you stay out of that call, the startup may quote the wrong price and lock itself into a bad deal.

The simplest test is this: if the buyer's question could change scope, timeline, risk, or trust, join.

That does not mean joining every call. That is a quick way to waste your week. If the founder only needs help collecting feature requests, stay out. A conversation full of "we'd like a dashboard filter" or "it would be nice to export this as PDF" usually does not need you live. The founder can gather those notes, group the patterns, and bring you the themes later.

The useful distinction is between requests and constraints. Requests tell you what people want. Constraints tell you what the product must handle to win and keep the customer. The founder should learn that difference. The technical cofounder should protect it.

What you should own

Your job on a discovery call is not to collect ideas for the roadmap. You're there to find the limits that shape scope, timeline, price, and risk before anyone makes a promise the team has to clean up later.

That means listening for the part under the request. When a buyer asks for "real time dashboards" or "enterprise security," they may mean very different things. One company wants updates every 15 minutes. Another wants second by second data, audit logs, single sign on, and approval flows. Those are completely different projects.

You own the translation work. First, turn vague requests into concrete effort, dependencies, and edge cases. Second, explain the tradeoffs in plain language. What gets faster, cheaper, or simpler, and what does the buyer give up? Third, sort the request by timing. Is this required on day one, needed later, or just nice to have? Finally, defend the promise boundary. Stop the call when it drifts into "sure, we can add that" and the "small" add on actually means months of extra work.

Most buyers do not care which database, model, or queue you use. They care about outcomes. Will this delay launch? Will their team need training? What breaks if usage doubles? If a custom integration adds three weeks and ongoing support, say that directly. Do not hide it behind technical terms.

You also need to test stated preferences. A request can sound fixed when it is really habit. If a prospect says they need on premises hosting, ask why. Sometimes the real need is data control, vendor review, or lower monthly spend. Once you know the reason, you can discuss simpler options.

This is one of the places where an experienced Fractional CTO can help. Oleg Sotnikov at oleg.is often works at exactly this level, where one architecture decision affects uptime, cloud spend, and how lean a team can stay.

When this part goes well, sales gets cleaner and pricing gets more honest. The team avoids traps like one off reports, custom workflows, and "minor" security asks that quietly become a second product.

Questions that uncover real constraints

Discovery gets more useful when you ask about limits instead of wish lists. A buyer may describe ten features, but one hard constraint can matter more than the whole list.

A good starting question is, "What has to work on day one for you to say yes?" That forces the buyer to separate must haves from extras. Sometimes the answer is not a feature at all. It might be single sign on, spreadsheet import, or a response time promise.

Then ask, "What tools or manual steps does this need to fit around?" Most teams already run a messy process. They use email, spreadsheets, Slack, an old ERP, or one person who fixes problems by hand. If your product breaks that flow, adoption gets slow fast.

Another useful question is, "Who will review security, reliability, or procurement concerns?" The person on the call may like the product and still not control the decision. Legal, IT, security, finance, or procurement can stop the deal later. You want those names early, not after a verbal yes.

You can also ask, "What kind of failure would make this feel too risky?" This usually gets honest answers. Some buyers fear downtime. Others fear bad data, failed migrations, or a tool their team will not trust. Once you know the fear, you know what proof matters.

Finally, ask, "Which budget or timing limit will not move?" Buyers often sound flexible until money or deadlines come up. A fixed launch date, a capped pilot budget, or a contract window shapes the build more than feature requests do.

A small example makes the point. A buyer might ask for a custom dashboard, but the real blocker is that finance needs data exported into a current system every Friday, and IT must review access controls before rollout. The dashboard is easy to talk about. The export and review process decide whether the deal can close.

When you hear a hard limit, follow up with questions like "How do you handle that today?" and "What happens if that goes wrong?" Those usually produce better answers than "What else do you want?" They move the call from opinions to daily reality.

How to run your part

Before the call, write down the few assumptions that could change scope, price, or trust. Keep it short. Ask yourself what would force a different architecture, a longer rollout, extra security work, or more hands on support after launch.

If the buyer needs single sign on, audit logs, and approval from internal IT before anyone can test the product, those are not small details. They affect delivery, and they may affect whether the deal makes sense at all.

During the call, let the commercial lead run the conversation. Your job is to listen for blockers first and feature ideas second. A buyer can live without a dashboard tweak. They usually cannot live without legal approval, data export, or a clear setup path.

Say tradeoffs out loud as soon as they appear. If the buyer expects a two week launch but also wants custom roles and a security review, name the tension. Clear tradeoffs protect trust better than polite silence.

Right after the call, sort your notes into three buckets: constraints, risks, and open questions. A constraint must be true for the deal to work. A risk might slow delivery or raise cost. An open question still needs an answer.

Then turn the result into a short memo for the team. One page is enough if it says what the buyer needs now, what can wait, what might break delivery, and what decision the founders need to make next.

Keep the note blunt. If trust depends on uptime, migration safety, or support response time, write that plainly. Teams lose time when they chase feature requests and miss the real reason a buyer says yes or no.

A simple example

A warehouse company says they want a simple dashboard for floor teams. On the surface, that sounds small. The founder hears "a few screens, some charts, and user logins" and starts thinking about a fast pilot.

The technical cofounder should slow that down a little. The first useful question is not about charts. It is about where the data lives now.

The buyer then explains that the dashboard must pull live inventory and shipment data from their ERP. They also need every stock adjustment tracked by user, time, and location because supervisors review disputes later. Then one more detail comes out: if the dashboard goes down during shift change, the warehouse backs up within minutes.

Now the shape of the deal is different.

You are not pricing a light dashboard anymore. You are pricing an integration project with audit history, uptime expectations, and real support needs. The work may still be worth doing, but the quote, rollout plan, and delivery promise all have to change.

The founder should keep leading the relationship. They ask about business impact, budget, and urgency. They make sure the buyer feels heard.

The technical cofounder handles the risk side in plain language. They might say that ERP access will set the pace, that audit history has to be designed from day one, and that active shift use means support and reliability belong in the price.

That is the honest version of the project. It may raise the price. It may split delivery into phases. It may even rule out a quick pilot if the buyer cannot give API access or internal IT support.

This is where the role earns its keep. The technical cofounder surfaces the hidden constraints early, so the team does not sell a cheap dashboard and discover later that the buyer really needs a business critical system.

The founder still owns the relationship. The technical cofounder protects it by making sure the team sells what it can actually deliver.

Mistakes that waste the call

One habit kills discovery fast: the technical cofounder starts teaching instead of learning. If a buyer asks about scale, integrations, or reliability, answer in plain language and tie it to their daily work. A long tour of databases, queues, or internal services usually does not build trust. It just uses time you needed for the real problem.

Another common mistake is promising a future feature for every objection. That feels helpful in the moment, but it blurs the line between a real need and a nice to have. When you say yes too quickly, you stop learning what the buyer can accept today, what they will pay for, and what only one loud person wants.

Vague words do damage too. If someone says they need an "enterprise" setup or a "secure" product, do not nod and move on. Ask what those words mean inside their company. They may mean single sign on, audit logs, approval from legal, regional hosting, or a written incident response target. Each one changes scope in a different way.

You can also waste the call by arguing with the buyer when a request sounds wrong. Maybe they ask for CSV exports every Friday and you think a dashboard would solve it better. Do not turn that into a debate. Ask why they need the file. You may learn that a finance team uploads it into an older system, or a partner blocks direct access. The reason matters more than the request.

Before everyone leaves, attach an owner to each open question. You confirm whether single sign on fits the current product. The buyer checks who signs off on security review. The commercial lead sends pricing for the delivery options discussed. If no one owns the next step, follow up drifts and the buyer starts to lose confidence.

Quick checks before you join

You do not need to join every call by default. Join when technical facts might change price, delivery date, scope, or buyer trust.

A simple checklist helps:

• Could a technical limit change the offer, quote, or rollout plan?
• Will the buyer ask for proof on security, reliability, or integrations?
• Can the founder answer the likely questions clearly without you?
• Will your presence build trust, or will it slow the call down?
• What decision should come out of this meeting?

The last question matters most. If you do not know whether the team wants a next meeting, a paid pilot, a clear no, or a list of blockers, it is easy to spend 45 minutes answering interesting questions that do not move the deal.

If most answers are no, skip the call and debrief after. If two or three are yes, join and keep your role tight.

What to do next

Right after the call, capture the constraints while they are still fresh. Do not stop at feature requests. Write down the parts that affect pricing, delivery, and trust: approval steps, security concerns, timeline pressure, integration needs, support expectations, and anything the buyer sees as risky.

Then pick one clear next move. If the buyer needs proof, schedule a demo. If they need budget clarity, send an estimate. If they need lower risk, propose a small pilot. If the situation is still fuzzy, book a follow up call with the people who own the blocked area.

A short note from each call should answer four things: what problem feels expensive or urgent to the customer, what constraint could slow delivery or raise cost, what would make the buyer trust the team enough to move forward, and what action moves the deal one step closer to a yes or a no.

Use the same notes across the team. Product can use them to decide what deserves real attention. Sales can adjust the pitch and stop promising the wrong thing. Onboarding can prepare for the friction that usually shows up after the contract is signed. One good page of notes can save hours of rework later.

A simple rule helps: if a discovery call changed your view of scope, timeline, or buyer confidence, update the plan the same day. Small gaps grow fast when nobody owns them.

If your team is sorting out where founder sales ends and engineering reality begins, outside help can be useful. A consultation with Oleg Sotnikov at oleg.is can help pressure test estimates, clarify technical risk, and decide when a CTO should step into the sales process.