Brownfield product. Do you still need a product strategy?

Brownfield is the honest word for most products: years of code, paying customers, and a backlog nobody has read to the bottom of. Teams in this position tend to think strategy is for the next product, not this one. This one has momentum. The trouble is that momentum is exactly what a coding agent amplifies.

What happens without the page

A team serving enterprise customers moved to AI-assisted development this year. Two developers, one product manager. Delivery got much faster. Within a few months there was always something waiting on a decision, not on a developer, and the backlog started to look like a list of whatever the last customer call produced. They hired a second product manager. That is a team discovering, at speed, that a brownfield product without a written direction fills up with output.

Brownfield strategy starts from the product, not the vision

For a new product, the page is mostly intent. For an existing one, half the page is already true and nobody has written it down. So start there.

• What the product can do today. Capability by capability, with an honest maturity next to each. Feature1 reads this from the repository; the point is that it is read, not remembered.
• Where you actually win. Not where the pitch says. Read the last twenty wins and losses.
• The two or three strengths to compound. Usually the ones customers renew for, which are rarely the ones on the homepage.
• What you will stop doing. The features that exist, cost maintenance, and serve nobody in the segment you win with.

The gap is the roadmap

Put the page next to the capability list and the differences appear on their own. Where the strategy says you win and the product is thin, that is your first initiative. Where the product is deep and the page does not mention it, either you have been building the wrong thing or the page is wrong. Either answer is worth an afternoon. Here is how the gaps become a roadmap, and with coding agents, how the roadmap updates itself when the code changes.

Why this is urgent, not just useful

Because your team is about to get faster whether or not the direction is written down. The only question is whether they get faster at the right thing.