Shape Mapping
There’s a feature we’ve been talking about since I started. It’s a big idea; the kind of change with cascading effects in the product. You know the one. It’s a feature that comes up anytime you talk about new ideas and innovations in the product. It always comes back to that same idea. I think that’s a good sign. When an idea is sticky, you know there’s something there. The trouble lies in finding the starting point. If you jump in without guardrails, you risk losing coherence in the final product. Progress is lost, details forgotten, and deadlines are missed.
In the Operating Cycle, Shape is the critical middle layer that governs and regulates Build and Connect. Without it, you build the wrong things, communicate the wrong things, and build more wrong things. When you invest intentional time to shape the work, you find clear starting points. You de-risk the work and release it sooner. The smaller slice makes it to real users. They use it, give feedback, and steer you in the right direction. A strong intuition guides the starting point, but integration and iteration bring out the value.
AI is an existential threat. As much as I love and use it daily, it’s true. I’m no doomsayer, but I also understand the immense power of what we are developing. Technological advancement is engrained in the DNA of the human race. We’re destined to find better, faster, easier ways to do things. Even if we can’t stop the development of it, we can stop to consider how we use it. Be intentional about how, when, and why you’re using it. More importantly, be intentional with why you’re not using it. For me, I love the messy creative process; I always have. So if AI can execute more quickly, then I want to create space for low-fidelity sketching, high-fidelity conversations, rigorous debate, attention to craft, and mindful rhythms of work. I find no joy in writing a short prompt and crossing my fingers that Claude Code figures it out. I want to do the work—leveraging AI in the process—to make those messy, important decisions about how to get started. Like humans, AI executes better in environments of clarity.
After months of conversations, I finally found the path to build this feature. It took rounds of discussions before the idea was ready. So I developed a new process to refine the concept into a format designed for agentic coding.
Once I used the prompt in a fresh Claude Code session, the work was executed almost flawlessly. All the major unknowns were resolved, so we could focus on the details and iterations to deliver a quality product.
This idea is called Shape Mapping, which lives in the Clarity Codex of the Claritorium and Value Creation of Equilio.
The five steps are:
- Surface: Create a flat list of everything.
- Structure: Build relationships in the list.
- Slice: Find the vertical slices of value.
- Simplify: Reduce scope and simplify.
- Sequence: Create the order of operations.
Surface
I love lists. Whenever I’m stressed with all the things floating in my head, I make a list. I write down everything I can think of, big and small. There’s no hierarchy or structure beyond emptying my head into the list. This is commonly called a “brain dump,” where you write everything related to a single topic.
You’re coming up with activities for a trip.
You’re listing out what you need to do today.
You’re identifying questions you want to ask.
No matter the situation, surfacing everything into a single list creates visibility. Because you can’t solve what you can’t see.
Surface is the first step in Shape Mapping. You start with a list of tasks, ideas, questions. It’s a mixed bag of information. That’s by design.
I categorize the list into five types:
- Action: Something to do.
- Decision: Something to decide.
- Question: Something to answer.
- Risk: Something to watch.
- Unknown: Something to learn.
You can add annotations with emojis or text prefixes to quickly identify the types.
At this stage, it’s a flat list with all the types mixed together. There’s no order. The goal is to write down everything you can think of to build the feature. Nothing is in or out of scope yet. Just keep writing things down.
I keep the list in a place I can add to it over time. And it’s a great exercise to do as a team collaboratively. Leverage the collective intelligence of the team to build the list.
Let’s look at an example.
We’re working on a new feature to let users save settings as named configurations.
This is what the list could look like:
- Save a configuration (name, description)
- Edit a configuration
- Delete a configuration (with confirmation)
- Show the list of configurations
- Show blank slate
- Reset to the default
- Toggle configurations
- Determine account access levels
- Limit the number of configurations?
- Support configurations in data model
Structure
Once you have the list, then you can introduce intentional structure with relationships. The goal is to create clusters where items group together. Structure shows the connections, defining a causal map of the system. When you start with a list before mapping the relationships, you discover the structure instead of inventing it.
There are three steps to Structure:
- Anchor the root nodes.
- Nest the sub-items.
- Link the dependencies.
Taking our list, we can build Structure, looking for relational groupings instead of operational structures. We’ll use simple group names and show any links (→ D shows that this group depends on Group D). Through each step of the process, you add new items. As the fidelity of the list increases, you’ll think of new considerations to add.
Group A (→ D)
- Save a configuration (name, description)
- Edit a configuration
- Delete a configuration (with confirmation)
Group B (→ A)
- Show the list of configurations
- Show blank slate
Group C (→ A)
- Reset to the default
- Toggle configurations
Group D
- New database table
- Migrations
- Determine account access levels
- Limit the number of configurations?
Slice
Structure builds relationships and draws boundaries in the work. Slice is where you convert those structures into independent units of value. Ask yourself:
What can we build and ship entirely independently?
Structure asks what belongs together?
Slice asks what can stand alone?
This is my favorite part of the process—decomposing work and breaking it down into releasable units of value. One of the engineers I work with is brilliant at this. When we meet and discuss the work, they naturally talk in slices of value. They consider not just the technical side, but the user experience. That thinking separates good engineers from great ones. And it’s the type of hard skill required to work effectively with AI and agentic coding. It takes domain knowledge and holistic product understanding to slice up work. The benefit? Smaller scopes of work, reducing complexity and increasing effectiveness in the build process. This applies to humans and AI.
The three steps to Slice are:
- Name the slice.
- Define the boundary.
- Test independence.
When defining slices, make sure you’re considering a usable flow, not just capability.
At this stage, you’re building language and drawing boundaries between the relationships. Each slice is part of the whole body of work, but pulling them apart like this makes it easier to reason about and track progress. Think of it like a territory where you’re drawing lines to demarcate the individual areas, like states within a country or counties in a city.
(1) Management (→ 3)
- Show the list of configurations
- Show blank slate
- Save a configuration (name, description)
- Edit a configuration
- Delete a configuration (with confirmation)
(2) Application (→ 1, 3)
- Toggle configurations
- Reset to the default
(3) Foundation
- New database table
- Migrations
- Determine account access levels
- Limit the number of configurations?
Simplify
Something often missed in product work is the noise generated by too much scope. The more you add, the more you risk losing the value. If you have a hypothesis, you define it within a narrow definition so you can limit variables. I always prefer to ship a small, simple slice of work and then iterate in response to feedback. Everything before someone uses it is an assumption, a guess, a simulation. AI makes it easy to tackle the “it would be cool if…” scope creep, so limiting scope is essential.
Scope is like a weed. It will keep growing unless you proactively manage it.
Simplify means asking yourself:
What is the smallest version of each slice that still delivers value?
Work through this process iteratively. Don’t rush it. This is when you should debate with your team, dig through all the data, and let your intuition guide the process.
In our example, we’re going to simplify in a few different ways. This happens before the build, but you should also simplify as you work through the actual build. Just because agentic coding means a change is just another prompt away doesn’t mean it’s the right path. An increase in code is an increase in complexity—for your codebase and your customers.
Now we’ll do a pass to simplify our slices.
(1) Management (→ 3)
- Show the list of configurations
- ✂️ Basic blank slate (keep it simple on the first pass)
- ✂️ Save a configuration (name only; no description)
- Edit a configuration
- ✂️ Delete a configuration (no confirmation)
(2) Application (→ 1, 3)
- Toggle configurations
- ✂️ No reset to default
(3) Foundation
- ✂️ Basic data model
- ✂️ Basic migrations
- ✂️ Deal with limits later
Sequence
Slice defines the build units—units of work defined as you would build them.
Sequence defines the value units—units of work that deliver real value.
Look at the three slices of Management, Application, and Foundation.
From a user’s perspective, Management without Application doesn’t make sense. You can create and manage the configurations, but you can’t actually toggle them on. The core value of the work is not just to create the configuration, but to enable them as applied settings. One without the other isn’t helping a user realize the value.
Physical products are often bundled together to highlight their value as one unit.
When you need to combine slices to deliver combined value, they become bundles.
To deliver this feature, I would tackle Foundation first. Define the data model and then run a simple migration to stand up the correct database tables. This could be shipped all the way to production, running live while the rest of the work is completed. Management and Application would be built in linear order, but delivered as a single bundle of value.
The Practice
To bring Shape Mapping into agentic coding environments, you need to provide key details to represent the output of the process. I call it the Shape Prompt.
There are five components to the prompt:
- Context: Why this exists.
- Capabilities: What must be possible.
- Behavior: How it works (states, actions, transitions, feedback, constraints).
- Uncertainty: Where AI should think carefully (risks, questions).
- Task: What the AI should produce.
Shape Prompt Template
Feature: [Feature Name]
Context:
[What this feature is, why it exists, and how it fits into the system]
Capabilities:
- [Capability 1]
- [Capability 2]
- [Capability 3]
Behavior:
States:
- [State 1]
- [State 2]
Actions:
- [Action 1]
- [Action 2]
Transitions:
- [Action/Event → Result]
- [Action/Event → Result]
Feedback:
- [What the user sees or experiences]
- [Success, error, loading states]
Constraints:
- [Rule or requirement that must always be true]
- [Validation, limits, system rules]
Uncertainty:
Risks:
- [Potential failure or concern]
- [Edge case or system risk]
Questions:
- [Open question AI should help resolve]
- [Ambiguity or design decision]
Task:
Generate a detailed implementation plan for this feature.
Include:
- system architecture
- data model
- API design (if applicable)
- UI structure
- edge case handling
Shape Prompt Example
Feature: Configuration Management & Application
Context:
Users can save named configurations and apply them to change their settings. This replaces manual adjustment with reusable presets.
Capabilities:
- Create a configuration (name only)
- View a list of configurations
- Toggle configurations on/off
Behavior:
States:
- No configurations (blank slate)
- Configurations available
- Configuration active
Actions:
- Create configuration
- Toggle configuration
Transitions:
- Create → configuration appears in list
- Toggle → configuration becomes active
Feedback:
- Updated list after creation
- Active configuration visibly indicated
Constraints:
- Configuration must have a name
- Only one configuration can be active at a time
Uncertainty:
Risks:
- Users may not understand how configurations affect settings
- Data model may not support future expansion cleanly
Questions:
- Should multiple configurations be active simultaneously?
- How should configurations interact with existing settings?
Task:
Generate a detailed implementation plan including system architecture, data model, API design, UI structure, and edge case handling.
The Throughline
Garbage in, garbage out. This is the mantra for working with AI, but it’s always been true. If you want to deliver something of high-quality value, then you need to engage in high-quality thinking, debate, and intentional iteration. If execution is cheap, then invest the extra money in areas where you can engage your human creativity. Sketch on paper, write lists, and work with your team in all the messy, glorious collaboration.
Shape Mapping helps you work iteratively to define clear constraints to build within. Those constraints fuel value creation and quality refinement.
Surface everything in a single list.
Structure the dependencies and relationships.
Slice the groups into related units of deliverable value.
Simplify the named slices to the smallest unit of value.
Sequence the slices to deliver value in a meaningful way.
Using the Shape Prompt, you can define intentional constraints to work against.
The best processes are iterative and experimental. They aren’t fixed. As AI changes the landscape of building software, the processes should evolve with them. What is and will always be true is engaging critical thinking in order to make clear decisions.
That’s the human part.
Enjoying this issue? Sign up to get weekly insights in your inbox: