I've been struggling with one question for many months: why is it that we have a unique solution in the market that solves the problem much better and much faster, taking implementations from years to weeks, and yet we struggle to sell it?
For a long time I blamed marketing.
It is well known that a lot of worse products get distribution because they do marketing well. I trusted it had to be this. Microsoft Teams outgrew Slack while lacking many of the features and quality Slack had for the subset of the market they competed for.
But eventually I realized distribution wasn't the root problem.
We were competing in a category that was already well established: Privileged Access Management.
That's a hard sell. Two or three incumbents have most of the market. Companies have spent years rolling these products out. They have dedicated teams operating them.
Asking a large company to drop all of that for a startup is nearly impossible, even if our product doesn't require a dedicated team to operate and doesn't take a year to roll out.
So we did what seemed logical.
We built the same basic capabilities, but better. We made them easier to deploy. We reduced the cost of switching from years to weeks.
But that still wasn't enough.
There are 20+ vendors competing in the space, so conversations naturally became about feature parity and price.
Meanwhile, underneath all those commodity access-control features (authentication, authorization, audit, just-in-time access) our four truly unique features remained buried.
That was the real problem.
A customer first had to understand our version of all the things they already had before they could get to the things only we could do.
And because of that, our time-to-value took weeks.
We were hiding the best part of the product.
Then I started looking at some of the most successful infrastructure products of recent years.
Many of them didn't start as complete enterprise solutions. They started as simple tools that solved one painful problem extremely well and were easy to adopt.
Fast time-to-value drove adoption of the small tool. That adoption then created the opportunity to build and sell enterprise capabilities around it.
HashiCorp repeated this playbook multiple times with Terraform, Vault, Vagrant, Packer, Consul and others.
The wedge came first.
So I decided to make the move that had scared me for a long time: delete 80% of our product.
We've been building this for years.
People always connected our solution to access control, so removing the basic access-control features meant deliberately walking away from those conversations. Our entire sales motion was built around that category, and it had been growing for many months.
But we were running out of time.
Our unique features were starting to get copied. We were spending too much engineering time building undifferentiated features to maintain parity with incumbents while the features that actually made us different were buried underneath them.
At the pace we were going, incumbents could copy our differentiation before we had the chance to build a meaningful company around it.
So we changed the product.
Hoop is now only the differentiated part.
Runtime controls: analyze what is happening in real time, mask sensitive data without requiring schemas, and put a human in the loop when an action needs approval.
Instead of replacing a company's access-control system, Hoop sits alongside the tools they already use.
Before, the path looked like this:
Adopt Hoop for access → configure identity and authorization → configure approvals and audit → migrate workflows → eventually reach the unique controls.
Now:
Put Hoop in the path → keep your existing identity, permissions and workflows → immediately use the controls that didn't exist before.
The team didn't take the decision well at first.
It meant a lot of software they had spent months building was no longer part of the product. More importantly, I was asking them to throw away things we had previously considered strategically important because our understanding of the market had changed.
But after going deep into why this would unbury our differentiated features and get users to the a-ha moment much faster, they took on the challenge.
A week later, our docs and website already pointed to the pilot implementation we had tested in the weeks before making the decision.
And almost immediately, our customer conversations changed.
Before, we could spend 25 minutes of a call explaining 15 features and why our version of those features was better than a competitor's.
Now customers come into calls already understanding where we fit in their architecture.
They understand we're not replacing their existing tools.
They understand the value of the unique features.
And instead of waiting weeks to reach them, they can test those features in minutes.
The biggest surprise came after that.
When you think about enterprise software, you usually think about big, complex solutions that address every edge case and have hundreds of features.
By making the product dramatically smaller, I thought we were ruling ourselves out of those enterprise conversations.
The opposite happened.
We've seen more traction in some of our largest enterprise deals, including companies with 10,000+ employees.
The reason is simple: the risk of adoption is much lower now.
We're a small component that doesn't require them to replace their existing workflows or architecture. They can deploy Hoop to an isolated part of production in a few weeks, run it in fail-open mode, see what it would do before enforcing anything, and gradually expand from there.
Compare that with an all-or-nothing platform migration.
A large company might have to change the workflows of thousands of people and modify thousands of infrastructure resources before getting meaningful value. Projects like that can take years.
With Hoop, they can deploy a set of sidecars to a small production scope in four weeks, prove the value, and then gradually expand over many months.
Making the product smaller actually made it easier for large companies to adopt.
And there's another consequence that might be even more important for us.
Before, a large percentage of our engineering capacity went into building undifferentiated features so we could reach parity with established vendors and stay in the evaluation.
Now almost everything we build can go toward increasing the distance between us and everyone else.
Instead of spending our time recreating features the market already has, we can spend it making the things only we do significantly better.
That gives us a much better chance of staying ahead while incumbents try to copy us.
We're only three weeks into this.
That's nowhere near enough time to know if the strategy ultimately works.
But our existing customer conversations have become dramatically simpler. Customers reach the a-ha moment in minutes instead of weeks. Enterprise deployments feel less risky, not more. And we're getting new inbound requests from people who already have a clear picture of where the product fits.
I've struggled with this problem for many months.
The lesson I'm taking from it so far is that having differentiated technology isn't enough.
If customers need to adopt all the undifferentiated parts of your product before they can experience what makes it special, your differentiation is effectively hidden.
Sometimes making the product much smaller is what finally lets people see it.