They had made it far enough to convince someone to buy. Getting people to keep using the product was proving harder.

“Adoption and usage seems to be the biggest challenge,” he said.

At the time of our conversation, Steve was leading the integration of Clari and Salesloft, so he was seeing this from both sides: customers trying to make a growing collection of tools work, and smaller companies looking for a way forward.

What stayed with me from our conversation on Inside the Silicon Mind was the gap between a product finding its first customers and earning a lasting place in their work. A signed contract gives a founder something important to build on. What happens after the sale tells you much more about whether the business can last.

Understand what the customer has to change

Steve described customers who had bought several AI tools to solve different parts of a business problem. Each tool might have a useful capability. The customer still had to manage the collection, connect the work, and get people to use it.

That last part can be easy to underestimate when you are building.

You know why your product is better. The person using it has an existing routine, other responsibilities, and a limited amount of patience for another system. They may agree with your pitch and still return to the way they worked before.

My takeaway is to study that return to the old routine. Choose a customer whose usage fell after the first few weeks and ask them to walk through a recent example of the work your product was meant to help with.

Where did they start? When did they reach for your product? If they stopped using it, what happened at that point? What did they use instead?

A founder may hear that the output needed too much checking, that information had to be entered twice, or that a colleague could not use the result. Those are different problems. A general request for more training will miss some of them.

The more precisely you understand the interruption, the better your chance of removing it.

Expand around the work that already matters

Steve’s view was that successful companies would grow beyond the first specific problem they solved and cover more of a customer’s workflow.

For an early founder, I would start by looking closely at the steps immediately around the product.

Suppose your tool helps a salesperson research an account. The research may be useful, but the salesperson still has to decide whom to contact, prepare a relevant message, and record what happened. Ask which of those steps is preventing the research from becoming useful action.

That is an illustrative example, but the question is practical: where does the value you have created get lost before the customer can use it?

The answer might be a small integration. It might be a clearer handoff to another person. It might justify a new capability. You need evidence from the customer before deciding how much to build.

I would also look at who is asking. Several active customers struggling at the same next step tell you something different from a prospect describing an entirely new use case.

That distinction can keep expansion connected to the reason people chose you in the first place. You are learning how to complete more of a valuable job, with customers who can show you whether the change helped.

Count the work your product leaves behind

Steve questioned how much of the activity around AI was actually giving people time back.

He described people spending more time at their computers because they could now build agents and attempt tasks they had not done before. Some of that work would be valuable. He wanted to know which parts produced a useful result and which parts simply created more activity.

The same question belongs in a customer review.

If your product produces an answer quickly, how long does someone spend checking it? What happens when it is wrong? Does the result arrive somewhere the customer can act on it, or does another round of copying and coordination begin?

For a founder, I would measure one completed piece of work from beginning to end. Include the preparation, review, corrections, and handoffs. Compare that with how the customer did it previously.

Then ask what they do with the capacity they get back. Can they serve more customers, respond sooner, or spend more time on a conversation that needs their judgment?

Those observations give you a more credible account of value than the speed of the model alone. They also help you decide which product improvement is worth making next.

Put retention alongside new bookings

Steve connected weak usage to a sequence he was seeing in smaller companies: retention becomes difficult, growth slows, and the next funding round becomes harder.

He expected some of those companies to look for acquisitions or acquihires. That was his view of the market, rather than a prediction about every AI startup. But the underlying operating problem deserves attention well before a company needs another round.

A founder can be busy winning new accounts while earlier customers quietly stop depending on the product.

I would bring those earlier customers into the same discussion as the new bookings. Who is using the product regularly? Who has reduced their usage? What happened to the problem they bought it to solve?

Look for differences between groups of customers too. If one type of team keeps using the product while another needs repeated encouragement, that may tell you where to focus your sales effort and development time.

The commercial question becomes more useful when it is tied to a specific customer experience: what would need to improve for this team to want another year?

Choose one result to improve this week

Near the end of our conversation, Steve recommended Will It Make the Boat Go Faster? He liked the discipline of testing daily decisions against a small number of priorities.

His own priorities were product innovation, bookings and revenue, and retention. He also described his team using its own sales software every day, giving them a direct view of where the product helped and where it needed work.

For this week, choose one customer whose initial enthusiasm has not become regular use. Reconstruct the last time they tried to complete the relevant task. Find one point where progress stopped or unnecessary work appeared.

Agree on a change small enough to test. Decide what a better result would look like for that customer, then go back and watch what happens.

The next conversation should give you something concrete: the customer completed the work, needed less help, or came back to do it again. If the change did not help, you have a more precise problem to investigate.

What would have to change for a customer who tried your product last month to depend on it next month?

Firas.

Someone still has to speak to customers, decide what matters, design the experience, and make sure the product works. At Rox, Shriram described those responsibilities coming together in the product engineer: the person who understands the customer’s problem also builds the solution and gets it into production.

“Engineers directly talk to customers and then build from there,” he said.

That was the part of our conversation on Inside the Silicon Mind that stayed with me. AI can help a team produce software faster. The opportunity for a founder is to use that speed to shorten the distance between a customer having a problem and someone taking responsibility for solving it.

Give the builder the whole problem

Shriram, co-founder and CTO of Rox, described a role that spans customer requirements, design, frontend and backend development, and deployment. Work that previously passed between several people can increasingly sit with one engineer using AI agents.

The interesting question for a founder is how much customer understanding survives those handoffs today.

A customer explains why a task is difficult. Someone turns that conversation into a requirement. Someone else designs a screen. An engineer receives a ticket. By the time work begins, the team may have a precise description of the feature and a much thinner understanding of why anyone needs it.

That is an example of the problem I would look for in an early company. If the builder only sees the requested feature, they have fewer chances to challenge it, suggest a simpler answer, or notice that the real problem sits somewhere else.

You can test this without reorganizing the company. Bring the engineer responsible for a feature into the customer conversation. Ask them to explain the problem back in their own words, including what the customer does today and why that falls short. Then keep them involved when the customer tries the result.

A useful question at that final step is: did the customer finish the job they came here to do? The answer can be very different from whether the team delivered the ticket.

Learn how quickly someone changes their mind

Shriram calls his hiring preference “slope over intercept.” Intercept is what someone already knows. Slope is how quickly they can learn.

He connected that distinction to the way engineers now use agents. Generating more code is easy. The harder work is recognizing where the output is useful, where it is unreliable, and what needs to change.

In my world of recruitment, that is a more revealing conversation than asking someone which tools they use. I want to hear about a time they were wrong. What did they initially believe? What evidence changed their view? What did they do differently afterward?

For a founder, I would apply the same scrutiny to the team’s customer learning. When did a customer last change your mind about the product? How long did it take to act on what you learned? Did anyone go back to find out whether the change helped?

A team can release something every day and keep making the same mistake. The useful speed is the time it takes to discover that mistake, understand it, and put a better answer in front of the customer.

That also makes learning easier to assess. You can look at a specific decision, the evidence behind it, and what happened next. You do not have to rely on someone describing themselves as adaptable.

Put your own work through the product

Rox takes a particularly direct approach to learning from use. Shriram said the company runs its sales work on Rox, with no other sales tool. Its salespeople report problems in an internal channel called Rox on Rox, and he described issue resolution happening in minutes.

There is a useful pressure in that arrangement. A problem in the product interrupts the company’s own work. The people building it can hear about that problem while it is still fresh, from someone who can explain exactly what they were trying to accomplish.

It also gives the sales team something concrete to show a prospect. Shriram described them explaining how Rox helped generate the outreach, prepare the material, and book the meeting they were now having.

For a founder, the lesson I take is to find a recurring piece of work that makes your team depend on the product. Where that is practical, use it under ordinary working conditions, including the awkward cases you would leave out of a demonstration.

Then check those lessons with external customers. Your colleagues know the product, can reach the engineers, and have a reason to persist through a bad experience. A new customer may simply leave. Internal use can uncover problems quickly; customer use tells you whether the solution travels.

Keep responsibility with the person who ships it

Shriram was careful about where he trusts agents. He distinguished general product work from the deeper infrastructure connecting enterprise data systems, where security and correctness require close attention.

He also named two skills he still values: reviewing generated work well enough to stand behind it, and debugging it when something goes wrong in production.

Those responsibilities matter when one person can build and deploy much more than before. The customer still needs someone to answer for the result.

Near the end of our conversation, Shriram recommended Extreme Ownership. His takeaway as a first-time founder was that a leader has to examine their own planning, training, and communication when something fails. He described Rox starting from the position, “I’m accountable for everything.”

I think that connects directly to the product engineer idea. Give someone the context and authority to solve a customer’s problem, then make sure they remain involved long enough to see what their work actually did.

Try it on one customer problem

Choose a customer problem your team is already planning to address. Put the person who will build the solution in the next conversation with that customer.

Agree on the result the customer needs, decide how you will check it, and give one person responsibility for following it through. After the change ships, have that person watch the customer use it.

You may discover that the feature was right. You may discover that a small change would have solved the problem, or that you misunderstood it entirely. Each answer is useful if the team hears it soon enough to act.

That is the opportunity I took from Shriram’s approach: a builder who can hear the problem, make a decision, and stay with the customer until the work pays off.

How many people does a customer’s problem pass through before it reaches someone who can solve it?

Mark’s conviction came from the economics. The ability to add capacity as a business grew made too much sense to dismiss. The question was how that advantage would find its way into organizations that already had systems, responsibilities, and ways of working.

That story stayed with me after our conversation on Inside the Silicon Mind. Mark, then VP and Senior Managing Director at Intel Capital, saw a similar challenge emerging around AI. Software is becoming easier to produce. Getting it adopted inside a company still takes work.

He called this the “messy middle.” It is where a new capability has to earn its place in a real business.

Follow the work past the demo

Mark listed the things an enterprise still has to do before using a new product: security reviews, compliance checks, integration with existing systems, access to data, and authentication for the people using it. A faster development cycle does little to remove those steps.

As he put it: “Now we have to prove adoption in complex organisms.”

For a founder, that changes what you need to learn from an interested customer. A successful demonstration tells you something about the appeal of the capability. You still need to understand the work required to make it useful on an ordinary Monday morning.

Who owns the workflow? Who can approve access to the data? Who will answer for a mistake? What does the person using the product have to do differently?

Imagine an AI tool that helps a support team resolve difficult tickets. The demo produces a good answer. In daily use, that answer may depend on account information the tool cannot access, permission to make a change, and a review process for exceptions. Those details determine whether the team can rely on it.

My takeaway is to make that whole path part of customer discovery. Ask a prospective customer to walk you through the last time they introduced a new tool into this workflow. The delays, handoffs, and approvals in that story are clues about what you will have to solve.

Find where the constraint moved

Later in the conversation, we discussed people building software without a traditional engineering background. Mark saw a clear advantage: someone who understands a problem can create and change a product directly, with less lost in translation.

Then he asked the question that I think every founder should carry into planning: does the constraint simply move somewhere else?

A team that used to wait for development may now wait for an integration. A product that is easy to generate may still need someone who knows how to operate it safely. More usage can bring a compute bill that changes the economics.

Mark was careful about this. He did not claim to know where every new bottleneck would appear. He was trying to understand the tradeoffs as they emerged.

That is a useful discipline. Look at a recent customer who stalled and identify the step that stopped progress. If the delay sits outside the feature backlog, shipping more features may leave it untouched.

The next useful release might include a better data connection, a clearer deployment process, or a way for the customer to understand and control costs. Let the evidence from that customer determine which problem deserves the team’s attention.

Prove the economics at the point of use

Mark’s cloud story was about an economic advantage that could change how businesses operated. He applied the same scrutiny to AI, including the possibility that savings in development could come with higher spending elsewhere.

That matters when a founder explains the value of a product. Time saved in one step is a starting point. The customer still needs to know what it takes to get a usable result.

For the support example, I would look at a completed ticket: the model calls, the human review, any rework, and the time needed to reach a resolution the customer accepts. I would also ask what happens on a difficult ticket, when the first answer is insufficient.

The point is to understand how value and cost behave together. A workflow that works well on a handful of demonstrations needs to remain useful as it becomes a daily habit.

Bring those observations into the commercial conversation. Show the customer what you have measured, what varies, and what still needs to be tested. That gives both sides a firmer basis for deciding whether to expand.

Build the team that can get it adopted

When we discussed founders, Mark distinguished between moments when a scientific breakthrough is the decisive advantage and businesses where the challenge is getting a product into the market and used.

He values people who understand the problem deeply and can explain why their solution is better. He also looks for complementary teams with a history of creating things together. His analogy was a band: the work can change dramatically while the group keeps finding ways to make something good.

For an early company, I would bring that back to the adoption problem in front of you. Does someone on the team understand how this customer buys? Can someone work through the integration with their technical team? Who can translate an operational concern into a product decision?

These responsibilities need owners. When everyone assumes the founder will handle the difficult handoff, the company can accumulate interest faster than it can turn that interest into customers.

Run one adoption review this week

Choose one promising customer who has seen the product but has not reached regular use. Write down the result they want, the next step they need to take, and the person who owns it.

Then speak with that person. Find out what evidence, access, approval, or product change would let them move forward. Agree on one concrete action and a date to check the result.

Afterward, ask whether the obstacle appears elsewhere in your pipeline. A repeated barrier may belong on the roadmap or in your standard onboarding process. An unusual requirement may reveal that this customer is a poor fit for the business you are trying to build.

That is where I landed after talking with Mark. Faster building creates more opportunities to try something. Product-market fit still depends on customers making room for it in their work, using it again, and finding enough value to keep paying.

Where does your product stop being easy for the customer and who on your team owns getting them through that step?

That small incident inspired me to write this after our conversation on Inside the Silicon Mind. If the model underneath a product can change without the person using it noticing, what gives that person a reason to keep choosing your company?

Benny, co-founder of Fireworks AI, has spent years working on the infrastructure that makes models useful. When I asked where Fireworks had found its strongest product-market fit, his answer was two words:

“Specialized intelligence.”

He described helping companies customize open models for their work, run them at a competitive cost, and build a process for improving them with their own data.

What interested me was the continuity in that process. A better base model can arrive. The company still has what it has learned about its customers and the work they need done.

Start with demand you can already see

Before Fireworks began in September 2022, Benny and his co-founders had seen GPU demand growing inside large technology companies. Recommendation systems, driving simulations, and other applications were placing new demands on infrastructure.

They could see the pressure before they knew exactly which application would define the next wave.

The team initially explored recommendation systems. Then ChatGPT arrived, and Benny described it as a hard reset for the industry. They tried different ideas while holding onto two convictions: open models would improve, and their experience running models could help other companies.

That experience included operating production services. As Benny put it, “We know how to hold the pager.”

There is a useful distinction here for founders. You can have strong evidence that a problem is growing while still needing to discover the product customers will buy.

The work is to keep those two judgments separate. Which part of your thesis comes from repeated demand you have observed? Which part is still a proposal about how to serve it?

Fireworks’ early direction changed. The team’s understanding of the infrastructure problem gave it something concrete to work from as it made those decisions.

Define the job your customer needs the model to do

In our August conversation, Benny described work with companies including Cursor and Harvey, helping adapt models to coding and legal tasks. His explanation of Fireworks’ fit centered on making those models useful for a particular business and economical to run.

A model’s broad capabilities only tell a customer so much. The buying decision depends on whether it can do the work that matters to them, under the conditions in which they need to use it.

The routing story brings that into focus. Benny said colleagues often could not tell the difference between models during ordinary use. That was his observation inside Fireworks, rather than a claim that every model performs equally on every task.

For a founder, I would turn it into a practical question: where does your customer still notice the product falling short?

Find the task they have to redo, the answer they must check, or the step that makes the workflow too expensive. Ask them to show you recent examples. Those examples give you a much clearer target than a general request for better AI.

You also need to understand what a successful result would change for them. Saving a few seconds on an occasional task may matter less than reliably completing the one job that keeps bringing them back.

Make customer feedback part of the product

Benny kept returning to what he called the data flywheel: helping companies improve their models over time and change the base model as better options appear.

The phrase can sound automatic. In practice, somebody has to decide what counts as useful feedback and make sure it leads to a better product.

My takeaway is that a founder should be able to follow one customer correction through the business. Where is it captured? Who decides what it means? How does it change the next version? How do you check whether the change helped?

Consider a customer who repeatedly rewrites the same part of an AI-generated answer. That could point to missing context, a poorly defined task, or a capability the model does not yet handle. Storing the interaction alone will not tell you which one it is.

You have to understand the correction, use data you have permission to use, and test the resulting change against examples that matter to the customer.

This also gives you a way to judge model upgrades. Keep a set of real tasks and known failures. When you try a new model, check whether it improves those outcomes and what it costs to deliver them.

Over time, that record becomes valuable knowledge about the work your customers need done. It can guide product decisions even when the technology underneath changes.

Keep the ability to change

Benny is concerned about businesses whose continued operation depends on access to a single model provider. Fireworks’ mission, as he described it, is to help companies become more self-sufficient through models they can customize and control.

For an early company, the practical question is how much freedom you need to keep delivering the customer’s result.

A hosted model can be a sensible way to start. As the product becomes part of a customer’s daily work, it is worth understanding what you would need to change providers, adjust deployment, or respond to different costs.

That does not require building every layer yourself. It does require knowing which parts of your product depend on a particular supplier, and whether your evaluation process and accumulated customer knowledge can move with you.

The more clearly you understand the customer’s task, the better placed you are to make that decision. You can judge a replacement against the result you promised.

Trace one improvement all the way through

Before your next product meeting, choose one recurring customer task. Bring examples of where the current product succeeds and where someone has to correct it.

Pick one failure to work on. Agree on the improvement the customer should notice, make the change, and return to those examples to check it. Then see whether the customer uses the improved workflow again.

A feedback process does not establish product-market fit by itself. You still need customers who choose the product, keep using it, and pay for the value it delivers. But it gives each customer relationship a chance to make the next version more useful.

That is what I took from Benny’s account of Fireworks. The models will keep changing. A company that understands its customers’ work, and turns that understanding into repeated improvement, has something it can carry forward.

What did your product learn from its customers this week, and where will they feel the difference?

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?

He wanted to know why she would want it. She was thinking about a different problem entirely.

As she understood it, losing a phone wouldn’t mean losing what she had access to. She wanted to take a big phone with good cameras to the kids’ events, then carry a little flip phone when she went out with her friends.

“Why can’t I change my phone out the way I changed my purse out?”

Jared had been thinking about people communicating in places where an enemy was looking for them. His wife was thinking about which phone to take to dinner.

She had found a reason to want the technology that had nothing to do with its original mission.

When you’ve spent years working on a problem, you become fluent in the reason your product exists. You know the benefit you’re trying to deliver. Your team can explain it almost without thinking.

Somebody else’s reason to want it can be harder to hear, especially when it falls outside the story you’ve been telling yourself.

He had a problem before he found the technology

Jared founded Intelligent Waves in Baghdad and grew it around doing IT in difficult places. Later, a general asked him to find a way for people to communicate securely in a hostile environment.

His team worked on concealing network activity and on accessing enterprise systems without keeping sensitive working data on the phone. One of his colleagues came across Hypori and thought its technology might help.

Jared called to ask about licensing it. The CEO told him he had been hired to close the business. The board was withdrawing its support and preparing to liquidate the assets.

Instead, Jared went to Austin to see the technology and meet some of the original developers. He bought the intellectual property for $1 million and hired six of them into Intelligent Waves.

He recalled that the remaining employees had about ten days before the company was due to close.

What gave him a reason to investigate was the job his team already needed to do. They could examine the technology against that job and work out what it would take to make it useful.

Hiring the original developers meant his team could draw on the people who had built it.

Jared said the team solved the mission problem. That was when he began to see how much further the approach might reach.

Privacy came from the way they solved it

Hypori, as Jared described it, provides access to a virtual operating system running in a data center. The screen is streamed to the phone. The enterprise’s working data stays in the remote environment.

The team had started with the assumption that the phone might already be compromised. The question was how to let someone work without depending on that phone being trustworthy.

Jared then realized something about the separation they had created. They didn’t need to know what was on the person’s own phone to give them access to the enterprise. That meant the person could keep their privacy.

“I wish we had said that we developed it this way on purpose, but it was really kind of a side effect,” he told me.

A design choice made for a difficult security problem had produced another reason to want the product.

The enterprise cared about protecting its systems. The person carrying the phone could care just as much about keeping an employer out of their personal life.

If you’re the employee, a presentation about security may leave a very ordinary question unanswered: what can the company see on my phone?

That is part of the product experience too. The person using it has interests that may never appear in the buyer’s list of requirements.

For a founder, there’s a worthwhile question here. What does your product let somebody stop giving up to get their work done?

When somebody describes the value differently, find out whether they’re giving the same benefit a more familiar name or pointing to a consequence you’ve barely considered. Those answers can lead to different decisions.

The next possibility still needs a customer

Jared’s wife took the idea further. She was interested in choosing a device for the occasion without having her digital life tied to one piece of hardware.

He had been looking at what the technology could protect. She was looking at what it could let her change.

She explained the appeal through something as familiar as a purse. She didn’t need his technical language to understand what she wanted.

Her question suggested a possible use. It left open whether there was a consumer market for it. Turning the idea into something people could choose, use reliably and pay for would require a lot more work.

That distinction matters if somebody asks for something that takes you beyond your current plan. An interesting request can become a whole new roadmap before you’ve found out how many people share the problem.

Start by asking the person to walk through the last time that situation occurred. Find out what they do today and what it costs them. Then speak to others in the same position.

If the need repeats, test whether the product can actually serve it. Look for people who will use it in a real situation and make a commitment to continue. Interest in an idea gives you much less to work with than somebody making room for it in their day and paying for the result.

You can investigate a larger opportunity while staying demanding about what you have learned so far.

A use worth pursuing still needs a team with time to develop it. Jared had to change the organization around Hypori to give it that room.

It was still inside Intelligent Waves. In his telling, the services business needed low overhead to deliver competitively, while the product needed investment in development. The two businesses kept pulling against each other.

He believed keeping them together would damage both. He appointed a CEO to run Intelligent Waves and spun Hypori out.

A founder growing a product alongside client work may recognize that pressure. The next project has a deadline. Product development requires spending now for something the business hopes to sell repeatedly later.

Jared chose to separate the businesses. For another company, the immediate question might be whether the product has a budget and a team whose time survives the next urgent client request.

Who gets to teach you something

We began our conversation with Jared’s life before either company. As a teenager, he had been homeless, sleeping in an old Lincoln behind a gas station. He said the memory still helps him avoid thinking he is better than anybody else.

When I later asked what he would tell a founder who had lost faith, he spoke about being receptive to mentorship from anybody. Someone who had spent twenty years as a janitor might have lessons he could learn from. Success didn’t make him too important to listen.

His colleague found technology worth investigating. The original developers knew how it worked. His wife described a use that was far outside the military problem he had been solving.

Each had something he needed to hear.

As a founder, you still have to decide where to spend your time. But first you have to hear the person well enough to understand what they’re describing.

Before your next product meeting, choose a customer who is already getting value from what you’ve built. Ask them to describe the last time they used it and the part they would miss most. Speak to the person using the product as well as the person who pays for it.

Compare their answer with the benefit you lead with when you sell. If they’re different, find out why. It might change how you explain what you already do. It might give you a new problem to investigate.

I have a great team. Building it has taken time, patience and a lot of work. Still, I had sat down with the people responsible for growing it and told them we needed to move faster.

Then I asked Sandeep what he sees great founders do in their first twenty-four months that people don’t talk about enough.

His answer was patience.

You can imagine why I wanted him to explain that one.

When you’re building a company, you can see everything that needs to happen. Customers need something delivered. Roles need filling. There’s a window of opportunity you’re worried about missing. You make a decision, put people behind it, and expect the results to arrive with the same urgency you feel.

Sandeep’s point was that the market has its own pace. Customers need time to respond to a product, a message or a price. You can do the work quickly and still have to wait to understand whether it worked.

That waiting period is where a founder can become a problem for their own company.

You launch something. The early results look encouraging, but they’re smaller than you hoped. You start questioning the approach. Soon, the team is changing something it has barely had time to learn from.

Sandeep put a useful question to that feeling: “Well, why did you think that, first of all, to begin with?”

Where did the expectation come from? Customer evidence? Previous results? Or had you simply decided that by now, things should be further along?

I think that question deserves a place in more founder meetings.

It forces you to examine the expectation with the same seriousness you bring to examining the result. Otherwise, your disappointment can become the reason for a change, even when the evidence still supports what you’re doing.

Sandeep described a practical way to approach this. Before changing a price or launching a message, decide what you expect to see. That could be a change in lead flow or customer acquisition. Once it is running, look at whether those measures are moving in the direction you intended.

Progress can be slower than you wanted and still give you a reason to continue.

For a founder looking for product-market fit, I would take that one step further. Write down what would justify continuing, what would make you reconsider, and when you will review it. Choose a period that gives your customers a reasonable chance to respond, within the time and money you can afford to spend.

You might be testing whether a different onboarding experience helps more customers reach the first useful result. Or whether people who try the product come back and pay. Be specific enough that the next conversation can begin with what happened.

Otherwise, every review risks becoming a discussion about how patient everybody feels that week.

There’s an uncomfortable complication here. Founders also have instincts, and those instincts sometimes tell them something useful before they can fully explain it.

I asked Sandeep how he deals with that. His answer was more flexible than his earlier emphasis on data might suggest. He trusts his judgment about people, shaped by experience. With a strategic decision, such as a potential partnership, he lets the initial reaction start the investigation.

“I can start with an impulse, but I won’t end with an impulse.”

That gives the instinct somewhere productive to go. A partnership looks promising. Fine. What would you need to learn about the customer, the distribution or the work involved before committing to it?

Sandeep said some of his biggest regrets came from decisions he hadn’t supported with enough evidence. He described investing on the strength of a trusted person’s recommendation without doing enough of his own work to understand the business.

Trust had made the decision feel easier. It hadn’t answered the underlying questions.

The same problem can show up when someone you respect tells you to change your pricing, pursue a different customer or add a feature. Their confidence is persuasive. You still have to work out whether the reasoning applies to your company.

Later in our conversation, Sandeep gave an example of how Heald approaches a specific problem.

The company supports people with their metabolic health, combining technology with a human care team. During onboarding, members need to connect devices such as glucose monitors and smart scales to the app. Initially, that involved sending instructions and getting someone on a call to help.

Heald introduced an AI onboarding agent to guide members through the process and gather information along the way. Sandeep said it significantly reduced onboarding time and freed the team to focus elsewhere. When a member preferred human help, a person could step in and finish the process.

What I liked about this example was how easy it was to understand the job the technology had been given. There was an existing task taking people’s time. The team changed how it was handled and observed an improvement.

There was also room for the customer to respond differently than the product team might hope. A member who wanted to speak to a person could still do that.

That matters when you’re trying to learn. If you become too attached to how you want customers to use the product, you can miss what their behavior is telling you. In this case, the human support remained part of completing the experience.

Sandeep didn’t give a percentage reduction in onboarding time, and faster onboarding alone doesn’t establish product-market fit. But it gives a team a concrete result to investigate further: are more people getting started successfully, does the improvement last, and what happens after they get through the setup?

Those are questions you can keep working on while giving the change time to prove itself.

I came back to that hiring conversation as we spoke. Sandeep was trying to fill five roles himself, mostly on the growth side. They had been open longer than he expected. He still wasn’t prepared to hire someone simply because there were forty resumes and he felt a decision was overdue.

I recognized the pressure immediately. An open role starts to feel like something you need to make disappear. The work is waiting. Your team is stretched. You want an answer.

But the urgency doesn’t tell you which candidate can do the job. You have to keep doing the work of finding out.

That is the part of patience I took from our conversation. There is plenty to do while an answer is developing: speak to customers, examine the results, question your assumptions, find the next candidate. You can stay demanding about that work while being honest about what you don’t yet know.

Before you change the strategy this week, go back to the reason you chose it. Look at what has happened since. Then ask whether the evidence has changed enough to warrant a different decision.

It’s a harder question than whether things are moving fast enough. It’s also more likely to help your team decide what to do next.

Your team still gets the call when it breaks.

You can accelerate the creation of a system without accelerating your ability to understand it. The feature ships. The product gets more capable. Then a customer cannot log in, a payment fails, and someone has to work out what happened across services they did not build.

The productivity gain is easy to demonstrate. The work it leaves behind is harder to see until somebody has to do it.

Anish Agarwal sees this tension in software engineering. In our conversation on Inside the Silicon Mind, he described engineers inheriting more review and production cleanup as AI writes more code. The promise was more time for creative work. The immediate experience can be a longer queue of things to check and fix.

Anish is the co-founder and CEO of Traversal, which is building AI agents to investigate production incidents and help keep software reliable.

If you are deciding what to build, pay attention to this pattern:

When a breakthrough makes one part of a workflow faster, look for the work piling up afterward.

Progress moves the bottleneck. Sometimes it moves the market with it.

1. Find the assumption that is breaking

A dashboard is a small act of prediction.

Someone decided which information would matter the next time something went wrong. They wrote a query, chose a graph, and put it where another person could find it.

Anish calls it an “enshrined query.”

For years, this has been central to observability: the tools engineers use to understand what is happening inside a software system. Logs record events. Metrics measure performance. Traces follow a request as it passes between services. Dashboards turn selected pieces of that information into something a person can read.

You can create ten times as many dashboards without giving an engineer ten times the capacity to hold the relationships in their head.

Anish describes incident calls that grow as the investigation moves from team to team. The database group gets pulled in. Then an application team. Each has a piece of the picture. The call can reach fifty or sixty people before someone with years of experience connects the clues.

The software has generated plenty of information. Understanding still depends on assembling the right people in a room.

And the system keeps changing. The dashboard reflects what somebody already knew to look for. The next failure may happen in a way nobody anticipated.

AI adds another pressure. Anish argues that an engineer responding to an incident may understand less of the underlying code and telemetry when AI produced them. The team has more software to operate, with less firsthand knowledge of how it was assembled.

The old problem was keeping software running. The changing condition is how much of that software a person can reasonably understand.

A familiar problem can become newly urgent when the assumptions behind its solution stop holding. You do not have to discover pain nobody has ever felt. You can notice why the way people have been managing it is starting to fail.

Ask what your customer’s current solution quietly expects a human to do.

Remember the history of every decision? Read every output? Connect evidence scattered across six tools?

Then ask what happens when the volume doubles.

2. Look beneath the market label

Anish and his co-founders began with a sense of the kind of problem they could solve before they had a company idea.

He and two of his co-founders had met while doing their PhDs at MIT. Their research included causal machine learning and reinforcement learning. They were interested in how systems learn cause and effect, and how they search through large spaces of possibilities.

A fourth co-founder, who came from Citadel Securities, introduced them to the reliability problem.

Underneath the unfamiliar industry vocabulary, they recognized familiar mechanics.

A software system is a network. One thing breaks and the effects spread. Soon, several things look broken. Some are symptoms. Some are unrelated. One may be the cause.

The challenge is to distinguish them while searching through an enormous amount of evidence.

“It felt like we were designed for this problem,” Anish said.

A market label can hide a problem you already understand deeply.

That is one way to find founder-market fit: recognize where your particular expertise matches the underlying difficulty.

But you still need the people who understand how the problem shows up in practice.

At Traversal, researchers work alongside experienced site reliability engineers, or SREs: the people who operate systems and keep them resilient. Anish described an SRE working closely with the research team, bringing years of troubleshooting experience into the development of the AI.

The research explains what might be possible. The operator helps reveal what will actually work.

If you are choosing a problem, look for that combination. A relevant technical advantage becomes more valuable when it meets a precise understanding of the customer’s daily frustration.

3. Rebuild around whoever does the work

Once an agent becomes the investigator, the implications reach beyond the interface.

A human needs information presented in a form they can scan and understand. An agent may need to search much more of the data in parallel, choose which evidence to pursue, and preserve what it learns for the next investigation.

Anish sees that as a reason to rethink how observability data is stored, indexed, and queried.

Existing dashboards can still help. He describes them as a useful starting point because they contain knowledge about what people previously considered important. But an agent may store and reuse its own discoveries in a different form.

Changing who does the work can change the system the work requires.

For founders, the question becomes concrete: which parts of the current product exist because a human has to operate them? What becomes unnecessary when that changes? What new capability becomes essential?

There is a second boundary to examine: the one between vendors.

Anish describes large enterprises using multiple observability tools. A customer cannot complete a purchase, but the issue may be several services away from checkout. The evidence needed to trace that failure can be spread across products owned by different vendors.

The customer experiences one broken journey. An engineer has to assemble the explanation from several places.

Anish argues that vendors whose pricing depends on the data customers bring into their platforms have an incentive to draw more data inside. Traversal’s approach, as he describes it, is to investigate across the existing systems and sell the value of the answer.

“We want to sell you the outcome,” he said.

Even in a crowded market, examine what a customer still has to do after buying the tools.

Who joins the pieces? Who resolves the contradictions? Who is responsible when the individual products work but the overall job remains unfinished?

The manual effort between products can reveal an opportunity that a feature comparison will miss.

4. Follow the work all the way to the end

Anish compares severe incidents to heart attacks, recurring alerts to chronic conditions, and long-term resilience work to improving your health before something goes wrong.

Emergency work consumes the attention that could help prevent the next failure.

Traversal’s ambition is to change that allocation. Anish expects agents to take on more investigation, involving people for verification or when an answer is uncertain. Engineers would have more time to improve the underlying system.

That is the human value behind the technical work: giving someone room to do the work they wanted to do in the first place.

The same standard should apply to your product. If you remove an hour of effort but create an hour of checking and correcting somewhere else, the customer may never feel the gain you put on your slide.

For a reliability product, that means measuring the time it takes to reach a diagnosis the team can act on. A fast answer that still requires a room full of engineers to investigate it leaves much of the job unfinished.

The person handling the exceptions often has the clearest view of what the automation left unfinished.

Spend time with that person.

Try this in your next customer conversation:

1. Choose a workflow that is already getting faster. Find someone using AI in real work. Ask who handles the output and who owns the consequences when it goes wrong.

2. Reconstruct the last difficult case. Have that person walk you through an actual example. Record the tools, handoffs, waiting, investigation, and rework. Find where effort accumulates as volume increases.

3. Name the failing assumption. Write down what the existing solution expects a person to know or do. Test whether that expectation is still reasonable at the customer’s current scale.

4. Prove one complete outcome. Agree with the owner on a small pilot and a measure that includes the work of verifying and acting on your answer. Compare it with their current process. Then test whether they will pay to keep using it.

A growing bottleneck gives you a hypothesis. Product-market fit requires the customer’s behavior to confirm it.

Watch what happens after the demo: whether the product enters the workflow, removes effort across the whole job, and earns repeated use.

AI is making more things possible. It is also changing which things are difficult.

Pay attention to where that difficulty goes.

Your next market may be there.

You can spend months crafting the perfect product narrative, refining your positioning, and obsessing over what you believe you’re building. Then customers arrive and describe your company in completely different terms.

When I sat down with Jonathan Mortensen, founder of Confident Security, this was one of the insights that stayed with me long after the conversation ended.

Jonathan shared a lesson he learned while building one of his previous startups: you’re in the business your customers think you’re in, not the business you think you’re in. The company began with one vision, but customers consistently bought it for another reason. Instead of resisting that reality, the team embraced it, repositioned the company around what customers actually valued, and found a far stronger product-market fit.

It’s a deceptively simple idea, but one I think many founders overlook.

Product-market fit isn’t something you define in a pitch deck.

It’s something your customers define through their behaviour.

Jonathan also spoke about the trade-offs every startup faces. The more novel your product, the easier it is to command attention and premium pricing. But if you’re building something incremental, success depends far more on distribution, marketing and execution. Every company is making that trade-off, whether they realise it or not.

The conversation reminded me that startups aren’t just about building products; they’re about learning. Every customer conversation is feedback. Every rejection is information. Every product iteration is another opportunity to get closer to what the market actually wants.

Jonathan recommended the book Skunk Works, which tells the story of Lockheed Martin’s legendary engineering team. His biggest takeaway wasn’t about aerospace: it was about iteration. The world’s most advanced aircraft weren’t designed perfectly the first time. They were the result of rapid experimentation, continuous learning and relentless improvement.

The same principle applies to startups.

The founders who build enduring companies aren’t always the ones with the best original idea.

They’re the ones humble enough to let the market reshape it.

Until next time,

Firas Sozan

The PMF Playbook

If AI can build software for almost anyone, what actually makes a software company valuable?

When I sat down with Lenny Pruss, General Partner at Amplify Partners, his answer wasn’t code, infrastructure or even AI.

It was trust.

For decades, software companies built moats because writing great software was difficult. That technical advantage created enough lead time to win customers, establish distribution and become the default solution. Today, AI has dramatically compressed that window. What once took years can now be replicated in weeks.

That changes everything.

Lenny argues that the new competitive advantage isn’t simply building faster, it’s earning trust faster. Customers aren’t buying software because it’s novel. They’re buying confidence that it will work tomorrow, next month and years from now. Reliability, support, security and consistency become increasingly valuable as software itself becomes easier to create.

This is particularly true in infrastructure. No matter how capable AI becomes, businesses still need systems they can rely on for mission-critical workloads. That’s why developer trust, brand reputation and customer advocacy become far stronger moats than technical complexity alone.

The conversation also reinforced something I’m seeing every day as an investor and recruiter.

Speed still matters but speed without trust doesn’t compound.

The companies that break out won’t simply ship the fastest product. They’ll win production workloads, delight early customers and build credibility quickly enough that those customers become their strongest advocates.

In a world where software is becoming increasingly abundant, trust may become the scarcest asset of all.

Until next time,

Firas Sozan

When I sat down with Eli Chen, Partner at AI Fund, he made a distinction that completely changed how I think about the future of talent.

Coding, he argues, is rapidly becoming commoditized. AI can already generate software in hours that once took teams of engineers months to build and the cost of writing code is falling towards zero.

Engineering isn’t.

Engineering is the ability to make decisions. It’s choosing architectures, balancing trade-offs, understanding customers, and designing systems that solve real problems. As AI removes the bottleneck of writing code, those human decisions become even more valuable.

What fascinated me most was how this changes company building.

If building an MVP is no longer the hard part, then finding product-market fit becomes the bottleneck. The winners won’t simply build faster but they’ll learn faster. They’ll iterate with customers more quickly, develop stronger product intuition, and cultivate better judgment about where AI genuinely creates value rather than simply adding hype.

Eli believes the founders breaking out today share one defining characteristic: iteration speed.

Not because they work longer hours alone, but because they understand AI deeply enough to make better product decisions. They build constantly, learn constantly, and refine their thinking through first principles rather than assumptions.

Perhaps the biggest takeaway from our conversation is that AI isn’t replacing engineers.

It’s raising the bar.

The future belongs to builders who combine technical intuition, product taste, customer empathy, and relentless curiosity. As the cost of creating software approaches zero, the quality of thinking behind it becomes the ultimate competitive advantage.

Until next time,

Firas Sozan

The PMF Playbook

Most cybersecurity companies are built around a simple promise: stop attackers from getting in.

Shachar Hirshberg, co-founder and CEO of Artemis, believes that assumption is already outdated.

When I sat down with Shachar, he painted a future that feels uncomfortably close. A world where cyberattacks are fully autonomous. Where AI-powered attackers can move from initial access to data exfiltration in seconds, not days. A world where sophisticated attacks, once reserved for nation states, become available to anyone with access to the right AI tools.

The striking part wasn’t his prediction.

It was his conclusion.

Getting in is becoming inevitable.

For years, cybersecurity has focused on building taller walls. Better firewalls. Better prevention. Better detection at the perimeter. But Shachar argues that AI has fundamentally changed the economics of attacking. Intelligence is cheaper. Sophisticated attacks are easier. The barrier to entry continues to fall.

So if attackers eventually get in, the real question becomes: what happens next?

That insight became the foundation for Artemis.

Rather than obsessing over keeping attackers out forever, Artemis helps organizations understand their own environment so deeply that they can detect, contain, and neutralize threats before meaningful damage occurs. Shachar compares it to an immune system. The goal isn’t preventing every virus from entering the body. The goal is identifying what’s abnormal and responding before the infection spreads.

What stood out most to me was his view on competitive advantage.

Most people assume AI will create symmetry. Everyone gets access to the same models. Everyone gets access to similar technology.

But Shachar believes defenders still have one advantage attackers never will.

Context.

An attacker might know an exploit. They might know a vulnerability. They might even know how to gain access.

But they don’t know your business.

They don’t know which employee should have access to which system. They don’t know which server is critical to revenue generation. They don’t know what normal looks like inside your organization. That knowledge belongs to the defender. And in an AI-driven world, that context may become the most valuable asset of all.

As our conversation moved beyond cybersecurity, I asked Shachar where he sees the biggest opportunities for founders.

His answer was surprisingly simple.

Look for industries where AI doesn’t just improve workflows but fundamentally changes the economics of what’s possible. Then build for the world that’s coming, not the one that exists today.

It’s the same philosophy that led him to start Artemis. He didn’t wait for autonomous attacks to become commonplace. He looked at where the technology was heading and built for that future first.

And maybe that’s the broader lesson.

The best founders aren’t reacting to change.

They’re positioning themselves ahead of it.

Until next time,

Firas Sozan
The PMF Playbook

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

Most startup stories are told through outcomes. Funding rounds. Product launches. Hypergrowth. Acquisitions. The headlines focus on the moments when things work. What we hear far less about are the moments when things almost don’t.

I sat down with Howard Ting, former CEO of Cyberhaven and current CEO of Opal Security. Our conversation went somewhere I wasn’t expecting. It wasn’t really about cybersecurity. It wasn’t about fundraising. It wasn’t even about product-market fit.

It was about responsibility.

Howard took over Cyberhaven in 2020, in the middle of COVID. Like many startup CEOs, he expected difficult decisions, long hours, and the pressure that comes with scaling a company. What he didn’t expect was that two years later Russia would invade Ukraine, where roughly 80% of his engineering organization was based. Two months before the invasion, Howard had been in Kyiv visiting employees, having dinner with team members and meeting their families. Then overnight, everything changed.

Engineers were being drafted into military service. Families were being separated across borders. Employees were trying to escape the country. The company suddenly faced an existential question: what happens when the majority of your product development team is sitting in the middle of a war zone?

What struck me wasn’t the operational challenge. It was Howard’s response.

His first principle was simple: family, country, company.

Not company first. Not productivity first. People first.

While many leaders would immediately focus on preserving business continuity, Howard focused on helping employees and their families survive an impossible situation. The company worked through relocation options. They explored legal pathways to help employees leave the country. They continued supporting people financially. They looked after families. Only after addressing the human problem did they turn their attention to the business problem.

Listening to Howard reminded me that leadership often looks very different from how Silicon Valley portrays it. We love talking about vision, strategy, and execution. But in reality, leadership is usually tested during moments where there is no playbook. Moments where the right answer isn’t obvious. Moments where every decision carries consequences for real people.

As the conversation evolved, I asked Howard what he believes causes companies to fail. His answer surprised me because it was both simple and universally true.

People.

Not funding. Not competition. Not technology.

People.

He described three common failure modes. The first is hiring the wrong people for the stage of the business. The second is hiring people with the wrong motivations. Early-stage companies need missionaries, not mercenaries. They need people who believe deeply enough in the mission to endure uncertainty, setbacks, and constant change. The third failure mode is one that doesn’t get enough attention: failing to develop the people already inside the company.

This resonated with me because recruiting has taught me the same lesson repeatedly. The best companies aren’t built by endlessly hiring stars from elsewhere. They’re built by identifying potential early, creating opportunities, and helping people grow into larger roles. Great organizations compound talent internally.

But perhaps the most thought-provoking part of our conversation was when Howard described how his definition of ambition has changed.

Earlier in his career, he was what he calls “locally ambitious.” Like many of us, he focused on advancing himself, his team, and his company. Today, he thinks differently. He described himself as “globally ambitious.”

Instead of asking how he can win, he asks what impact his life’s work will leave behind.

That mindset is what ultimately brought him back to identity security, a problem he first worked on more than two decades ago. Despite enormous advances in technology, many of the core challenges remain unsolved. Rather than chase the next trend, he chose to return to unfinished business.

I think that’s a powerful lesson for founders.

The best opportunities aren’t always the newest ones. Sometimes they’re the problems you’ve understood deeply for years but finally feel compelled to solve.

The final part of our conversation centered on something many founders, executives, and ambitious professionals struggle with: the cost of building.

We often celebrate sacrifice in Silicon Valley. The late nights. The obsession. The relentless pursuit of excellence.

What we discuss less often is what that sacrifice means for the people around us.

Howard spoke candidly about the impact that building companies has had on his family. The missed dinners. The lost time. The moments that don’t come back. But he also offered a perspective that stayed with me.

Children don’t only learn from the time you spend with them.

They learn from what they watch you dedicate yourself to.

Howard’s parents owned a small Chinese restaurant near Berkeley. He rarely saw them because they worked constantly. Yet what they gave him wasn’t advice or instruction. It was an example. Through their actions, they taught resilience, perseverance, and grit. Those lessons shaped who he became.

It made me think differently about ambition.

There is always a cost to pursuing something meaningful. The challenge isn’t eliminating the sacrifice. The challenge is ensuring the sacrifice is attached to something worth pursuing.

When I reflect on this conversation, I don’t think the biggest lesson is about leadership or even entrepreneurship.

It’s about people.

Product-market fit matters. Strategy matters. Timing matters.

But businesses are ultimately collections of people working toward a shared mission. The strongest companies survive because people trust each other during difficult moments. Customers trust them. Employees trust them. Investors trust them.

And that trust is built long before the crisis arrives.

Until next time,

Firas Sozan
The PMF Playbook

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

This week’s PMF Playbook comes from my episode with Cosmin Nicolaescu, Co-Founder and CEO of Accrual.

Cosmin has had one of those rare Silicon Valley journeys: Microsoft, Stripe, Brex, and now founder. He has seen massive companies, high-growth startups, and hyper-scaling cultures from the inside. But what made this conversation valuable was not just his resume. It was his honesty about what changes when you become the founder.

The biggest shift is simple: you lose optionality.

An employee can decide the company is no longer right for them and move on. A founder cannot do that so easily. The more people join, the more customers depend on you, the more investors believe in you, the more locked in you become. Every hire adds responsibility. Every customer adds obligation. Every decision starts to carry more weight.

That is the part of founding that people romanticize less often.

Let me walk you through what stood out.

The founder burden: responsibility compounds

Cosmin described founding as lonely, not because you are physically alone, but because you are constantly balancing different time horizons.

Investors want growth. Employees want momentum and meaning. Customers want features, reliability, and value as quickly as possible. And the founder has to hold all of that at once while still making decisions that keep the company alive and moving forward.

That is a different kind of pressure from being an operator.

At Microsoft, Cosmin was one engineer among many. At Stripe, he saw what great culture looked like in a high-growth environment. At Brex, he stepped into a much larger leadership role, leading engineering without the same safety net.

But founding Accrual introduced something else entirely.

When someone joins your early company, they are taking a real risk on you. Cosmin said every person who joins adds a little more stress, because each person is betting part of their career on the company’s vision.

That is the emotional weight of founding.

The regret framework: why inaction can be worse than failure

When Brex came calling, Cosmin was happy at Stripe. He was growing, building important products, and working with great people.

But he knew that one day he wanted to lead engineering at a company without a safety net.

So he used a regret minimization framework.

If he stayed at Stripe and Stripe did well, that was fine. If he joined Brex and Brex did well, that was great. If he joined Brex and it failed, he would lose time but learn from the experience.

The worst outcome was staying at Stripe and watching Brex become huge without ever knowing what he could have learned by taking the leap.

That is a powerful career lesson.

Action teaches you something. Inaction only leaves you wondering.

Why accounting passed the founder-market fit test

When Cosmin and his co-founder started exploring what to build, they looked across many industries. They were optimizing for two things: impact and learning.

Accounting passed the test because it sits at the backbone of business. Every dollar that moves has to be accounted for. Yet the industry remains deeply manual, with accountants spending huge amounts of time on mechanical, repetitive work instead of strategic judgment.

They also saw a market under pressure.

Fewer people are becoming CPAs. Many accounting firm partners are aging. Firms want to grow, but they cannot hire enough people. At the same time, accountants care deeply about doing right by their clients.

That passion for the craft resonated with Cosmin.

This is an underrated founder-market fit lesson: you do not just need to like the problem. You need to like the people you are serving. If you do not enjoy spending time with your customers, the journey becomes much harder.

Founder-market fit as a lifestyle choice

One of the most interesting parts of Cosmin’s story is that he and HIS Co-Founder did not just study accounting from the outside.

They took CPA classes at community colleges.

That is not founder-market fit as a talking point. That is founder-market fit as a lifestyle choice.

Their reasoning was simple: they could not replicate decades of CPA experience, but they could at least understand the baseline knowledge of someone entering the profession.

That depth matters.

Without it, it is easy to oversimplify a complex industry. Accounting can look mechanical from the outside. But once you go deeper, you see the nuance: judgment, planning, trade-offs, regulation, client context, and strategic decision-making.

The PMF lesson is clear: if you want to transform an industry, first respect it enough to learn its language.

Accrual: creating time for accountants

Accrual works with some of the largest accounting firms in the United States.

The problem they are solving is time.

Accountants spend too much of their day on tactical, mundane, mechanical work. Accrual removes as much of that work as possible so accountants can spend more time on what actually matters: helping clients make better financial decisions.

Cosmin described the mission as creating accountants out of thin air.

Not by replacing accountants, but by giving firms back massive amounts of capacity.

That is the right AI wedge in a professional services market. Not “replace the expert.” Instead: remove the work that prevents the expert from being an expert.

The customer lesson: acquisition is not the win

Cosmin made a point that every founder should sit with:

Customers are the only thing that really matters.

You can fundraise without customers. But that does not mean you have a business.

The first signal is that you can acquire customers. The second is that you do not lose them. The third, and maybe the most powerful, is that customers start pulling you into new directions.

That means they trust you. It means your product is landing. It means they see you as a partner, not just a vendor.

But Cosmin also warned against a common founder mistake: over-optimizing for growth.

Some founders treat customers as acquisition logos. They win the deal, celebrate the growth, and move on to the next one. But trust is earned slowly and lost quickly.

In accounting especially, change management is hard. If accountants are spending most of their day in your product, the experience has to be excellent. Otherwise you are not improving their work; you are making their day worse.

The lesson here is simple: landing the customer is not the finish line. It is the beginning of the obligation.

The real founder transition

The deepest difference between operator and founder is not decision-making, speed, or even ownership.

It is responsibility.

As an operator, Cosmin cared deeply about building good teams and being a strong leader. But as a founder, the stakes feel different. If the company fails, it is not just a business outcome. It affects the people who took a risk to join.

That responsibility compounds with every hire.

And that may be the clearest sign of founder maturity: understanding that the company is no longer just your ambition. It is now other people’s risk too.

Closing thought

If I compress the entire episode into one sentence, it’s this:

PMF is not just about finding a painful market; it is about earning enough trust to remove real work from customers’ lives without disrespecting the craft they have spent years mastering.

Accrual is not trying to make accountants irrelevant.

It is trying to give accountants their time back.

And in a world where every professional services firm is under pressure to do more with fewer people, that may be one of the most valuable products you can build.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

Not the kind of frustration that comes from reading a market report or spotting a trend on social media. The kind that comes from living inside a problem for years. The kind that comes from seeing the same inefficiency, the same bottleneck, or the same failure point over and over again until you can no longer ignore it.

When I sat down with Peyton Smith, founder of Specular and former Red Team operator at CrowdStrike, I expected to talk about cybersecurity. Instead, I found myself thinking about entrepreneurship.

For five years, Peyton’s job was to do something most companies spend millions trying to prevent. He was paid to break into their systems.

His team would simulate real-world attacks against large organizations, exposing vulnerabilities before real attackers could exploit them. The mission was simple: find the weaknesses before someone else does.

What struck me wasn’t that vulnerabilities existed. Every company has vulnerabilities. Every system has weaknesses. Complexity guarantees that. What stood out was how often the same pattern repeated itself.

Organizations had security teams. They had budgets. They had tools. They had processes. Yet time and time again, vulnerabilities remained hidden for far longer than they should have.

The issue wasn’t a lack of effort. The issue was the model itself.

For years, cybersecurity has largely operated on periodic reviews. Companies conduct assessments, penetration tests, audits, and security exercises at set intervals. Problems are discovered, reports are generated, fixes are made, and everyone moves on until the next cycle begins.

But attackers don’t operate on a schedule.

They aren’t waiting six months for the next assessment. They aren’t waiting for the next quarterly review. Threats evolve continuously, while many organizations still evaluate risk periodically.

That gap became impossible for Peyton to ignore.

And that’s where the entrepreneurial journey really begins.

Not with technology. Not with AI. Not with a funding round.

With a question.

What if security could operate continuously instead of periodically?

The more I reflected on our conversation, the more I realized this pattern exists across every industry. The best founders aren’t necessarily the ones who predict the future. They’re the ones who see the present more clearly than everyone else.

They notice an assumption the market has accepted and start questioning it.

Why does it work this way?

Why have we always done it like this?

What if there’s a better approach?

Today we’re living through an AI gold rush. Every company claims to be AI-powered. Every founder is talking about agents, automation, and transformation. Most of those companies won’t survive.

Not because the technology isn’t impressive.

Because technology alone has never been enough.

The companies that endure are usually built by people who understand a problem at a level others don’t. Long before the technology exists, they’ve experienced the pain firsthand. They’ve seen the inefficiencies. They’ve felt the frustration.

The technology simply arrives at the right moment to make the solution possible.

That’s what stood out to me about Peyton’s story.

He wasn’t chasing AI.

He wasn’t building because the market suddenly became interested in cybersecurity.

He was solving a problem he had lived with for years.

The technology changed. The problem remained.

And that’s often how enduring companies are built.

Not by chasing trends, but by developing conviction.

The best founders don’t discover problems.

They live them.

And after seeing the same gap between what should happen and what actually happens enough times, building the solution stops feeling like a choice.

It becomes inevitable.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

The future of healthcare is not about replacing doctors. It’s about removing the friction, inefficiency, and information asymmetry that exists between patients and the healthcare system itself.

Neil, who leads investments at Redesign Health, believes we are entering a new era where intelligence becomes abundant - where AI compresses specialization and democratizes access to medical knowledge.

“The unlock here is AI,” he told me.

What struck me most was how quickly the conversation moved beyond software.

Today, many people debate whether SaaS is dying. Neil’s view was more nuanced: SaaS in healthcare isn’t disappearing - it’s evolving. Interfaces are changing. Chat is becoming the natural way humans interact with software and data. But beneath that shift is a much bigger battle happening between systems of record and AI-native workflows.

History suggests incumbents eventually absorb feature-level innovation.

Neil used Epic as the perfect example. Over the years, startups built patient apps, scheduling layers, and workflow tools on top of Epic’s infrastructure. Most eventually disappeared once Epic replicated those features internally.

That creates an important lesson for founders today: if your company only improves the surface layer, the platform eventually catches up.

The enduring companies will be the ones solving infrastructure-level problems - reducing costs, increasing access, and fundamentally redesigning how healthcare operates.

And that’s where Neil sees AI creating profound impact.

Not just in helping clinicians, but in empowering patients and families with understanding. The ability to ask questions, interpret information, receive guidance, and bridge the knowledge gap between medical expertise and ordinary people may fundamentally reshape healthcare outcomes.

But Neil believes the biggest transformation is still ahead.

“A hospital is not where you heal,” he said. “A hospital is where you get treated. You heal somewhere else.”

That single statement reframes the future entirely.

The next generation of healthcare systems may become smaller physically, but infinitely more intelligent digitally - powered by AI agents, preventative diagnostics, personalized therapies, and clinicians augmented by machine intelligence.

And perhaps that’s the deeper lesson underneath all of this.

The most important technology companies of the next decade won’t simply build better software.

They’ll build systems that reduce human suffering at scale.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

When I sat down with Mike Kropp, former Microsoft and AWS leader, and now founder of Iridius - one idea kept resurfacing throughout our conversation: product-market fit is not something you discover once. It’s something you engineer through constant feedback loops.

Mike learned this at Microsoft while building the Patterns & Practices community, where his team worked directly with over 17,000 developers and architects in real time. They didn’t just ask customers for opinions. They shipped code weekly, exposed early SDKs, invited criticism, and let the community shape the product as it evolved.

“We called it customer-connected development,” Mike told me. “The better scale you have in getting requirements, the better product-market fit that you have.”

That line stuck with me because it reframes what great product teams actually do. They don’t build in isolation and hope customers validate later. They build with customers from the beginning.

And importantly, this only works if the company itself is built to move quickly.

Mike explained that one of the key enablers at Microsoft was adopting agile development early. You need the ability to iterate fast enough that customer feedback actually changes the product. Otherwise, “listening to customers” becomes little more than performative research.

What fascinated me was how much of this philosophy still shapes Mike’s thinking today at Iridius, where he’s building AI infrastructure for highly regulated industries.

The timing couldn’t be more relevant.

Right now, enterprises are rushing toward AI adoption, but many are stuck between experimentation and production. Mike believes the issue isn’t excitement - it’s trust.

Highly regulated organizations don’t just need AI that works. They need AI that is compliant, deterministic, explainable, and audit-ready.

“Their projects get all the way to MVP,” he explained, “but they feel it’s too risky to move them into production.”

That’s the gap Iridius is trying to solve.

The company is building what Mike describes as a compliance-by-design architecture for enterprise AI - turning regulations, policies, and standard operating procedures into executable logic that AI agents can understand and follow.

What struck me most wasn’t just the technology. It was how clearly Mike understood the emotional reality inside large organizations.

When auditors arrive, teams scramble for months trying to reconstruct evidence trails manually. Compliance departments are often viewed internally as bottlenecks slowing innovation down. Meanwhile, executives are under immense pressure to adopt AI without creating catastrophic risk.

The result is a market full of AI ambition but very little operational confidence.

And that’s where founder discipline becomes critical.

One of the most important parts of our conversation centered around restraint. Mike referenced Bob Muglia - another Microsoft legend I previously interviewed and highlighted something many founders struggle with: saying no to the wrong customers.

At Snowflake, Bob deliberately avoided certain enterprise customers early because he knew the product wasn’t ready yet. That level of discipline is incredibly difficult in startup environments where momentum feels existential.

But Mike believes long-term success depends on clarity.

“You need absolute clarity on who your customer is,” he said. “Know their pains, their hopes, their desires and obsess about making sure your product fits them.”

That discipline extends internally too.

Mike shared something I’ve increasingly noticed while scaling my own businesses: founders set the pace of the company. Not through motivational speeches, but through behavior.

In startups, there’s nowhere to hide. Everyone works. Everyone executes. And people either rise to that environment or self-select out.

As Mike put it:

“A’s hire A’s. B’s hire C’s and D’s.”

The best founders aren’t trying to be the smartest person in the room. They’re building teams capable of changing industries.

Toward the end of our conversation, we discussed AI hype. Mike was blunt: most AI startups won’t survive.

The reason? Many are building features that can easily be replicated as models improve. The companies that endure will be the ones building deep infrastructure, differentiated platforms, and solving mission-critical problems customers genuinely care about.

That may be the real lesson underneath everything we discussed.

The strongest companies aren’t built by chasing hype cycles.

They’re built by obsessing over customer truth long enough to create something that actually matters.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

This week’s PMF Playbook comes from my episode with Jim Harding. Jim has lived through multiple computing inflection points: the early personal computer era, the operating system wars, the rise of internet search, early AI, and now the shift toward agents and autonomy.

What made this conversation so valuable was the way Jim connected history, technical architecture, and nature into one bigger idea: the next wave is not just AI. It is autonomy.

Let me walk you through what stood out.

Inflection points punish imitation

Jim’s first point was blunt: most companies miss inflection points because they chase what has already happened.

You see this today with large language models and agents. Once a category gets hot, hundreds or thousands of companies rush toward the same surface area. But if they don’t bring anything truly differentiated to the market, they get absorbed by the hyperscalers or disappear.

That is the uncomfortable PMF lesson: being in the right market is not enough. You still need a unique wedge.

In every platform shift, the first wave is excitement. The second wave is imitation. The third wave is consolidation. The companies that survive are the ones with something the platform cannot easily commoditize.

The lesson from Intel: even the authors can miss the next wave

Jim brought up Andy Grove and Intel, which is fitting because Only the Paranoid Survive is fundamentally a book about strategic inflection points.

Intel helped define the microprocessor era. They saw one of the most important computing shifts in history before almost anyone else. But even companies that author one inflection point can miss the next.

Jim’s point was that Intel saw the CPU world clearly, but missed other waves: GPUs, mobile, and ultimately AI.

That is a brutal reminder for founders. Past clarity does not guarantee future clarity. In fact, success can make it harder to see the next shift because your current business model teaches you what to pay attention to.

PMF creates signals, but it can also create blindness. The product that made you great can become the lens that prevents you from seeing what comes next.

The people who survive inflection points have guts

When I asked Jim what separates those who survive inflection points from those who miss them, he didn’t give a process answer.

He said it comes down to innate drive and guts.

That matters. There is always a point in a major shift where the evidence is incomplete. The market has not fully moved. The incumbents look strong. The new behavior seems strange. The economics are unclear.

At that moment, data alone will not save you. You need judgment. You need risk tolerance. You need the willingness to move before consensus has formed.

The PMF lesson here is that inflection points are not obvious in real time. They only look obvious in hindsight. The people who win are often the ones willing to look unreasonable before the market catches up.

From thousands to millions: the PC inflection point

Jim’s early story around Seattle Computer Products, QDOS, Microsoft, and IBM was fascinating because it showed how messy inflection points actually are.

The personal computer wave was not one clean breakthrough. It was a collision of hardware, operating systems, software, and distribution.

The IBM PC mattered. Microsoft mattered. DOS mattered. But Jim also pointed to Lotus 1-2-3 as one of the real accelerants. People did not just buy computers because computers were interesting. They bought them because a spreadsheet made the machine useful.

That is such an important PMF point.

Platform shifts need killer use cases. The infrastructure can exist, but adoption accelerates when users feel a specific productivity gain that justifies the cost and behavior change.

In the PC era, the spreadsheet helped pull the market forward. In every platform shift, founders should ask: what is the Lotus 1-2-3 moment for this category?

AI is not the final shift. Autonomy is.

The most interesting part of the conversation was Jim’s distinction between AI and autonomy.

AI has been around for decades. Jim worked on AI in the 1990s. What is different now is scale: language models have compressed vast amounts of digital knowledge into an interface that feels instantly useful.

But Jim’s argument is that this is still not the end state. Today’s AI is incredibly powerful, but much of it still behaves like a calculator: a generative, reasoning, content-producing calculator.

The deeper shift is autonomy.

That means moving from humans using computers to agents using computers, agents talking to agents, robots talking to agents, applications talking to agents, and intelligence moving to wherever work needs to happen.

In Jim’s words, we are moving toward a world of distributed intelligence.

The PMF implication is massive. The next generation of products will not just help users do work. They will coordinate work between autonomous actors.

That changes the product question from “does this tool help a user?” to “can this system safely discover, delegate, execute, observe, and collaborate across a network of actors?”

The next network: from the internet to the Paranet

Jim described his idea of the Paranet: a new layer above the internet where autonomous actors can discover each other, declare skills, request skills, and collaborate safely.

The analogy he gave was powerful. The web needed HTTP and HTML to make distributed information usable. The autonomous era may need its own protocol and language to make distributed intelligence usable.

That is the kind of thinking founders should pay attention to. Every major platform shift eventually needs standards, protocols, trust models, and developer primitives.

The winners are not always the first apps. Often, the biggest winners are the companies that build the enabling layer beneath the apps.

If the internet organized information, the next wave may organize autonomous action.

Nature already understands autonomy

The final part of the conversation took an unexpected turn: Jim’s ranch.

He runs a cutting-edge technology company while surrounded by bison, yak, horses, donkeys, sheep, goats, pigs, birds, fish, and bees. That is not a gimmick. For Jim, nature is a design system.

His example of bees was especially memorable. A hive is full of autonomous actors. They coordinate through signals. They maintain temperature. They defend against threats. They collaborate with flowers through a form of biological protocol.

Jim’s point is that nature already solved many of the problems we are now trying to solve in software: coordination, trust, delegation, signaling, defense, and resilience.

That is a beautiful product lesson. The best systems often mirror the real world. They do not fight complexity by pretending it does not exist. They create simple local rules that allow complex coordination to emerge.

Closing thought

If I compress the entire episode into one sentence, it’s this:

PMF survives inflection points when founders stop chasing the obvious wave, build something uniquely differentiated, and understand that the next platform shift is not just AI - it is autonomous coordination at scale.

That is the shift Jim is building toward.

And if he is right, we are still early.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

This week’s PMF Playbook comes from my episode with Monzy Merza, Founder and CEO of Crogl.

Monzy is one of those founders who didn’t discover a problem from the outside. He lived it. He spent more than 25 years in cybersecurity, including time at Splunk, Databricks, and inside the cybersecurity team at HSBC, before starting Crogl.

What made the conversation valuable wasn’t just the product. It was the way Monzy thinks about founder-market fit, customer listening, and the difference between hearing a problem and truly understanding the physics of that problem.

Let me walk you through what stood out.

Founder-market fit: living the problem before building the solution

A lot of founders today build products in industries they’ve never worked in.

Sometimes that works. But in complex markets like cybersecurity, surface-level understanding is dangerous. The easy assumptions are usually wrong.

Monzy’s journey to Crogl started with a pattern he kept hearing from customers at Splunk and Databricks: security teams were never going to put all their data in one place.

That sounds simple. But it challenged years of conventional wisdom.

The standard pitch in data and security was: centralize your data, put it in one lake, and then analytics will solve the problem. But customers were saying something different. Their data was already spread across S3, Databricks, Splunk, log analytics platforms, endpoint tools, cloud services, and countless other systems.

And they were not going to move it all.

The PMF lesson is this: sometimes the market tells you the answer repeatedly, but you only hear it once you stop trying to force it into your existing worldview.

Listening to customers is not the same as hearing customers

One of the strongest parts of the conversation was Monzy’s definition of listening.

Most people say “listen to the customer.” But what does that actually mean?

Monzy described it as understanding the physics of the customer’s work. Not just the words they use. Not just the complaint. The actual day-to-day motion of the job.

If a customer says, “We want more value from our data,” the lazy interpretation is: great, here’s a better data platform.

The deeper interpretation is: what does value mean? Why are you not getting it today? What outcome would prove that value has been created? What work has to happen for that outcome to exist?

That is where the real problem lives.

In cybersecurity, the obvious phrase everyone uses is alert fatigue. Too many alerts, not enough analysts, too much noise.

But when Monzy dug deeper, he found the real problems underneath:

Analysts had domain knowledge gaps. They had tool competency gaps. And teams had collaboration gaps, where one analyst’s work did not easily compound into another analyst’s work.

That is a very different problem than “too many alerts.”

And that distinction matters.

If you solve the tagline, you build another feature. If you solve the physics, you build a company.

The aha moment: “we are never putting all our data in one place”

The moment that led to Crogl happened during a Databricks customer call.

The customer said they were never going to put all their data in one place.

Monzy had heard versions of that before, but this time it landed differently. It triggered a realization: if security data is permanently distributed, then the old model of centralizing everything before investigation is fundamentally broken.

That insight did not immediately become a pitch deck.

Instead, Monzy spent weeks challenging himself. Has this already been solved? Why had federated search not fixed it? Why had decades of tooling still left security analysts overwhelmed? What would a person on the keyboard actually need to do the job properly?

That discipline matters.

Aha moments are rarely enough. The founder still has to interrogate the insight until it either breaks or becomes stronger.

Why Monzy went back inside the problem

Before founding Crogl, Monzy did something most founders would never do.

He went back into the operator seat.

He joined the cybersecurity team at HSBC because he wanted to experience the problem directly in one of the most complex environments possible.

That decision says a lot about how he thinks.

HSBC had the resources. It had the talent. It had the tools. If even an organization like that still struggled with alert investigation, data sprawl, and analyst constraints, then the problem was not simply budget or hiring.

It was structural.

This is an important founder lesson: when you remove the obvious excuses and the problem still exists, you may have found something worth building.

Crogl: what the company actually does

Crogl works on alerts.

That was Monzy’s simplest definition.

In a security operations center, analysts can receive hundreds or thousands of alerts. Most are not meaningful. But one missed alert can become the root of a breach, a regulatory issue, a financial loss, or a CISO losing their job.

The conventional answer has been to filter alerts down.

Monzy calls that the diminishing view of the world: the idea that everything should somehow get smaller. Fewer alerts, less noise, fewer things to inspect.

Crogl takes the opposite view.

The world gets bigger. Data grows. Computing grows. Attack surfaces grow. Alerts grow.

So instead of assuming fewer alerts, Crogl investigates every alert with depth. It connects across the tools and data an organization already has, helps analysts understand whether there is evidence of threat, and documents the work automatically.

The analyst does not have to remember every schema, every query language, every tool convention, or every organizational nuance.

Crogl brings that context forward.

The PMF lesson here is clear: a great product does not always remove work. Sometimes it removes the wrong work so humans can focus on the judgment they were hired for.

The real customer: the practitioner who carries the pain

Crogl sells to security leaders, but it is built for practitioners.

That distinction matters.

The buyer might be a VP of security engineering, a security leader, or in some cases the CISO. But the user is the analyst, the threat hunter, the incident responder - the person actually doing the work.

Monzy’s pride in Crogl is tied directly to that community.

In ten years, he wants Crogl to have made analysts look like the heroes they already are. He wants their work to be captured, reused, improved, and recognized. He wants the domain knowledge gap, tool competency gap, and collaboration gap to be materially smaller.

That is a powerful founder-market fit signal.

The company is not just serving a budget line. It is serving a community.

The PMF lesson: boring problems can be the most valuable

One of Monzy’s strongest points was that many of the easy problems have already been solved.

What remains are often the boring ones.

The messy ones. The operational ones. The problems buried inside workflows that outsiders underestimate because they look unglamorous from a distance.

But those are often the highest-value problems.

In security operations, the work is not sexy. It is repetitive, detailed, high-stakes, and unforgiving. But if you can solve it, or even materially improve it, the value is enormous.

This is where a lot of founders get founder-market fit wrong.

It is not just “I know the space.” It is not just “I worked in this industry.” It is the willingness to get dirty, respect the complexity, and serve the people doing the work.

AI in security: not replacing people, but multiplying them

Monzy was clear on one thing: broad claims about replacing humans usually reveal shallow understanding.

In security, the work is too nuanced to reduce to a slogan.

Crogl is not valuable because it says, “you no longer need security analysts.” It is valuable because it helps analysts operate at a much higher level.

It investigates alerts. It documents work. It learns from analyst input. It helps analysts avoid being blocked by tool knowledge or data sprawl.

That is a much more realistic AI wedge.

Not replacement.

Amplification.

And in enterprise markets, amplification often wins because it respects how work actually happens.

The deeper takeaway: PMF starts with service

The theme I kept coming back to in this episode was service.

Monzy did not describe Crogl as a clever AI product. He described it as a way to serve a community he understands deeply.

That changes how you build.

You ask better questions. You avoid arrogant assumptions. You do not dismiss complexity. You do not build a magic wand and then go looking for a market.

You start with the people doing the work.

Then you build around their reality.

Closing thought

If I compress the entire episode into one sentence, it’s this:

PMF starts when a founder understands the physics of a customer’s work deeply enough to solve the problem beneath the obvious problem.

Crogl is not just solving alert fatigue.

It is solving the knowledge, tooling, and collaboration gaps that make security operations so difficult in the first place.

That is the kind of insight that only comes from listening properly, living the problem, and caring enough about the practitioner to build something that actually helps.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/

This week’s PMF Playbook comes from my episode with Evan Silberhorn. Evan has lived across multiple company-building worlds: operator, founder, consultant, BCG Digital Ventures, and now private equity portfolio operations.

What made this conversation valuable was the contrast between venture capital and private equity. Not as abstract finance categories, but as two very different operating systems for value creation.

Let me walk you through what stood out.

VC versus PE: growth versus durability

Evan’s simplest distinction was also the clearest.

Venture capital is about growth. You invest early, often before product-market fit is fully proven, and you put capital behind founders who might be able to capture a massive market. The goal is speed, iteration, market capture, and scale.

Private equity is different. It is not just asking, “Can this company grow?” It is asking, “Can this company grow while improving the bottom line?”

That’s where EBITDA becomes the language of the room. In PE, value creation is not just top-line expansion. It is top-line growth plus cost discipline, process improvement, operational maturity, and margin expansion.

The PMF lesson here is important: venture is often about finding and scaling PMF; private equity is about making PMF more durable, measurable, and profitable.

The PE lens: no BS, just value creation

One phrase from Evan captured the private equity mindset perfectly: there is no BS.

When a PE firm buys or invests in a company, everything starts with a value creation plan. That plan becomes the operating map for the hold period. Product roadmap, sales strategy, cost structure, AI initiatives, hiring, organizational design - everything needs to connect back to how value will be created.

That’s a very different rhythm from the early-stage startup world, where ambiguity is often part of the journey.

In PE, ambiguity has a cost. You are operating against a clock. You need to show progress quarter after quarter, and the company has to become more valuable within a defined time window.

The PMF lesson: once a business reaches scale, storytelling alone is not enough. The story has to become an operating plan.

The real PE clock is shorter than founders think

One of the most useful parts of the conversation was Evan’s breakdown of the private equity timeline.

People often hear “five-year hold” and assume there are five full years to create value. But Evan explained that the real window is much shorter.

The first six to eight months are often spent aligning on the value creation plan, understanding the company deeply, improving visibility, and setting up the operating system. Then, by year three and a half or four, the firm is already thinking about exit positioning.

That means the true value creation window may only be from month eight to around year three and a half.

That changes the whole game.

You don’t have unlimited time to modernize the stack, fix the operating model, rebuild the product motion, integrate acquisitions, and improve growth. You have to prioritize ruthlessly.

The PMF lesson: time is not just runway. Time is strategic leverage. If you waste the first year, you may have already lost the hold.

Why PE cares so much about operations

Evan made the point that many PE-backed companies are not broken. They are often proven companies that have grown through sales motion, founder energy, or acquisition.

But they may be operationally immature.

They may have multiple product lines that do not fully connect. They may have different systems stitched together from acquisitions. They may have a sales-led culture that never fully evolved into a product-led or customer-led operating model.

That is where PE sees opportunity.

The value comes from bringing maturity: better reporting, better processes, clearer product strategy, stronger go-to-market alignment, cleaner cost structure, and more disciplined execution.

The PMF lesson: growth creates complexity. If you don’t professionalize the operating system, the complexity eventually eats the growth.

AI in PE: efficiency first, transformation second

Evan’s view on AI was pragmatic.

In the venture world, AI today can feel like a land grab. Capital is being poured into infrastructure, talent, and capability-building. Companies are paying extraordinary compensation because they are terrified of falling behind.

But in private equity, the AI conversation is becoming much more focused on efficiency.

Where can AI reduce cost? Where can it improve workflows? Where can it help the company do more without endlessly adding headcount? Where can it drive measurable business value?

That’s a different adoption pattern from the hype cycle.

The PMF lesson: AI will not be judged forever on pilots and demos. Eventually, it will be judged on business outcomes.

Founder autonomy changes after PE

One of the sharper points in the episode was what happens when a founder takes private equity money.

Evan was direct: the PE firm becomes your boss.

That does not mean the founder loses all control overnight. But it does mean the founder now reports into a very different accountability structure. Quarterly performance matters. EBITDA matters. The value creation plan matters.

If the founder can scale with the company, great. If not, PE firms may decide that the next phase requires different leadership.

That can be difficult because founder-led companies often have deep emotional and cultural attachment to the founder. Removing a founder can disrupt the organization. But if the company is missing targets and the next stage requires a different operating muscle, the conversation becomes unavoidable.

The PMF lesson: the person who creates PMF is not always the person who scales PMF through the next phase.

East Coast versus West Coast capital

I loved Evan’s framing of East Coast versus West Coast investing.

Silicon Valley is more comfortable taking big swings on founders, ideas, and category-defining outcomes. It is more willing to believe in a future that does not yet exist.

The East Coast mindset, especially in private equity, is more measured. It is more numbers-oriented, more durability-focused, and more anchored in proven business models.

Neither is right or wrong. They are simply different forms of capital with different expectations.

Venture asks: how big can this become?

Private equity asks: how durable, profitable, and operationally excellent can this become?

The PMF lesson: the type of capital you take shapes the company you become.

The support you get: networks versus playbooks

Another useful contrast was the support founders receive.

From venture capital, founders often get access to networks: other founders, early-stage operators, talent, customers, and advisors who can help them find PMF and scale quickly.

From private equity, companies get playbooks: former operators, proven processes, operational benchmarks, cost discipline, reporting systems, and repeatable methods for improving performance.

VC helps you move faster into uncertainty.

PE helps you operate better inside a proven model.

The PMF lesson: founders should not just ask, “Who will give me money?” They should ask, “What kind of operating system does this capital bring with it?”

Closing thought

If I compress the entire episode into one sentence, it’s this:

PMF may begin with growth, but long-term value comes from turning that growth into a durable, disciplined, measurable operating system.

That is the bridge between venture and private equity. Venture funds the possibility. Private equity tests the machinery.

Until next time,

Firas Sozan
Your Cloud, Data & AI Search & Venture Partner

Find me on Linkedin: https://www.linkedin.com/in/firassozan/
Personal website: https://firassozan.com/
Company website: https://www.harrisonclarke.com/
Venture capital fund: https://harrisonclarkeventures.com/
‘Inside the Silicon Mind’ podcast: https://insidethesiliconmind.com/