Why Entro Security Turns Away Customers: The Hidden Cost of Scattered Use Cases

There’s a specific moment in every startup’s growth when saying yes to revenue starts costing more than saying no. Most founders miss this inflection point entirely. They celebrate each new customer, regardless of how that customer uses the product, because revenue is the universal scorecard. More customers equals more validation equals more fundability.

In a recent episode of Category Visionaries, Itzik Alvas, CEO and Co-Founder of Entro Security, shared a perspective that challenges this orthodoxy: “All of them should use it in the same way, by the way, like if you’re, if each customer is using a different portion of the product, that’s not, not as good as it can be.”

The statement sounds almost innocuous—”not as good as it can be”—but the implication is severe. If your customers use different parts of your product, you don’t have product-market fit. You have something more dangerous: the appearance of PMF masking a fundamentally unscalable business.

The Services Business Disguised as Software

Most B2B founders understand the difference between services and software intellectually. Services scale linearly with headcount. Software scales exponentially with distribution. Services require customization for each client. Software runs the same code for everyone.

But the line between them blurs in practice. You build a platform with multiple modules. Customer A uses modules 1, 2, and 3. Customer B uses modules 3, 4, and 5. Customer C uses modules 2, 5, and 6. Each customer pays, each finds value, each renews. By traditional metrics, you have PMF.

Except you don’t have a software business. You have a services business with a software interface.

Consider what happens as you scale. Your sales team can’t develop a standard pitch because each customer buys for different reasons. Your marketing can’t target a specific persona because you’re serving multiple personas with different jobs to be done. Your onboarding team needs different workflows for each customer type. Your customer success team can’t develop playbooks because success looks different for each segment. Your product team can’t prioritize the roadmap because you’re serving competing use cases.

The economics break down too. Your customer acquisition cost stays high because each sale requires custom education. Your implementation costs stay high because each customer configures differently. Your support costs stay high because each customer encounters unique issues. You’re hiring linearly to support logarithmic growth—the exact opposite of software economics.

Why Founders Accept Scattered Use Cases

Understanding why this happens requires examining the incentives founders face between seed and Series A. Itzik’s framework makes the problem clear: “You need to mainly sell an idea, but that should be somewhat of a calculated risk in terms of you’ve done your market research, you interviewed your customers, you are getting to repetitive circle with your market around the questions that you’re asking them and the answers you are getting from them.”

At seed stage, the goal is validating that the problem exists and that someone will pay to solve it. You’re not trying to prove repeatability yet—you’re trying to prove viability. So when your first customer wants features A, B, and C, you build them. When your second customer wants features D, E, and F, you build those too. Each customer validates that the problem space is real and that people will pay for solutions.

Then you try to raise Series A, and the requirements shift. “You should have customers, you should have reached the $1 million mark. Your customers should use your product, love your product,” Itzik explains. Founders focus on the revenue milestone and the satisfaction score, but they miss the crucial qualifier: “All of them should use it in the same way.”

By the time you notice the problem, you’ve already signed contracts, made promises, and built features that pull you in multiple directions. Saying no to scattered use cases requires walking away from revenue you already have or turning down deals that would help you hit your numbers. The short-term incentives all point toward acceptance.

The Pattern Recognition Test

The solution starts with recognizing what product-market fit actually looks like. It’s not just that customers find value—it’s that they find value in the same way, from the same features, following the same general workflow.

When Entro was building toward Series A, this principle shaped their customer acquisition strategy. They weren’t just looking for companies with security problems—they were looking for companies experiencing the specific problem of non-human identity management in ways that fit Entro’s solution.

“Developers, DevOps users are the ones who are creating permissioning. Them, using them are without security oversight and they scatter them around so they, you know, committing them into code, they are sending them over slack and no one is actually managing their lifecycle, no one is deleting them, no one is making sure their permissions are right side,” Itzik describes.

Notice the specificity. This isn’t a broad description of “security challenges” or “identity management problems.” It’s a precise description of a workflow pattern: developers create credentials, scatter them without oversight, and nobody manages their lifecycle. Companies that experience this exact pattern are ideal customers. Companies that experience adjacent but different patterns are not—even if they’d pay.

The Discipline of Saying No

Implementing this discipline requires a framework for evaluating opportunities. Here’s what it looks like in practice:

After your first few customers, analyze their usage data. Which features do they all use? Which workflows do they all follow? Where is there convergence?

Then define your Ideal Customer Profile not just by firmographics (company size, industry, tech stack) but by workflow patterns. Your ICP becomes: “Companies where developers create and scatter non-human identities without security oversight,” not just “Companies that need security tools.”

When a new opportunity emerges, the first question isn’t “will they pay?” but “do they fit the pattern?” If a prospect needs something adjacent to your core use case, the right answer is usually no—even if they’re offering significant revenue.

This feels counterintuitive when you’re trying to reach growth milestones. Saying no to a $200k deal because the customer would use your product differently than your other customers seems like leaving money on the table. But what you’re actually doing is preserving your ability to scale.

What You’re Actually Buying With Focus

When you turn away customers who don’t fit the pattern, you’re buying several things:

First, scalability in sales. Your team can develop and refine a standard pitch. They can target similar prospects with similar messaging. They can learn what objections matter and which are smokescreens. Your win rate increases because you’re getting better at selling the same thing rather than learning to sell different things.

Second, scalability in onboarding. You can build a standardized process that works for everyone because everyone is trying to accomplish the same thing. Time-to-value decreases. Implementation costs decrease. Customer success can develop playbooks instead of improvising for each customer.

Third, scalability in product development. Your roadmap becomes a prioritization exercise within one use case rather than a negotiation between competing use cases. You can go deep on the core workflow instead of spreading features across multiple workflows. Your product gets better at one thing instead of mediocre at many things.

Fourth, scalability in marketing. You can create content for a specific persona solving a specific problem. Your messaging resonates because it speaks to a consistent experience. Your brand becomes associated with solving one problem well instead of solving many problems adequately.

The Hidden Cost Becomes Visible

The cost of scattered use cases isn’t immediately visible because the second-order effects take time to manifest. Your first year, having diverse customers seems like validation. Your second year, it feels like optionality—multiple potential directions for growth. By year three, it’s fragmentation—you’re supporting multiple products within one codebase, your team is pulled in competing directions, and your GTM motion lacks focus.

“If you’re, if each customer is using a different portion of the product, that’s not, not as good as it can be,” Itzik observes. The understatement masks the severity. It’s not just “not as good”—it’s a ticking time bomb that explodes at scale.

Series A investors have seen this pattern enough times to recognize it immediately. When they dig into your usage data and discover scattered patterns, they know what it means: you haven’t found PMF yet, regardless of what your revenue suggests. You’ve found willingness to pay, which is different from finding a repeatable, scalable motion.

The Path Forward

If you’re between seed and Series A and recognizing this pattern in your own business, the fix isn’t easy but it is straightforward. Analyze your current customer base and identify the convergence—where do usage patterns overlap? That overlap is your real product. Everything else is distraction.

Then make a hard decision: are you willing to focus exclusively on that convergence, even if it means walking away from customers or revenue that don’t fit? If yes, you’re building a scalable software business. If no, you’re building something that might be profitable but won’t be venture-scale.

Itzik’s insight reveals that product-market fit isn’t just about finding customers who’ll pay. It’s about finding customers who’ll pay for the same thing, in the same way, for the same reasons. That’s the difference between revenue and repeatability. And repeatability is what Series A investors are actually buying.