Two companies can buy the same category of software for completely different reasons.
One needs to show that it has the right protections in place. The other needs to keep the lights on.
That distinction came up early in my conversation with Evan Powell, founder and CEO of DeepTempo, on Inside the Silicon Mind. We were talking about cybersecurity, but I kept coming back to what it means for founders trying to find product-market fit.
If two customers have different definitions of success, selling them the same promise can send your company in two different directions.
Evan’s approach offers a useful way to think about who to build for, how to earn their trust, and what deserves a place in the next sprint.
Choose customers by what failure costs them
Evan describes cybersecurity as two markets sharing a category.
In one, the buying decision centers on checking the right boxes. In the other, a breach could interrupt critical infrastructure or compromise essential services. The consequences make the effectiveness of the product an immediate concern.
His language is deliberately sharp. Compliance and operational security can overlap. But the distinction raises a useful question for any founder: what is this customer actually buying?
A familiar vendor name? A requirement satisfied? A measurable improvement in how the business operates?
Those motivations shape which features matter, who evaluates the product, and how much work a customer will do to adopt it.
My takeaway is to segment early customers by the consequence of leaving the problem unsolved. Industry, headcount, and budget only tell you part of the story.
Ask a prospect what happens if the problem is still there in six months. Then ask who has to deal with it every day. The answers can tell you more about urgency than an enthusiastic reaction to a demo.
Give the customer a way to test the promise
When I asked Evan how DeepTempo stands out in a noisy market, he brought the conversation back to results.
He described offering to examine historical logs at little or no cost and look for suspicious activity. The customer gets a chance to assess the findings in their own environment.
That is a concrete starting point for a sales conversation. It gives both sides something to examine: what did the product find, was it useful, and did it justify further investigation?
Evan put the underlying principle plainly:
“try to be uncomfortably transparent”
He connects that transparency to open source, too. Practitioners can try the software and discuss their experience publicly. The company has to live with what they discover.
For founders, I would turn this into a practical exercise: design the smallest evaluation that lets a customer judge your core promise.
Agree on the task, the baseline, and what a useful result would look like. Get the person who will use the product involved in that evaluation.
A successful pilot still has to become recurring use and a paying relationship. But a test with a clear outcome makes the next decision much easier to understand.
Match the technology to the work
DeepTempo’s origin also matters.
Evan said he began by imagining a world where attackers used AI. That led him toward a specific problem: identifying attacks that are difficult to recognize.
In the interview, he described two different jobs. DeepTempo’s LogLM, a model trained on logs, handles detection. Vigil, its open source security operations software, helps with investigation and response workflows.
His argument is that analyzing huge volumes of events and helping a human work through an investigation place different demands on a system. Cost, speed, and accuracy matter differently at each stage.
The PMF lesson I take from that is to break the customer’s outcome into the work required to deliver it. Then choose the technology for each part.
For an AI founder, that means evaluating the product at the volume and under the constraints the customer actually faces. An impressive interaction is a starting point. The product also has to keep working when it becomes part of someone’s daily job.
Build around the conditions of adoption
We also talked about what happens when a company depends on a model it does not control.
Evan emphasized the ability to switch models, keep workflows open, and deploy intelligence close to the customer’s data. For the organizations he described, where data lives and how the system operates are central buying considerations.
There was another constraint in the conversation: accountability. Evan gave the example of an infrastructure organization where threat-hunting actions need to be attributable to a human.
That detail matters because it can determine whether a useful capability ever reaches production.
For founders, discovery needs to include the people and rules that govern adoption. Where can the data go? Who can authorize an action? What happens if a provider becomes unavailable?
These questions belong in the product conversation early. A customer can want the outcome and still be unable to use the product as you have designed it.
Use one customer outcome to set the next sprint
Near the end, I asked Evan how he stays focused when there are so many opportunities to build.
His answer brought the whole conversation together:
“tie ourselves to the mast of a problem and a desired outcome from a user”
He described planning the next two or three weeks around a particular problem for a particular customer. That gives the team a way to decide what to do and a way to recognize progress.
I like how practical this is.
Before the next sprint, write down whose problem you are solving, what they struggle to do today, and what they should be able to do when the work is finished.
Then decide how you will check the result with them.
Over time, you also need to see whether that same improvement matters to other customers. A focused sprint helps you learn; repeated demand tells you whether there is a broader business to build.
Evan’s approach keeps returning to that connection between the person doing the work and the outcome the company promises.
That is the question I would take into next week: which customer outcome is important enough to organize your next sprint around?