The case for treating your website as a product, not a brochure

What makes a website a "brochure" in the harmful sense?

Not the content. The operating model. A brochure site is defined by three symptoms: a multi-year redesign cycle, no owner between redesigns, and no testing surface. Content updates queue behind marketing campaigns; performance improvements queue behind whoever has time. Between redesigns, the site is effectively frozen.

The problem is that the site is usually the highest-traffic owned surface the company has, and the only one that actually compounds. Frozen surfaces don't compound.

What does treating the site as a product actually mean?

Four moves:

Name an owner. A single accountable person for the site's traffic, conversion, and revenue contribution — not a committee, not a shared marketing responsibility. If no one owns the number, no one improves it.

Keep a real backlog. Prioritized, sized, visible. Not a design queue for the next redesign. A rolling backlog of experiments, content improvements, and technical debt, ordered by expected impact.

Ship on a cadence. Weekly or biweekly, not quarterly. The value of shipping small changes often is that you can attribute what happened. Big-bang redesigns destroy attribution.

Run a testing surface. At least one live test at all times on a high-traffic surface. The point is not the individual test. The point is the muscle: a team that ships tests weekly learns what its audience responds to at a rate a brochure team never will.

What is the counterargument, and is it right?

The counterargument is that B2B sites do not have enough traffic to test. Sometimes true, more often overstated. If a site has enough traffic to justify a full-time content team, it has enough to run high-contrast tests with honest uncertainty. The remedy for low traffic is not to stop testing — it is to design bigger tests and report with wider intervals.

The second counterargument is that redesigns lock in brand consistency in a way continuous change does not. Fair. A product model does not mean chaos; it means a shared design system and a release process. The consistency lives in the system, not in the freeze.

What I would do differently

The single change with the largest return, in every program I have run, has been shortening the release cycle. Not because any individual change is transformative, but because it collapses the feedback loop between intent and evidence. A team that ships weekly makes better decisions in six months than a team that ships quarterly does in two years. Everything else — the backlog, the tests, the owner — is downstream of that cadence.