The Budget Didn't Give You Focus. It Was Just Hiding the Absence of It.

There is a restaurant in the city I used to live in that has been open for eleven years. It survived a flooded kitchen, two ownership changes, and a period where the head chef left without warning in the middle of a Saturday service. What it did not survive, at least not gracefully, was success.

In its fifth year, it expanded. New premises, bigger kitchen, twice the staff. The menu went from fourteen dishes to forty-two. The logic was sound: more covers, more options, more revenue. For about eighteen months it worked.

Then it didn't. Reviews started noting that the food was inconsistent. The kitchen was doing too many things at once. The dishes that had made the restaurant worth going to in the first place were still on the menu but they weren't the same. The chef was spread across forty-two problems instead of focused on fourteen solutions.

The restaurant didn't have a menu problem. It had a belief problem. It had stopped knowing what it was actually for.

I've been thinking about that restaurant a lot this January.

The conversation in most product teams right now is about cutting. Headcount is down. Budgets are tighter than they've been in three years. Every roadmap review I've sat in since October has had the same energy: we need to do less, we need to focus, we need to make sharper bets.

All of which is correct. But most teams are approaching it the wrong way.

They're starting with the list.

They pull up the roadmap, look at what's on it, and start removing the items that are hardest to defend. The newest additions go first. The speculative bets get cut. The things that haven't started yet are the easiest to kill. And three weeks later the team has a shorter roadmap that feels more manageable but is structurally identical to the original one. Same thinking. Fewer items.

That's not focus. That's a smaller version of the same unfocused strategy.

The restaurant that cuts twenty-eight dishes by removing the least popular ones still has a kitchen trying to do too many things. The restaurant that cuts twenty-eight dishes by asking "what are we actually brilliant at and willing to commit to" ends up with something different. Not just shorter. Sharper.

The question that produces focus is not "what can we remove." It's "what do we believe in enough to protect when everything else is being challenged."

Most product teams, when the pressure arrived, discovered they didn't have a clear answer.

I worked with a team last year that went through exactly this. Good people, genuinely strong product instincts, but they'd spent two years in a well-funded environment where being wrong about a bet didn't cost much. There was always another quarter, always another hire, always another feature to try next. Abundance is a very effective way of making strategic clarity feel optional.

Then the funding environment changed and leadership asked for a focused roadmap. The team produced one in two weeks. I looked at it and felt something was off but couldn't immediately place it.

It took another month to see it clearly. The roadmap was focused in appearance and scattered in logic. They'd removed items based on effort and recency, not based on belief. The things they'd kept were the things that had been on the roadmap longest, which meant they'd been kept out of inertia as much as conviction. When I asked the head of product which item on the roadmap she would fight hardest to protect if she had to cut one more thing, she paused for a long time.

She named something that wasn't on the roadmap at all.

That was the real roadmap. One item. Everything else was furniture.

This is the thing that constraint reveals, and why the teams that come out of this period sharper are not the ones who cut the most aggressively. They're the ones who used the pressure to ask a question that abundance had let them avoid: what do we actually believe this product is for?

Not the mission statement version. Not the investor deck version. The version that would hold up in a room where someone was cutting the budget in half and asking you to defend every remaining item with your own money on the line.

Most product strategies, examined that way, turn out to contain a lot of things the team built because they could, a few things they built because users asked, and one or two things they built because they genuinely believed the product needed them. The first two categories are the forty-two menu items. The third category is what the restaurant was actually for.

Funding allowed teams to carry all three categories simultaneously and call it a strategy. Constraint is forcing the question of which category the team actually believes in.

The teams I'm seeing struggle most right now are not the ones with the tightest budgets. They're the ones trying to maintain a wide surface area with fewer resources, defending every item on the roadmap with equal energy because they haven't decided which ones actually matter.

Spreading a smaller team across the same strategic perimeter doesn't produce a leaner strategy. It produces the same strategy, executed worse.

But the teams treating this moment as a forcing function rather than a crisis are asking a different question. Not "what can we afford to build" but "what do we believe enough to build when we can only build one thing." That question is harder. It requires conviction rather than consensus. It requires someone in the room to say: this is what we are, these are the things we are brilliant at, and the rest is noise.

Fewer product leaders are willing to say that out loud than you'd expect.

The ones who are, though, will have roadmaps worth reading by the end of the year. And kitchens that know what they're cooking.