Strategy Is a Filter, Not a Plan

The brief I got was short: figure out if this can be salvaged, or kill it.

The product was the Adaptavist Library, and by the time it reached me it had been through three product managers. That detail tells you most of what you need to know. Nobody quits a product that's working, and three in a row isn't bad luck, it's a structural problem wearing different names.

I spent the first stretch interviewing – the previous PMs, the engineers, customers, developers on other teams – and the story that came out was familiar. The original PM had a hallway comment from the CEO, the wouldn't it be cool if this existed kind, spent a weekend building a prototype, shipped it, and used that to get approval for a team. What he never had was a strategy. He had a list of neat ideas, which is a different object entirely, and the list kept growing because nothing in it had the authority to say no to the next item.

The map that explained the architecture

Understanding the original scope explained why the code looked the way it did. The idea was enormous – three buckets, any one of which could have been its own product – and it was being built by roughly three developers and one PM.

I charted it on a Wardley map, which arranges the components you need against how evolved each one is: Genesis, Custom Built, Product, Commodity. Left to right, novel to utility. The useful thing about the exercise is that it makes a particular pathology impossible to miss.

Nearly every component sat in the Genesis column. We were building from scratch, in-house, things we didn't actually know how to build, and customizing almost nothing off the shelf. That's an appropriate posture for the one component that's genuinely yours. As a description of an entire product built by three engineers, it's a diagnosis.

The standard move on a map like that is to differentiate where things are evolving and optimize where they're stable – build the novel thing, buy the commodity. So the work was to find the single component that was genuinely ours, and shift everything else right.

Finding the one thing that was actually ours

There was exactly one: the most visible-to-the-user capability that was genuinely novel and that nobody else could provide. One, out of a feature list that had been growing for a year.

That's not a criticism of the people who built the list. Every item on it was a reasonable idea, proposed by someone competent, in response to a real request. The list was the output of a year of good-faith work by smart people. It was also the thing killing the product, because a team of three cannot hold a Genesis-column architecture and a dozen priorities at once, and the accumulated weight of all those reasonable yeses was that nothing shipped.

Then the strategy became a filter. I took the feature list and cut, and cut, and cut, until only the core proposition was left. From that point on, any new idea that didn't fit was a no – not a later, not a backlog item, a no.

What got cut

Worth naming specifically, because "we focused" is easy to say and the actual cuts are where it hurts.

In-product integrations, so you could search the library and one-click install scripts from inside other products. Automated testing and review of user-submitted scripts. A legal waiver flow assigning submitted code to us in perpetuity. All three were architecturally heavy, two of them were legally heavy, and the integration story was worse than it looked because the thing we'd be integrating into was itself a plugin. We'd have been plugging into a plugin, and inheriting every constraint of both.

None of those were bad ideas. Under different constraints – more engineers, more runway, a commodity-heavy architecture instead of a Genesis one – several of them are good. That's the part that makes cutting hard. You're not removing mistakes, you're removing perfectly good work that you cannot afford.

What saying no cost

Some people didn't love it. There was real sunk-cost resistance, particularly from engineers who'd built things that were now being taken out, and that's not irrational either. They'd spent months on work that was about to stop existing, and the fact that the decision was correct didn't make that feel better.

We got through it, and what happened next is the part I'd want anyone weighing a decision like this to know. Once the team was past the loss, they appreciated the focus enormously. They started shipping value. Customers responded, actually enthusiastically, which none of them had experienced on this product. The thing that changed wasn't talent or effort, both of which had been there the whole time. It was that there were finally few enough things to do that doing them was possible.

Running the filter afterwards is the actual work

Cutting once is a project. Keeping the filter is the discipline, and it's where most of these turnarounds quietly revert.

Within a few months of any successful focusing exercise, the requests start again, and they arrive in their most persuasive form: a real customer asked for it, a competitor shipped it, an executive is curious about it. Each one, taken alone, is a small and reasonable exception. The list rebuilds itself out of exceptions, every one of which had a defensible case, and nobody can point to the decision that undid the strategy because there wasn't one.

The thing that holds is making the filter something you have to argue against out loud. A new idea doesn't get evaluated on whether it's good – almost all of them are good – but on whether it serves the one proposition you kept. If it doesn't, the answer is no, and changing that answer means changing the strategy explicitly, in front of everyone, with the trade named. That happens sometimes and it should. What it can't be is a drift nobody authored.

The uncomfortable side effect is that you become the person who says no a lot, and you should expect that to be socially expensive for a while. It gets easier once the shipping starts, because by then the filter has visible results attached to it and people stop experiencing it as obstruction. But there's a gap between when you start saying no and when the results arrive to justify it, and you have to be willing to be unpopular across that gap.

The distinction that matters

Michael Porter got here in 1996 and said it better than I will:

Strategy is making trade offs in competing. The essence of strategy is choosing what not to do.

He goes on to note that setting limits is a function of leadership, which is the part most roadmap documents quietly decline to perform.

A plan tells you what to do. You can write one in an afternoon, everyone can agree with it, and it costs nothing because it takes nothing away. A filter tells you what not to do, which means it has to reject things, which means someone has to absorb the cost of the rejection. That's why plans are common and filters are rare. Everyone understands the idea; what stops them is that applying it costs something every single time, and it costs it to specific people sitting in the room with you.

The practical test is simple and slightly brutal. Look at your strategy document, and ask what it has rejected in the last quarter. Not what it prioritized – priorities are just a plan with a sort order. What did someone want to do, that was a reasonable thing to want, that this document was the reason you didn't do. If the answer is nothing, you don't have a strategy yet. You have a list.

When founders ask me what they should build next, the question usually isn't the one that's stuck. They can generate ideas fine; the organisation is full of capable people producing good options faster than anyone can evaluate them. What's missing is the thing that makes most of those options go away, cheaply and early, so the few that remain get enough of the team to actually work.