Case Study: Product Development

You can solve two problems at once if you know where to look.

I analyzed every state's requirements and found overlapping structure no one had documented. The modular architecture I designed serves 43 markets from a single content base and supports two product tiers from one build.

Mae Mendoza · Senior Content Strategist and Architect

01 — The Starting Point

Two related products in the ecosystem. Both failed the QA audit.

Both products showed their age. Created in the mid-2000s, relying on outdated data and disproven frameworks. Years of patching defects had degraded the information architecture in both.

The products needed to be rebuilt from the ground up for today's user.

Legacy Product A
Product Line 1

QA Audit Score

Legacy Product A

The core problem

Content created in 2008, still running on the original information architecture. Years of quick fixes left the product incoherent.

Legacy Product B
Product Line 2

QA Audit Score

Legacy Product B

The core problem

Years of building new content by repurposing old had eroded the original structure. Users noticed, and they complained.

02 — The Compounding Cost

The longer we patched, the more expensive the problem became.

Every product in the ecosystem had the same structural failures at different stages of decay.

The Quick Fix Trap

Fixing one outdated reference created conflicts elsewhere. Each successive patch eroded the content structure further. Every fix created new problems.

Regional Requirements Pressure

Every regional revision cycle generated a new gap analysis. Without a systematic approach to coverage mapping, updates were reactive and perpetually incomplete.

Updates Don't Scale

Two product lines, most of the content more than a decade old. The same subject matter expert reviewing the material was also doing the mechanical work of locating requirements.

Competitive Risk

An advanced-tier product was a known gap. Competitors already offered one. Every quarter without a credible option was a quarter the sales team couldn't answer for.

03 — The Opportunity

A 50-state coverage analysis revealed the potential reach.

I mapped every region's requirements against 10 core content categories. Hover over any state or click a tier in the bar below.

Full coverage (18)

Strong coverage (16)

Moderate (9)

Limited (4)

Minimal (3)

Core market: full or strong coverage

Full + Strong

Extended market: moderate or better coverage

Full + Strong + Moderate

04 — Why Modular Works Here

The content is already organized by domain. The architecture should be too.

Regional requirements share structural patterns. Modular architecture mirrors that: each domain is a self-contained module that can be updated without touching the others.

Standard tier (shared base)

Advanced tier (extended depth)

12345 678910

Content domains, sorted by regional coverage

34states served at launch

1build produces both tiers

0content duplication

Same content, deeper coverage.

05 — What the Architecture Delivers

A model for maintaining complex systems at scale.

Maximum Coverage

Every content domain earns its place by appearing across the most regions.

Efficient Updates

When a region adopts new requirements, a module gets added. One region's change never cascades into another region's content.

Dual-Build

One content base, two product tiers. A single build that replaced multiple aging products and preserved region-specific customization.

Competitive Positioning

Quantified positioning, market by market.

06 — The Result

A repeatable process for the product ecosystem.

Two product tiers from one build.
A standard and an advanced content system from a shared content base.

34-region core market on launch.
Documented path to 43 via modular supplements.

Evidence-based positioning.
Region-specific coverage data no competitor could match.

The Takeaway

The content problem was really a systems problem.