# Build Your First Map

Build your first map in one session.

Keep it narrow. One user. One outcome. One business problem.

Read the visuals from top to bottom for visibility.

Read them from left to right for maturity.

{% hint style="info" %}
**Legend:** Top = user visibility. Bottom = supporting dependency. Left = novel. Right = standard.
{% endhint %}

{% stepper %}
{% step %}

### Pick one outcome

Write the outcome in one sentence.

Use this format:

`[User] needs to [result] with [limited resources].`

Example:

`Independent sellers need to get paid within 24 hours with limited admin time.`

This works because it ties one user, one result, and one real constraint.
{% endstep %}

{% step %}

### List the capabilities

Ask one question:

`What must exist for that outcome to happen?`

Keep going until you reach shared services and utilities.

Example capabilities:

* Seller onboarding
* Payout visibility
* Checkout
* Fraud checks
* Ledger
* Payout orchestration
* Bank connectivity
* Notifications
* Support operations
  {% endstep %}

{% step %}

### Arrange them by dependency

Put the user outcome at the top.

Place user-facing capabilities closer to it.

Place supporting capabilities farther away.

If capability B is needed for capability A, B goes lower in the chain.
{% endstep %}

{% step %}

### Place each capability by maturity

Ask how common each capability is in the market.

* Novel means uncertain and changing fast.
* Emerging means patterns are forming.
* Proven means repeatable products exist.
* Standard means it behaves like a utility.

Use evidence, not preference.

#### This is how your first map looks

* Read the map from top to bottom to see dependency.
* Read it from left to right to see market maturity.
* Capabilities near the top matter most to the user outcome.

<figure><img src="https://3898048178-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpcYGzPrHr3PqLnjWf6js%2Fuploads%2FO4lafB9c3IaTE0OVC2Nv%2Fimage.png?alt=media&#x26;token=dd77c0f0-0b3b-4189-9352-03a2f12acde1" alt=""><figcaption><p>Fig 1. Wardley Map of Payout Strategy</p></figcaption></figure>
{% endstep %}

{% step %}

### Choose the moves

<table data-header-hidden data-full-width="true"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Stage</strong></td><td><strong>Move</strong></td></tr><tr><td>Novel<br>(Genesis)</td><td>Observe / Experiment</td></tr><tr><td>Emerging<br>(Custom-Built)</td><td>Observe / Build / In-house Development</td></tr><tr><td>Proven<br>(Product/Rental)</td><td>Buy / Partner</td></tr><tr><td>Standard (Commodity/Utility)</td><td>Outsource / Automate</td></tr></tbody></table>

For each important capability, decide one move:

* Build
* Buy
* Partner
* Automate
* Observe

Then rank moves by impact on the user outcome.

<table data-full-width="true"><thead><tr><th>Capability</th><th>Move</th></tr></thead><tbody><tr><td>Seller onboarding</td><td>BUILD</td></tr><tr><td>Payout orchestration</td><td>BUILD</td></tr><tr><td>Checkout</td><td>PARTNER</td></tr><tr><td>Bank connectivity</td><td>PARTNER</td></tr><tr><td>Fraud checks</td><td>BUY</td></tr><tr><td>Payout visibility</td><td>BUY</td></tr><tr><td>Ledger</td><td>BUY</td></tr><tr><td>Notifications</td><td>AUTOMATE</td></tr><tr><td>Support operations</td><td>AUTOMATE</td></tr></tbody></table>

#### Your first map with moves

* Read each move as a decision for that capability.
* Compare the move with the capability's maturity on the map.
* Build where advantage matters. Buy, partner, or automate where the market is mature.

<figure><img src="https://3898048178-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FpcYGzPrHr3PqLnjWf6js%2Fuploads%2FM4qYXIoceaHY7Kclnv4H%2Fimage.png?alt=media&#x26;token=a3c49e5b-11d3-472c-8646-99a7841ca56b" alt=""><figcaption><p>Fig 2. Wardley Map of Payout Strategy, with Moves.</p></figcaption></figure>
{% endstep %}

{% step %}

### Document the decisions

Payout rules may deserve custom work.\
\
Bank connectivity likely does not.\
\
Seller visibility may be a differentiator.\
\
Commodity infrastructure should be standardized and purchased.

Use this section to record the reason behind each move.

Match each capability to its stage and execution choice.

#### Stage 1: Genesis (Novel)

*High uncertainty, high potential for future differentiation.*

* **None currently identified.**

  *Strategic Notes:*

  * All your current "Build" items have moved into the Custom-Built stage, suggesting your core value proposition is now in the execution and refinement phase rather than pure invention.
  * Sometimes, experimenting with novel ideas in-house is counterproductive and loss-making venture.

#### Stage 2: Custom-Built (Emerging)

*Unstable, constantly changing, and built in-house to create competitive advantage.*

* **Seller Onboarding (BUILD):** Custom workflows to reduce friction for new merchants.
* **Payout Orchestration (BUILD):** The complex internal logic that manages the 24-hour cycle across multiple providers.

#### Stage 3: Product / Rental (Proven)

*Increasingly stable, forming a market, characterized by feature competition.*

* **Checkout (PARTNER):** Leveraging external payment gateways to handle consumer-facing transactions.
* **Bank Connectivity (PARTNER):** Using API aggregators or direct partner links to bridge the gap between your ledger and the banking system.
* **Payout Visibility (BUY):** Payment gateway that provides transparency to sellers.
* **Fraud Checks (BUY/Product):** Utilizing industry-standard risk assessment tools.
* **Ledger (BUY/Product):** Standardized financial record-keeping software.

#### Stage 4: Commodity (Standard)

*Highly standardized, low unit cost, high volume, and critical for operations.*

* **Notifications (AUTOMATE):** Standardized SMS/Email delivery (e.g., SendGrid, Twilio).
* **Support Operations (AUTOMATE):** Automated ticketing and self-service bots to handle high-volume, low-complexity queries.
  {% endstep %}

{% step %}

### Strategic Alignment

<table data-header-hidden data-full-width="true"><thead><tr><th>Stage</th><th>Characteristics</th><th>Your Focus</th></tr></thead><tbody><tr><td><strong>Genesis</strong></td><td>Experiment</td><td><strong>Avoid</strong></td></tr><tr><td><strong>Custom-Built</strong></td><td>Differentiate</td><td><strong>Engineering Moat:</strong> Onboarding &#x26; Orchestration</td></tr><tr><td><strong>Product</strong></td><td>Optimize</td><td><strong>Partnerships:</strong> Connectivity &#x26; Checkout</td></tr><tr><td><strong>Commodity</strong></td><td>Efficiency</td><td><strong>Cost Reduction:</strong> Support &#x26; Messaging</td></tr></tbody></table>
{% endstep %}

{% step %}

### Final check

* [ ] One user is named.
* [ ] One outcome is clear.
* [ ] Capabilities are linked by dependency.
* [ ] Each capability is placed by market maturity.
* [ ] Each key capability has a move.
* [ ] The team agrees on what to build, buy, partner, or automate.
* [ ] A review date is set.
  {% endstep %}
  {% endstepper %}

### Related pages

* [Define the Outcome](https://docs.theoutcomeminds.com/framework/editor)
* [Identify the Chain](https://docs.theoutcomeminds.com/framework/markdown)
* [Note the Stage](https://docs.theoutcomeminds.com/framework/images-and-media)
* [Decide the Play](https://docs.theoutcomeminds.com/framework/interactive-blocks)

{% hint style="info" %}
The shape matters more than perfect placement.

Get the first draft down fast.

Refine it with evidence and conversations with team.
{% endhint %}

<sub>Wardley Mapping is provided courtesy of Simon Wardley, CC BY-SA 4.0.</sub>