In 2009, Mark Rostick and a colleague presented the idea of enterprise cloud to a group of senior IT leaders. He remembers the room rolling its eyes. They had seen cloud computing work for consumers, but using it inside a large company seemed like a different proposition.
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?