Deep vs. Wide

I’ve been thinking about something that keeps showing up in my work. At Olea, at Basic Memory, in conversations with other founders. It’s a pattern, and I think it needs a name.

I’m calling it deep vs. wide.

How it used to work

Before AI, software teams had a natural speed limit. Writing code took time. A feature that took two weeks to build gave the rest of the business two weeks to prepare. Marketing could write the copy. Support could learn the feature. Accounting could update the billing. The pace of engineering roughly matched the pace of everything else.

Nobody designed it that way. It was just a side effect of how long software took to build. The bottleneck was the code, and that bottleneck gave everyone else time to keep up.

That bottleneck is gone.

Going deep

Deep is what software teams have always done. Get a spec. Write the code. Ship the feature. Move to the next ticket. It’s what engineering culture celebrates. Ship fast. Iterate. Deploy on Friday if you’re brave enough.

AI didn’t change what deep means. It changed how fast you can go. Features that took weeks take days. Sometimes hours. I’m shipping at a pace that would have been impossible two years ago, and I’m not special. Anyone with a good AI workflow is experiencing the same thing.

Deep got faster. That’s the good news.

Going wide

Wide is everything else that has to happen for a feature to matter to anyone besides the people who built it.

Does management know it’s coming? Are the people who influence your market talking about it? Has marketing previewed it, introduced it, explained why anyone should care? Can customer service support it when someone calls with a question? Is accounting billing for it correctly?

In a big company, these functions are handled by entire departments. Product managers, marketing teams, support leads, billing ops. The feature moves through a pipeline that touches all of them before it ever reaches a customer.

In a small team, all of those roles collapse into a few people. Sometimes one person. And when that happens, steps get skipped. Not because anyone decided they weren’t important. Because there’s no one whose job it is to remember them.

Wide didn’t get faster. That’s the problem.

The gap

Engineering velocity went to 10x. Everything else stayed at 1x. And that gap is growing every week.

I’m watching it happen in real time. At Basic Memory, we’re building fast. Really fast. But are our users hearing about new capabilities as quickly as we ship them? Are we making sure people know how to use what we just built? Are we capturing feedback in a way that feeds back into the next iteration? Sometimes. Not always. Not consistently.

Before AI, the answer to “why didn’t marketing know about this feature?” was usually “because we haven’t built it yet.” Now the answer is “because we built it Tuesday and forgot to tell anyone.”

That’s a new kind of problem. And most teams don’t even realize they have it yet.

The grid

Here’s how I’ve been visualizing it.

Imagine a grid. The rows are your features. The columns are business functions: product spec, marketing preview, pricing, engineering, launch announcement, support training, billing setup, customer feedback, iteration.

Left columns are pre-launch. Middle columns are launch. Right columns are post-launch.

Here’s what it looks like in practice:

Features A through C are what most teams actually look like. The engineering column is full. Everything else has gaps. Feature D is what a real release looks like. Most teams never get there.

Every feature should fill an entire row. But on most teams, the only column that consistently gets filled is “engineering.” Everything else is spotty at best, empty at worst.

Look at your last three feature releases. How many of those columns did you actually complete? If you’re honest, the answer is probably uncomfortable.

Shipping is not releasing

This is the core distinction. Shipping a feature means the code is deployed. Releasing a feature means the business is ready for customers to use it.

Those are two very different finish lines. And if you’re only crossing the first one, you’re leaving value on the table. Worse, you might be creating confusion. Features that show up in the product without context, without documentation, without anyone knowing they exist. That’s not agile. That’s just chaotic.

What I’m doing about it

I don’t have this figured out. I’m writing about it because I’m in the middle of trying to solve it for myself.

But the grid helps. Even just drawing it out on paper for a project forces you to see the gaps. It turns “we should probably tell people about this” into a visible empty cell that bothers you until you fill it.

I think the fix isn’t to slow down development. It’s to apply the same AI leverage to the wide columns that made the deep column so fast in the first place. Use AI to draft the marketing copy. Use it to generate support documentation. Use it to prepare the launch announcement. The same tools that are accelerating engineering can accelerate everything else, if you remember to point them in that direction.

The hard part is remembering. When you’re deep in the code, going wide feels like a distraction. It feels like overhead. But it’s not. It’s the difference between building something and building a business.

If you’re on a small team shipping fast and feeling like the rest of the business can’t keep up, you’re not alone. The answer isn’t to slow down. It’s to go wider.