Jason Sherman

In this episode of Strap On Your Boots, I explore one of the biggest advantages startups have over much larger competitors: speed. Drawing from my experience building companies and the evolution of Vengo AI from a consumer product to B2B SaaS and eventually enterprise, I explain how small teams can listen to customers, test ideas, pivot, and respond to the market incredibly quickly. Large companies may have more money, people, and resources, but all of that size comes with organizational weight. Sometimes the startup that can adapt in days has an advantage that money simply can’t buy.

Listen to the Podcast:

Get ready to strap on your boots. I’m your host, Jason Sherman. One of the things I’ve always enjoyed about running a startup is how quickly you can move when you have a small team. I’ve experienced this across a lot of different companies over the years, whether I was building an e-commerce business, a video platform, a mobile app, or more recently an AI company. There are plenty of disadvantages to being small, especially when you’re competing against companies with more money, larger sales teams, and resources you simply don’t have, but I’ve come to appreciate that being small gives you one advantage that’s incredibly difficult for a large organization to replicate. You can change direction very quickly.

I learned this early on through lean startup methodology, especially the idea of building a minimum viable product. An MVP isn’t supposed to be the perfect version of your company. You’re trying to build enough of the idea to put it in front of real people and find out whether your assumptions were correct. I always liked that approach because I’m a builder by nature. I’d rather create something, let people use it, watch what happens, and improve it based on actual behavior than spend a year sitting in meetings trying to predict what customers might eventually want.

I’ve done that so many times that it has become part of how I naturally approach a company. I’ll have an idea, build the earliest version I can reasonably test, and start putting it in front of people. Sometimes they respond exactly the way I expected. More often, they surprise me. They’ll ignore a feature I thought was going to be incredibly important and become fascinated by something I considered secondary. They’ll start using the platform for a purpose I hadn’t really anticipated, or a completely different type of customer will show up and see value in it.

I’ve learned to pay very close attention when that happens because the market is giving you information you couldn’t have gotten from a business plan.

A recent example for me is Vengo AI. When we originally started developing it several years ago, we were thinking primarily about consumers. We saw an opportunity to give people access to AI personalities and experts they could interact with, and the initial version of the platform reflected that idea. We built it, released it, got people using it, and started watching how they responded.

Over time, something interesting became increasingly obvious. Business owners were much more interested in what we had built than we initially expected. They weren’t looking at the technology simply as something entertaining to interact with. They were asking how they could use it for their own companies. They wanted AI agents that understood their businesses, could interact with their customers, answer questions, capture leads, and become part of their existing operations.

Once we saw that happening consistently, we shifted toward B2B SaaS.

That wasn’t the direction we had originally planned, but I didn’t feel any loyalty to the original business model simply because we’d already spent time building it. The technology still worked. The underlying idea was still valuable. We were learning that the people willing to pay for that value were different from the audience we had initially imagined.

Then the market gave us another signal.

As we continued selling to businesses, we started having conversations with much larger organizations. Universities became interested. Enterprise companies started looking at the platform. The problems they wanted us to solve were more substantial, and they had the budgets to build the technology into their operations in ways that smaller businesses often couldn’t.

So we adjusted again.

That evolution took Vengo from a consumer product to B2B SaaS and eventually toward enterprise. If we had been a huge company with hundreds or thousands of employees built around the original consumer model, making those changes would’ve been incredibly complicated. There would’ve been departments whose jobs depended on that strategy, marketing campaigns already planned months ahead, budgets allocated around it, executives responsible for particular business units, and investors or board members who might need to approve a significant change in direction.

In a small company, the conversation is very different. We can look at what’s happening, talk about it as a team, decide whether the evidence is strong enough, and start adapting.

That’s where I think people sometimes underestimate the advantage a startup has over a large competitor. When you’re looking at a Fortune 500 company, it’s easy to focus on everything they have that you don’t. They may have millions of dollars available for development, huge marketing budgets, established customer relationships, legal departments, sales teams, and an existing brand that people already recognize. From a resource standpoint, there’s no comparison.

Technically, they should be able to beat you at almost everything.

But those resources come with organizational weight.

I’ve seen that firsthand now that I spend more time selling into enterprise organizations and universities. Even when everyone agrees that something is a good idea, decisions still have to move through the organization. The person you’re talking to might love the product, but they need someone else involved. Then procurement has questions, legal needs to review the agreement, information technology wants to understand the infrastructure, accounting needs to approve the budget, and eventually you may have several people participating in a decision that started as a simple conversation.

There’s nothing inherently wrong with that process. A large organization has responsibilities that a five-person startup simply doesn’t have, and those checks exist for good reasons. But they create time between recognizing an opportunity and acting on it.

I’ve always thought of it almost like the Stay Puft Marshmallow Man in Ghostbusters. He’s enormous, powerful, and completely intimidating when you see him walking through New York City. The Ghostbusters look tiny standing next to him. But he’s also this gigantic marshmallow lumbering through the streets while these four guys can run around, change direction, communicate with each other, and react immediately to whatever is happening.

Startups have a little bit of that advantage.

We may not have the size or the resources, but we can move.

The smaller team itself makes a huge difference because communication happens almost automatically. In most of the startups I’ve worked on, I can talk directly to everyone involved in building the product. If a customer tells me something important during a sales call, I don’t need to write a report that eventually gets passed to another department. I can message the developer and explain exactly what the customer said, why I think it matters, and whether we should test a change. Depending on what it is, we might have a new version working within a few days.

That kind of communication is difficult to maintain as a company grows. Once you have separate departments for sales, marketing, engineering, product, customer service, legal, and everything else, information has to travel through an organization before it reaches the person who can actually act on it. Along the way, people interpret what they heard, priorities compete with each other, schedules have already been established, and something that seemed urgent to the customer may become one item in a backlog of fifty other things the development team is supposed to address.

I’ve experienced the other side of this through enterprise sales, and it’s given me a much better appreciation for why these companies move the way they do. You can be talking with somebody inside a large organization who completely understands the problem you’re solving and genuinely wants to move forward, yet that person usually can’t make the entire decision alone. There may be a security review because you’re handling data, a legal review because there’s a contract involved, a budget approval because the purchase exceeds a certain amount, and technical conversations about how the platform will fit into their existing systems. A decision that I could make for one of my companies this afternoon might reasonably take a large organization several months.

The irony is that they have far more people available to solve the problem.

If I need a feature built, I might have one developer available. A large technology company could potentially assign twenty engineers to the same problem. They have specialists in areas where I’m figuring things out as I go, along with infrastructure and capital that would take me years to build. On paper, the larger company should be able to move much faster because almost every resource constraint that I have doesn’t exist for them.

The constraint becomes coordination.

As the number of people involved in a decision grows, the amount of communication required grows with it. You have meetings to prepare for other meetings, project management systems to keep everyone aligned, approvals that need to happen before work begins, and competing priorities across departments that may all be perfectly reasonable. A developer might be capable of building something in two days, but getting those two days onto the development schedule could take two months.

For a startup, those two months can be an enormous opportunity.

I’ve had situations where we heard the same request from several customers and immediately recognized that there was something worth exploring. We didn’t know whether the idea would ultimately work, but we also didn’t need to know. We could build a rough version, show it to the people who requested it, and find out. If they loved it, we could continue developing it. If they barely used it, we had our answer without spending six months debating whether the feature belonged on a roadmap.

That goes back to something I really like about lean methodology. You’re allowed to be wrong cheaply.

I think that’s an underrated advantage.

I’ve been wrong about plenty of ideas. There have been features I thought people would love that they barely touched, marketing campaigns that sounded great when we came up with them and produced almost nothing, and entire assumptions about who our customers would be that changed once the product was actually in the market. Being a small company gave us room to discover those mistakes before they became enormously expensive.

A large organization has a different relationship with failure because the cost of changing direction can be much higher. If you’ve spent millions of dollars developing a product, hired an entire division around it, signed agreements with vendors, committed to marketing campaigns, and announced the strategy publicly, walking away becomes a serious decision. Even if people inside the company recognize that the market has changed, there are practical consequences to changing course.

A startup usually has much less to unwind.

That’s part of what happened as we moved Vengo AI toward enterprise. We didn’t have thousands of consumer employees or physical stores or some enormous infrastructure tied permanently to the original model. We had technology, a small team, customers giving us information, and the ability to decide where we thought the strongest opportunity was developing. That flexibility allowed the company to evolve along with what we were learning instead of forcing the market to fit the plan we’d written years earlier.

Of course, being nimble can become a problem too.

I’ve seen founders confuse adaptability with constantly changing their minds. If you pivot every time one customer makes a suggestion, you can end up building a product that has no clear identity at all. I’ve certainly had moments where someone requested a feature and my immediate reaction was that we should build it, only to realize after thinking about it that this was one person’s preference rather than evidence of a larger need.

So I’ve become much more interested in patterns.

If one person asks for something, I listen. If five unrelated customers start describing the same problem in different ways, I pay very close attention. At that point, the advantage of having a small company isn’t simply that we can move quickly. It’s that we can decide quickly whether something deserves our attention, test the idea without turning it into a massive initiative, and allow the response from real customers to tell us what we should do next.

I think this way of working also changes how you think about competition. Earlier in my career, I would look at a much larger company entering a market and immediately assume they had the advantage. They had more money, more people, established customers, and usually a recognizable name. If they decided to build something similar to what we were working on, there was always that concern that they could simply throw resources at it and catch up very quickly. After spending enough time building companies, I’ve become much less intimidated by that because I’ve seen how difficult it can be for a large organization to turn those resources into speed.

A startup can spend Tuesday talking to customers and Wednesday changing the product based on what it heard. By Friday, you might already have something new to show those same customers. I love working that way because the distance between an idea and an actual test is incredibly short. You don’t have to convince yourself that you’ve found the perfect answer before doing anything. You can make a reasonable decision, put it into the market, gather information, and continue from there. Over time, all of those small adjustments can move the company surprisingly far from where it started, which is exactly what happened with several businesses I’ve worked on.

There is also something valuable about having the people making decisions close to the people actually doing the work. In a small company, I usually know what the developers are dealing with, what customers have been saying, how sales conversations are going, and where we’re spending money. I don’t know every detail every minute of the day, but I can see enough of the whole picture to understand how one decision affects another. If we decide to pursue a new type of customer, I can immediately think about what that means for the product, how we’re going to market it, whether our pricing still makes sense, and what the development team might need to change.

As companies get larger, that view naturally becomes fragmented because no single person can stay involved in everything. The people closest to customers may have very little interaction with the engineers building the product, while executives are making decisions based on information that’s been collected and summarized by several layers of the organization. Again, I don’t think that’s necessarily poor management. At a certain size, you have to create structure or the company would become impossible to operate. The same structure that allows ten thousand people to work together, though, can make it difficult to respond with the speed of ten people sitting in the same room.

There’s a tradeoff here that I think founders sometimes overlook because we’re usually so focused on growing. We want more customers, more revenue, more employees, and greater resources because those things generally mean the company is succeeding. But growth also introduces complexity, and complexity eventually changes the way a company behaves. Decisions that once happened during a five-minute conversation start requiring meetings. The founder who once knew every customer eventually needs a sales organization. The developer who could release something whenever it was ready now has processes designed to make sure an update doesn’t affect millions of users.

I’ve had to think about this in my own companies because I don’t want to romanticize being small either. There are plenty of times when I would’ve loved to have a larger team or a much bigger budget. Being nimble doesn’t magically solve the problems that come with limited resources. Sometimes you know exactly what you should build and simply don’t have enough people to build it as quickly as you’d like. There are opportunities you can’t pursue because everyone is already busy, and there are moments where one person being unavailable can affect an entire project because there isn’t another department waiting to take over.

What I’ve become more conscious of is using the advantages I actually have instead of wishing I had the advantages of the company I’m competing against. If a larger competitor can spend more on advertising, trying to beat them through advertising probably isn’t the smartest use of my time. If they have a sales organization with hundreds of people, I’m not going to recreate that with a small team. I can spend more time talking directly with customers, respond faster when I see an opportunity, experiment without putting millions of dollars at risk, and make decisions without needing ten levels of approval.

I’ve seen how meaningful that can be when dealing with enterprise customers. Sometimes a large organization comes to a small technology company precisely because we can do something their internal teams would struggle to accomplish quickly. They may already have talented developers and tremendous technical resources, but getting a new project prioritized internally can be difficult when those teams are responsible for dozens of other systems. A small outside company can focus on one problem, work closely with the people experiencing it, and sometimes have a solution running while the larger organization would still be figuring out which department should own the project.

I find that dynamic fascinating because it reverses the way I used to think about size. I spent years assuming that becoming larger automatically made a company stronger. Now I see size as one characteristic among many. It gives you resources, stability, reach, and the ability to take on projects a small company couldn’t possibly handle, while also creating responsibilities and processes that affect how quickly you can respond.

For me, the goal isn’t to stay small forever. I want the companies I build to grow, and I want them to have more resources than they have today. What I hope to preserve as they grow is some of the behavior that made being small useful in the first place: staying close to customers, keeping communication direct, testing ideas before overcommitting to them, and being willing to change direction when the evidence says something isn’t working.

I don’t know how much of that you can realistically preserve as an organization becomes much larger. That’s something I’m still figuring out myself. Every stage of a company seems to introduce a different set of problems, and maybe the real challenge is recognizing when the habits that helped you reach one stage need to evolve for the next. For now, though, whenever I look at a huge competitor with resources I couldn’t possibly match, I remind myself that they also have something I don’t have: all that weight to carry around. And sometimes being one of the little Ghostbusters running around the Stay Puft Marshmallow Man isn’t such a bad position to be in. Hope you enjoyed this episode, and I’ll see you in the next one.