Wardley Mapping with Kiro: Integrating Strategy and Product Building with AI agents

Last week, I embedded my Wardley Mapping principles directly into my AI development workflow.

The experiment worked - but not how I expected. It revealed two gaps I hadn’t fully appreciated before:

1. How can I influence engineering decisions with agent rules/steering documents?
2. Where is this going to evolve?

The Problem I Was Trying to Solve

I’ve been mapping landscapes for years, but there’s always been this frustrating disconnect. I’d create these detailed maps showing how components evolve, identify strategic opportunities, then watch and participate in a team effort to build features that completely ignore the landscape context.

It’s not that we, as product builders, are bad at what we’re doing. Most are good at:

• Identifying the customer needs
• Building perceived features
• Prioritizing based on business value

But here’s what I kept seeing us miss:

Where does this component sit in the broader evolution of the landscape?

Example: A team planned to build their custom authentication system. They evaluated for better UX, security - all correct product thinking. But they missed the landscape context: identity management has commoditized (AWS Cognito, Auth0), while custom protocols remain in genesis. The strategic question: why build what you can buy?

(Some might say “We don’t want AWS in the middle of it, we want more control.” - Sure, but what about opportunity cost?)

This happens constantly. Smart people making locally optimal decisions that are product suboptimal because they can’t see the landscape forces.

Even if they could see, how can the strategy perspective of the product align with development in a large scale organization?

Cursor Rules and Kiro Steering

As the developers need for better and consistent LLM prompting results lead to the creation of LLM rules, the development team’s need for consistent team practices forced product teams to share their team’s development rules (in Cursor Rules and Kiro’s Steering Directives) through their version control.

But, what about product and development strategy practices? How can I encode my Wardley Mapping thinking directly into the development process?

The Kiro Strategy Experiment

I’ve decided to experiment with Kiro. If you haven’t seen it yet, Kiro has two major features that drew me in:

• Steering - akin to Cursor Rules, with a slightly better UX
• Specs - a prompting process flow, which takes your prompt through 3 phases:
  1. Requirements - where it writes user stories and their acceptance criteria in a WHEN, IF, THEN, SHALL manner.
  2. Design - document where it designs the main feature components, interactions, structure and tests.
  3. Tasks - a document list of tasks on a user story level

Here is a partial example “document analysis” feature spec prompt result:

And here are the following tasks:

Now these do look great, but from a Wardley mapping point, it doesn’t help if you’re automating specification and task creation if you’re moving in the “wrong” direction. Sure, with Kiro Specs you can do it 10x faster, but its as if you’re driving 200mph straight into a wall.

I wanted to apply my strategy principles before writing any specification. But, at the moment that isn’t possible, so I decided to write a steering document / rule.

In general, instead of hoping people will read my maps (they won’t, usually just a glance), I embedded my mapping approach into the development environment using Kiro’s Agent Steering (Cursor rules). Every build-vs-outsource development decision now gets challenged by my mapping principles, even when I’m not in the room.

Within the directive, I’ve put four strategic questions:

1. What are you building that you could buy?
2. Where does this sit on the evolution axis?
3. What’s the switching cost if you’re wrong?
4. What user need requires a custom implementation?

The Result

I’ve decided to test this on the above mentioned example feature for “document analysis”. I wanted to provide a “wrong” approach that I wanted to build the feature with a custom ML pipeline.

I wrote the prompt and included the Wardley Mapping steering when starting the Kiro spec, and it immediately challenged the approach:

Document analysis is rapidly commoditizing through GPT-5, Claude, and AWS Textract. Before building custom ML pipelines, have you evaluated these services? What user need requires custom implementation?

This wasn’t me being there — it was my strategic thinking embedded in the solutioning workflow. If that was a developer they would be forced to stop before implementing it.

That’s exactly what I wanted.

Before writing the tasks or building a feature, the engineer was asked to reevaluate the approach and instead of a custom built feature, the LLM suggested to use an existing, commoditized service.

But you can already assume where this won’t work.

When Does It Fail

I tried the same approach on a real-time collaboration feature. Without specific context, the steering kept pushing toward commodity solutions (Google Docs API, Notion), but the team had a specific context and customization requirements that genuinely needed a custom implementation.

It backfired. The LLM questioned a feature development decision that was actually correct and started annoying the team. The team started ignoring it entirely. I realized I’d created a strategic “know-it-all” annoyance that couldn’t read the room.

When to Use Strategic AI Steering

Commoditizing components: AI steering wins 90% of time. Most of the time we are unaware of the tools that already exist on the market and we’re trying to build the existing thing ourselves.

Build-vs-buy decisions: The steering consistently helps me to avoid building things that are commoditizing. I’ve saved probably 3 months of development time (a.k.a. my life) by using existing services instead of custom implementations.

Where It Struggles

Context-heavy decisions: I’ve tried several context-heavy product features and the steering couldn’t read the room - it’s still an LLM. Sometimes a custom implementation is the right choice, but the AI keeps pushing toward commodity solutions.

Timing-sensitive choices: Just because something will commoditize doesn’t mean it has commoditized yet. Early adoption of immature services can be worse than custom implementation.

Team buy-in: If people don’t understand why the AI is asking strategic questions, they ignore it. The steering works best when teams understand the underlying mapping principles.

The Surprising Benefit - the Possible Evolution

The biggest win wasn’t what I expected. I thought this would help teams make better strategic decisions (it does). But the real value was seeing how to make strategic thinking scale across the team and how the potential future in how will these rules might evolve.

I can’t be in every product decision. But my mapping principles can be. When a team in another timezone is evaluating a new feature, they get the benefit of landscape context questions even when I’m asleep.

It’s like having a Wardley mapper embedded in development that consistently asks: “Where does this component sit on the evolution axis? What forces are acting on it?”

Additionally, these rules aren’t the only thing an organization has, but actually two categories:

• Policies - the specific team rules such as: variable naming, tabs vs spaces, guard-rails, infrastructure rules and others.
• Knowledge Patterns - domain patterns, the business know-how, differentiating processes.

My Wardley Mapping steering belongs to the Knowledge category, but how can I share it accross the organization?

And as my fellow AWS Hero Chris Miller said: “No Product or Business executive will open up any IDE and write down their strategy documents and push to GitHub.”

Where might this evolve?

What about a Strategy Steering / Rules Hub?

Currently, every organization member has to read through the strategy and product documents first before they start working in their team, and most of that documentation tends to be forgotten or even obsolete. With org memebers now constantly using LLMs for speeding up their work - integrating Org Rules and Strategy documents with LLMs directly can align the team more.

We already have:

1. Rules and steering documents sitting in development environments
2. Strategy and Product documents sitting in Confluence, Google Drive or Notion

Combined through a simple integration, organizations could be enabled to have living documentation and living principles when building their products. Product leaders could get their strategy embedded in the actual work. This could create a bridge between business landscape awareness and product / development decisions together with LLM usage.

The organizations that get the most value will be the ones where:

• Leadership understands Wardley mapping principles (so they can refine the steering)
• Product builders see immediate tactical benefits (faster decisions, less wasted work)
• The strategic context is specific and actionable (not just “consider the landscape”)

Personal Opinion: There’s a chance that both Kiro and Cursor will build both Policies and Knowledge as a feature, along with Steering Org Hub.

The Honest Assessment

After several features, I can safely say this approach works with a few requirements:

• when you already know Wardley Mapping
• the team you work with knows its tools, has an open mind and is collaborative
• when specific context has been provided

I am fully aware that this might automatically discard 95% of the organizations out there.

The approach fails when it starts annoying the team without clear value or incorporating the specific context or the team is simply unwilling.

It’s real value is:

Making landscape awareness executable at the moment of engineering decision, not just during planning sessions.

As a parting note, I would recommend at least experiment with it on one evolving component where build-vs-buy matters.

What’s your experience? Have you tried embedding strategic thinking into some of your workflows? Really curious what did work (and what didn’t) for others. This landscape is constantly evolving, and I suspect there are and will be better approaches we haven’t discovered yet.

Find me on X if you want to share your experiments or challenge my assumptions.