Case Study · 11 2025

Roadmapping by Complexity, with AI

A tactical way to use AI for fast initial planning: inventory what exists, sort every idea by what it costs to build, and the MVP becomes obvious.

Role Staff Product Designer Themes AI Product Strategy Process

What problem existed?

A complex redesign came with a long wishlist. Every stakeholder had ideas, and many were good. Generating options was easy. The hard part was deciding what to build first, and in what order, without spending a week on analysis the project could not afford.

Real roadmapping is slow because the useful axis is hidden. The value of an idea is easy to argue about. The cost is what actually sorts the list, and cost is buried in feasibility, dependencies, and what already exists to reuse.

Why did it matter?

A team needs a concrete starting point to align on. Without a first cut, you either over-scope, trying to ship everything and stalling, or under-scope, shipping the easy things and missing the point. A fast, defensible starting roadmap gives the team something to react to, which is where the real planning begins.

What constraints existed?

This was a designer’s first pass, not an engineering estimate. I could read complexity, but not certify it.
The roadmap had to be a hypothesis the team could validate, something to shape together.
The window was short. The point was to go from idea to structure in an afternoon.

What role did I play?

I framed the method and ran it. I treated AI as a planning analyst: I gave it the wishlist and the existing system, and had it do the slow part fast, inventory what could be reused, and sort every idea by what it would actually take to build.

What options were explored?

Gut-feel prioritization. Rank the wishlist by intuition. Fast, but it hides cost and starts arguments about value.
Complexity-first sorting. Score every idea by what it depends on, then let the cheap, high-value work fall out as the MVP. This is the direction.

List every idea Inventory what exists Score by complexity Sort MVP vs later

What tradeoffs were considered?

The tradeoff was speed against certainty. An AI-assisted sort is a first-pass hypothesis, not ground truth. Some complexity reads will be wrong, and a few “cheap” items will turn out to be more complex than they looked. It is worth it anyway: a structured, mostly-right starting point in an afternoon beats a blank page, as long as everyone treats it as a draft to pressure-test.

How did UX, engineering feasibility, and business strategy intersect?

The sort lives exactly at that intersection. The MVP was the work that was high-value and frontend-only: no backend, no new data, nothing that waited on another team’s roadmap. The deeper wins were real but depended on backend and data work, so they became a later phase. The business got a visible result fast, and engineering got a dependency-aware target instead of a wishlist.

How was AI used in the process?

This is the whole tactic. I used AI to do three things quickly:

Inventory the reusable parts. I had it read the existing system and list what already existed to compose with, so “new work” shrank to the genuinely net-new.
Score each idea by complexity. For every item, what does it actually need: just the frontend, or backend, data, or another team? That dependency read is the real cost.
Tag the cut, with confidence. Each idea got an MVP-or-later tag and a confidence level, so the shaky estimates were flagged for a human to check.

In practice that was close to one prompt:

feasibility-triage.txt

Read the existing system and list every component, endpoint,
and pattern I could reuse. Then, for each proposed feature,
tell me what it actually needs to ship: frontend only, or
backend, data, or another team. Tag each as MVP or later, and
flag your confidence so I know which estimates to check by
hand. Do the analysis; leave the final cut to me.

The wishlist, sorted by what it costs to build

MVP = high value, no backend dependency. Ship it now; park the rest.

Clearer header and metadata frontend only MVP
Copy / open-in-AI menu frontend only MVP
Collapsible long sections frontend only MVP
Summary stats from real data backend data Later
Machine-readable structure the build pipeline Later
Related items and results backend data Later

Every idea tagged by what it needs to build. Once the dependencies are visible, the cheap, high-value MVP sorts itself out.

AI ran the analysis, and people made the decisions. It compressed a week of feasibility triage into an afternoon, while the judgment and the final roadmap stayed with the team.

What was learned?

Complexity is what actually sorts a roadmap, and it is the thing teams skip because it is tedious. AI is unusually good at the tedious part: reading a system, listing dependencies, and making a fast first-pass call. The pattern that fell out, ship what is cheap and independent, park what is valuable but dependent, is one I now reach for on any over-scoped project.

What was the outcome?

A complexity-sorted MVP roadmap, plus a working preview of the MVP itself, produced in a fraction of the usual time. The MVP was the cheap, high-value, dependency-free work. The deeper data and backend wins were named and parked for a later phase. The team had a concrete, dependency-aware starting point to validate and build from.

A leadership note: a fast draft to validate

The honest caveat first: this is a designer’s first-pass roadmap, made with AI. The complexity reads are educated guesses rather than engineering estimates, and the roadmap is a hypothesis to validate and shape with the team.

That said, as a way to interact with AI for fast initial planning, it is genuinely powerful. The tactic, in four moves: give the AI the wishlist and the existing system, ask it to inventory what you can reuse, sort every idea by what it actually depends on, and flag its confidence. You walk into the planning conversation with structure instead of a blank page, and the cheap, high-value MVP is usually staring back at you.