Working Backwards: How We Turned Amazon's Most Powerful Product Principle Into an AI Agent

There's a reason Amazon has shipped so many products that actually matter to people. It's not just resources or talent — it's a discipline. Before a single line of code gets written, teams at Amazon are required to answer one deceptively simple question: what does the customer experience look like when this is done?

They call it "working backwards." And after using it ourselves for years, we decided to stop treating it as a mental framework and start treating it as a job — one that an AI agent could do, consistently, at the start of every build.

The Idea Behind Working Backwards

Amazon's process is straightforward in theory and surprisingly hard in practice. Instead of starting with what you can build, you start with what the customer should experience. You write the press release first. You draft the FAQ before the spec. You define what success looks like for the person on the other end before you touch an architecture diagram.

The discipline forces a shift in perspective that most product processes quietly avoid. It's easy to get pulled into implementation thinking — how do we build this — before you've locked down what we're actually trying to do and for whom. Working backwards keeps you honest.

The result is fewer features that miss the mark, fewer pivots late in the build cycle, and more clarity going into execution. It's not magic. It's just rigor applied at the right moment.

Turning a Framework Into an Agent

When we were designing Perspect's multi-agent system, we found ourselves asking: what if we stopped leaving this discipline to chance? What if the platform itself enforced working backwards before any implementation agent lifted a finger?

That's how the Planning Agent was born.

The Planning Agent's sole job is to take an underspecified request — the kind every builder makes, like "add a pricing page" or "create a membership flow" — and interrogate it from the customer's perspective before anything gets built. It reads memory for relevant past decisions. It inspects the current site state so it doesn't ask questions the site already answers. And then it works backwards from the intended outcome to identify exactly what's still missing.

The output isn't a spec or a prototype. It's a minimal set of questions — typically three to six — each one focused on the customer-visible result, not the mechanics of building it.

What It Looks Like in Practice

When you give Perspect a vague directive, the Planning Agent kicks in first. It starts not with "how do I implement this" but with three prior questions:

• What is supposed to exist or change when this is done?
• Who is it for?
• What problem does it solve, or what action should it enable?

From there, it works backwards. It checks what's already decided — by your previous choices, your existing site patterns, your stored preferences. It eliminates every question it can answer on its own. What remains is the smallest possible set of clarifications needed to make the outcome unambiguous.

The questions it asks are framed in terms of what a visitor will see, what a user will be able to do, and what "done" looks like — not in terms of database schemas or component libraries.

This distinction matters more than it sounds. Implementation questions tend to generate implementation-shaped answers. Customer-outcome questions generate clarity about what actually needs to exist.

The Defaults Rule

One of the Planning Agent's core principles is that existing patterns are assumed to be intentional. If your site already has a consistent navigation structure, a defined content hierarchy, or an established visual rhythm, the agent defaults to preserving those — and asks only when a deliberate change is genuinely required.

This prevents a common failure mode where an AI agent, trying to be helpful, introduces friction by asking about things that already have answers. Every unnecessary question is a tax on your attention. The Planning Agent's job is to eliminate that tax, not add to it.

Why a Dedicated Agent

We could have baked planning logic into every agent as a preprocessing step. We chose not to.

A dedicated Planning Agent creates a clear separation of concerns. Execution agents are good at building. Planning agents are good at asking the right questions. Mixing the two tends to dilute both. When planning is a first-class role, it gets the full attention the working-backwards method deserves — memory access, site inspection, structured output — without competing with the pressure to produce deliverables.

It also creates a consistent entry point that users can trust. Every build on Perspect starts the same way: with a structured look at what the customer should experience at the end, before anyone decides how to get there.

A Proven Method, Applied at Scale

Amazon invented working backwards because large organizations, moving fast, have a tendency to optimize for building rather than for outcomes. The discipline was a corrective — a way to keep the customer's experience as the organizing principle of every product decision.

We're not Amazon. But the underlying problem is universal. Anyone building something — at any scale — can drift from outcome-first thinking into method-first thinking without realizing it.

Perspect's Planning Agent is our answer to that drift. It's a small piece of the platform, but it carries a disproportionate amount of weight. Done right, the planning step is what makes everything that comes after it faster, more focused, and more likely to land the way it should.

Working backwards has always been one of the best ideas in product development. We just gave it an agent.