Building deep tech is hard. Finding the right customer is harder. Code, models, and hardware can work in the lab and still fail in the world. Customer discovery is how you bridge that gap. It is the quiet work that helps you ship the right thing, to the right people, at the right time. It turns your hunch into a plan. It saves months of burn and keeps your team focused.
What customer discovery means in deep tech
Deep tech changes how work gets done. That is why discovery here is not only about need. It is also about risk, rules, and time. Your task is to learn where your tech removes real drag without adding new pain.
You do this by walking through the day of the buyer, step by step, and by testing small parts of your promise in the real world. You also track the parts of your method that are new and useful so you can protect them early.
That way your learning builds value you can keep.
Turn vague interest into clear proof
Interest is cheap. Proof is gold. Ask each prospect to choose one metric that matters this month, not next year. Tie every test to that one number. If they care about uptime, count minutes saved.
If they care about cloud spend, track one job’s cost. If they care about safety, measure near misses. Keep the window short so you can show a move in days, not quarters.
When you plan a pilot, write a one-page pact. Name the site, the owner, the single metric, the start and stop dates, the access you need, and what you will do if the test stalls. Keep scope small.
Cut anything that needs a full rework of their stack. Ask for read-only data first. If that works, ask for a narrow write path under a toggle. Make rollback easy and fast.
Reduce risk before you sell speed
Most orgs fear breakage more than they want speed. Treat risk like a feature. List the top three fears you hear, such as downtime, data leak, or bad alerts. For each, bake in a simple guard. Offer a dry run
mode with shadow logs. Strip or hash sensitive fields at the edge. Gate actions behind human review at first. Show this plan on day one. It builds trust and shortens the yes.
Map buyers, users, and gatekeepers
Your user may not be your buyer. Your buyer may not own the wallet. Your gatekeeper may sit in IT, legal, or safety. In each account, draw a simple map with names and roles. Ask who owns the budget for the metric you track.
Ask who can block the install. Ask who gets credit if this works. Your path to yes is the path that helps each of them win. Share quick notes after each chat so they stay aligned and feel heard.
Design for integration, not just invention
A good idea fails if it does not fit the tools people use. During discovery, collect one sample of every file, API, and log you must touch. Verify field names, units, and update rates.
Confirm who owns each system and when they patch it. Build tiny adapters and test them in a day. Use the same words as the tools on their floor or in their stack. Names that match reduce training and support.
Price the change, not the code
In deep tech, price comes from the change you make, not the lines you ship. During calls, ask how they decide spend. Some teams need a payback in one quarter. Some need a capex path.
Some need a per-unit cost they can pass on. Draft a simple model with them. Show how your pilot metric rolls up to a monthly gain. Share a price that keeps their gain at least three times your fee. If the math does not clear that bar, adjust scope or find a bigger pain.
Capture IP while you learn
Your tests will surface new tricks, data flows, and edge-case fixes. Write these down in plain words with dates and names. Note why your way is different and useful. When a pattern repeats across sites, that is a signal to file.
A quick provisional can lock your date while you refine. As you move to full runs, convert to stronger claims. This turns daily learning into assets that keep rivals from cloning your path.
If you want a partner to guide this work and protect your edge while you do it, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
Set a sharp problem hypothesis
A problem hypothesis is a single clear claim you can test fast. It names the buyer, the moment of pain, the metric that moves, and the limits of your current build. Keep it short enough to say on a call without notes.
If it takes more than one breath, it is not sharp yet. Your aim is to turn a big space into one small promise you can prove within days, not months. This focus lets you plan the next interview, the first pilot, and the right IP move with confidence.
Make it testable in one week
Tie the claim to proof you can gather in seven days. Use logs, shift notes, or job histories that already exist. If your claim needs new tools or long installs to test, cut it down.
Choose a single unit of change, like tasks per hour, false alerts per shift, or minutes from alert to fix. State the baseline and the hoped move. Keep the time window short so you can show a real shift before attention drifts.
Anchor on a real event
Good hypotheses point to a trigger you can see. Think about the moment when the pain spikes. It could be a night handoff, a weekly batch, or a storm load. Write the line so it starts at that event.
When the camera fogs at dawn, detection drops. When the queue spikes after a firmware push, cost jumps. When the conveyor restarts after lunch, mispicks rise. Events make your claim concrete and help you find the right data slice fast.
State your boundary and your stop rule
Sharp means narrow. Say what you will not handle in this test. You might exclude certain parts, lighting, or data gaps. You might limit to one site or one model family. Also set a stop rule.
If results do not move by an agreed amount by a set date, you pause and rethink. This reduces risk for the buyer and saves your team from chasing noise. It also sets clean ground for a future patent, since you can show exactly what you tested and why.
Write the line like a contract
Put the claim in one clean sentence that a manager would sign. For this role at this site, when this event happens, our method will cut this metric by this much within this time under these limits.
Read it aloud. If it sounds like marketing, rewrite. If it sounds like a lab note, you are close. Share it before the pilot and ask for edits. Their words become your product copy and your claims language later.
Treat learning as an asset
Each test, even a miss, teaches you something unique about data prep, timing, or control logic. Capture that pattern with dates and names. Note what you tried, what failed, and what finally worked.
If a trick repeats across two sites, it may be patent worthy. Filing while you refine the hypothesis locks in your lead and makes each next test build value you can keep.
If you want help to frame sharp claims and protect the methods that make them work, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
Who feels the pain right now
A clear problem is not enough. You need a person who lives with it today and can act this month. Look for the role that owns the messy moment you target.
This person is close to the work, tracks the metric you want to move, and can say yes to a small test without a long chain of approvals. When you find this role, your path to a pilot gets shorter and your message gets simple.
Spot real urgency in the org chart
Titles can mislead. Urgency shows up in calendars and pagers. Ask who gets called when the line stops, the model drifts, or the bill spikes. Ask who stays late when quality dips. That is your primary contact.
Meet this person first and ask for a recent story, not a roadmap. If they speak in last-week numbers, you have found current pain. If they speak in next-year goals, keep looking.
Find the budget owner behind the scenes
The person who hurts may not move funds. Ask who owns the line item tied to the pain. It could be overtime, scrap, cloud, or warranty. Learn how that budget resets and who signs changes under a threshold.
Offer a test that fits under that limit so you avoid board cycles. Share a one-page plan that links your single metric to their line item. Keep the math plain. When the budget owner sees a clear path to a quick win, the door opens.
Score accounts by speed to yes
Not all accounts are equal. Create a simple scoring method that fits on a note. Give points for access to data, a named owner, a clear metric, and a pilot site. Subtract points for vendor freezes, security blocks, and complex change control.
Focus your week on the top two accounts. Tell the others you will circle back after you learn. This keeps momentum high and shows respect for time on both sides.
Turn champions into internal sellers
A strong champion wants a win as much as you do. Arm them with a short pack they can send without you. Include the one-line problem, the single metric, the test scope, and the guardrails that cut risk.
Offer to join a brief internal call only after they send it. Train them on the story with their own words. When they speak like an owner, approvals move faster and you avoid being seen as an outsider pushing change.
Build a small circle of proof
Run your first proof with one site, one shift, or one model family. Share weekly notes that show the metric moving. Ask your champion to forward those notes to the budget owner and one peer.
This creates gentle pressure and builds demand without hype. When the trial ends, ask for a plain statement you can reuse inside the company. That single paragraph will open the next site.
If you want help mapping these roles and turning early wins into protectable IP, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
Choose a narrow beachhead
Your first win should be small, loud, and close to your strengths. A narrow beachhead lets you learn fast, show proof, and avoid long change cycles. Think about one site, one shift, one data pipe, and one owner.
Keep the work inside a lane you can control. The goal is to move one number in days and turn that move into a story others can repeat.
Start by drawing a tight box around scope. Choose a job where inputs are stable and the handoffs are clear. Confirm you can reach the data without months of security reviews.
Confirm the line leader has the power to say yes to a short test. If any of these are weak, switch to a different lane. Your speed depends on clean access and a single person who wants the win now.
Set the ground rules in plain words before you touch anything. State what you will measure, how you will measure it, and when you will stop. Offer a fallback plan so the team feels safe.
Keep install steps simple and reversible. Promise weekly notes with the one metric up front and the narrative below. Teams trust what they can see and roll back.
Lock your language to the local tools. Use the same labels that show on their dashboards. Match units, shifts, and thresholds. This reduces training and also lowers your support load. It also gives you clean phrases you can later use in claims if your method proves unique.
Define the first proof line
Choose a single causal chain you can trace end to end. For robotics, it might be detection to pick to place. For AI, it might be ingest to score to alert. Name the baseline and the target shift for this chain.
Keep the window short. A seven day run is better than a quarter. If you hit the target early, extend with the same scope. Do not expand mid-test.
Turn the site into a quiet showcase. Capture before and after clips, anonymized if needed. Save logs that show the metric moving. Ask the line owner to write a short note in their own words.
With their consent, reuse that note within the company to open the next door. One clear paragraph from a peer beats a deck.
Treat the learning as future leverage. If a small adapter, timing tweak, or sampling trick makes the win possible, record it with dates and names. If it repeats at a second site, talk to a patent attorney.
That is how a tiny beachhead test turns into protectable IP and a moat you can carry to the next account.
If you want a partner to shape this lane and protect the methods that make it work, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
Build an interview plan that works
Treat interviews like an engineering sprint. You need a small pipeline, clear inputs, and steady output. Set a cap on how many calls you can run and synthesize each week.
Pick a few tight segments and spread your calls across them so you do not overfit to one voice. Time box each step so momentum never fades.
Set a weekly rhythm
Block fixed windows for outreach, calls, and synthesis. Send invites on the same two mornings each week. Hold calls in a tight band so notes feel uniform.
End every week with a short readout that lists what changed in your problem line, your buyer map, and your pilot plan. This cadence builds trust with prospects and keeps your team aligned.
Ask for artifacts, not opinions
Opinions drift. Artifacts anchor truth. In every call, request something concrete from the last ninety days. It might be a redacted ticket, a clip, a query, a shift note, or a budget line. Read it together on screen.
Mark the exact fields that matter. This turns a chat into a joint debug and gives you data you can later turn into a small test.
Use neutral prompts and silence
Lead with plain prompts like walk me through the last time and what happened next. Avoid why did you not try our approach.
After they answer, pause for a beat. The second sentence often holds the real constraint, like a change window, a safety rule, or a vendor lock. Capture those words verbatim. They will shape scope and pricing.
Triangulate within one account
One story is fragile. Within a single company, speak to a user, a manager, and someone from IT or safety. Ask each to tell the same incident. Differences reveal hidden systems and real blockers.
When three views match, you have a reliable map for a pilot that will not stall on week two.
Capture consent and protect data
Open each call with a clear note on how you will use what you learn. Ask permission before recording. Offer to anonymize names and sites in your notes. Strip sensitive fields from any files you receive and store a clean copy.
This builds credibility and speeds legal signoff when you propose a test.
Synthesize fast into a decision memo
Right after the call, write a one-page memo. State context, observed pain, metric to move, constraints, and the smallest test that could prove value. Add a short risk plan and a date for a go or no-go.
Share it back within twenty-four hours. Ask what you missed. Their edits become your playbook.
Turn insight into a micro test
End each week by picking one insight to test next week. Keep it tiny. A shadow run, a replay on historical data, or a line-side timing check is enough.
Promise to report the single metric and one clip or log that shows the path. Repeat this loop until you have a pilot both sides trust.
If you want a partner to design these interviews and protect the methods you refine, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
How to get meetings
Meetings happen when your note feels useful, safe, and short. Your first goal is not to impress. It is to make it easy to say yes to a twenty minute chat. Write like a peer. Show you did the work.
Promise one clear takeaway. Respect their calendar and their privacy. If you do those things, replies rise without tricks.
Write outreach that earns a reply
Open with their world, not yours. Mention a recent shift, launch, or post that ties to your problem line. State the single pain you study and the one metric you track. Offer a brief call to share what similar teams learned last month.
Ask for a short slot and propose two times. Close with a soft opt out so there is no pressure. Keep the entire note under six sentences and send it early in their morning.
Use a subject that reads like a log line. If they can guess the topic without opening, they will open. Avoid slogans. Use plain words from their tools. If they use a specific platform or model, name it.
This signals you will not waste time.
Use proof assets that travel
Create a simple one pager that shows a before and after for one use case, with numbers and dates. Redact names. Keep it visual and light. When you email, attach this as a preview and offer to walk through it live.
Add a short clip or a single annotated log if that fits the story. People book meetings to see working proof, not big decks.
Turn events into meetings
Watch for triggers that make your note timely. A plant restart, a policy change, a cost spike, or a public outage can create urgency. Reach out within a day of that event and tie your line to the moment.
Offer a quick review of what peers did in the same week when this hit them. Timeliness earns attention even if you are new to them.
Keep follow ups gentle and specific
If there is no reply, wait three business days. Send one new line with a fresh hook, such as a metric from your latest test or a small slot that opened on your calendar. Do not resend the same email.
If there is still silence, send one last note a week later with a clear goodbye and an open door. This keeps goodwill for a better time.
Turn a yes into a kept meeting
Right after they accept, send a calendar invite with a tight agenda and a link to join. Include your one line problem, the metric, and the artifact you will review together. Ask if anyone else should join.
Share your privacy stance up front. On the day, arrive early. Start on time. Close with a clear next step or a polite stop. Kept meetings come from trust and structure, not pressure.
Build a warm lane while you wait
Use small communities where your buyers gather. Share short insights, not pitches. Post a weekly note with one metric trend or a field lesson. Offer office hours for fifteen minutes at a set time.
People will book when they are ready. These warm lanes make future outreach feel natural.
If you want a partner who helps you set this system and also protects the methods you refine, Tran.vc invests up to $50,000 in in-kind patent and IP services for AI, robotics, and other tech startups. You can apply anytime at https://www.tran.vc/apply-now-form/
Conclusion
Customer discovery is how you turn hard tech into a real business. It is steady work, not a stunt. You name one clear problem, find the person who feels it today, and prove a small win in a narrow lane.
You speak in simple terms. You measure one number. You learn fast. You protect what is special as you go. Do this well and you build trust, speed, and a moat that grows with each test.