Making Business Rules Visible With Example Mapping

While working on a global pricing platform at G-P, I encountered a problem whose difficulty came less from the technology than from the business it needed to represent. Before we could decide what the platform should do, we had to understand how pricing worked across countries, teams, and the exceptions that had accumulated over time.

The company was operating across more than 187 countries, helping businesses employ people internationally through an Employer of Record (EOR) model. Pricing had originally been supported through pricebooks within the Salesforce CPQ (configure, price, quote) system. That approach could support the business at an earlier stage, but international expansion introduced a much larger collection of variables that pricing needed to represent accurately and change as the business evolved.

Employing someone in one country could involve different employer costs, social contributions, compliance requirements, payment infrastructure, currencies, local service providers, and operational accommodations than employing someone somewhere else. Those differences could affect pricing, quoting, billing, and the adjustments finance teams eventually needed to make.

We weren't simply replacing a pricebook. We needed to understand the rules represented by that pricebook, the operational processes around it, and the people doing the work, including knowledge that wasn't documented in one place. Making that knowledge explicit gave us a better basis for deciding what belonged in the new platform. Cucumber Example Mapping helped us work through it together.

Meet the business where it operates

I partnered closely with an excellent engineering team to understand how pricing actually worked across the business. Rather than beginning with the assumption that we already knew what the pricing engine should be, we worked through the pricing journey from initial price calculation and quote generation through billing and the manual adjustments that sometimes occurred later.

Following the full journey mattered because a pricing system can look correct at the point where a quote is generated while still creating problems downstream. If finance routinely needs to correct something during billing, that adjustment is evidence worth understanding. If an operations team maintains a workaround because a particular country behaves differently, that workaround may contain a business rule. If a local service provider requires a different payment arrangement, that can affect the cost structure and how the system needs to represent it.

We wanted the platform to reflect how the business actually operated, including the exceptions and accommodations that had accumulated as it expanded. That didn't mean reproducing every historical workaround. Understanding why each existed helped us distinguish necessary operating rules from limitations of the previous system.

That work eventually became a rules-based pricing engine. Before we could build those rules into a platform, however, we needed a practical way for product, engineering, finance, operations, and other subject-matter experts to develop a shared understanding of what the rules actually were.

Example Mapping turns rules into a conversation

Example Mapping is commonly associated with Cucumber and behavior-driven development, an approach that uses concrete examples to describe how software should behave. You don't need to practice BDD or use Cucumber to benefit from the underlying technique.

Example Mapping gives a group a structured way to discuss rules, examples, and questions. I find it useful because creating the map requires people to turn abstract assumptions into situations they can inspect together, so the discussion produces value beyond the documentation.

Imagine that we begin with a hypothetical pricing rule:

Rule: Employees hired in Country A require a 10% employer social contribution.

That sounds clear enough to document as a requirement, but it may not be clear enough to build into a pricing platform. We can start testing our understanding with examples:

The one where an employee earns 40,000 in local currency and the applicable employer contribution is 4,000.

Then we introduce a different situation:

The one where an employee earns 100,000, but contributions are capped after the first 80,000, making the applicable contribution 8,000.

Another example might introduce compensation that is treated differently:

The one where the employee receives base salary plus a bonus, and the bonus follows a different contribution rule.

These are illustrative examples rather than actual G-P pricing rules, but they show why the technique is useful. A statement that initially appeared to describe one straightforward rule has already raised questions about caps, compensation types, thresholds, and how the calculation should behave under different conditions.

"The one where..." makes abstract rules easier to inspect

One approachable way Example Mapping is sometimes discussed is through the naming convention used for episodes of Friends: "The One Where..." The phrasing works well for discovery because it pushes a group to describe something that actually happens instead of continuing to discuss a requirement in the abstract.

A broad requirement such as:

The pricing engine must support country-specific employer costs.

might instead become a series of situations:

The one where the employee is hired in Country A and the employer must pay a percentage-based social contribution.

The one where that contribution stops increasing after compensation reaches a statutory threshold.

The one where Country B requires both a percentage-based contribution and a fixed employer cost.

The one where the local service provider introduces an additional cost because payroll must be distributed through a particular channel.

The one where a regulatory change takes effect while an employee is already active.

Each example gives people with different knowledge of the business something concrete to react to. A regional specialist may point out that an assumed rule doesn't apply in a particular country. Finance may identify how a calculation eventually appears during billing. Engineering may see that two apparently different examples can be represented by the same underlying rule, while operations may recognize an exception the rest of the group hasn't encountered.

Finding disagreement at this stage gives the team a chance to resolve different interpretations before one becomes part of the platform.

Examples show where a rule needs more definition

Concrete examples tend to surface questions that a broad requirement leaves unanswered. In the hypothetical social-contribution example, we'd need to understand whether the percentage applies to all compensation, whether there's a minimum or maximum, when the rate changes, whether a threshold is annual or per payroll period, and what happens when someone starts partway through a year.

Those questions can lead to additional rules or reveal that the original rule was incomplete. They can also expose circumstances where the organization itself hasn't yet established a consistent answer.

That uncertainty exists whether or not it appears in a requirements document. Capturing a question makes it visible enough for the right people to resolve it; otherwise, software can formalize an assumption that was never actually a business rule.

For a global pricing platform, an unanswered question might require input from finance, legal, operations, a regional expert, or someone managing a local service provider relationship. In other cases, the discussion may reveal that there's no single global rule. The team then has a product decision to make: standardize the process, support multiple variations, make something configurable, or deliberately leave a particular judgment with a person.

Downstream work can reveal rules too

Following the pricing journey beyond the initial quote helped us examine manual billing adjustments before assuming they should be eliminated. We needed to understand why they happened, because manual work can indicate either a system limitation or an accommodation the business still needs.

Some adjustments can represent inefficiency or limitations in an existing system. Others may be evidence of legitimate business conditions that the primary pricing model doesn't yet represent. Treating both categories the same can result in automating the wrong behavior or removing flexibility the business still needs.

Looking at pricing, quoting, billing, and adjustments together helped us understand where the existing model diverged from what ultimately needed to happen. Example Mapping gave us a useful structure for turning those discoveries into rules, examples, and open questions that could be discussed across the team.

Understanding the reason for an exception gave us a basis for deciding what the platform should do with it, rather than making every exception permanent.

Shared understanding matters more than the map

A completed Example Map can be useful documentation, but I think its greater value is the shared understanding developed while creating it.

No single person necessarily holds all the knowledge a complex platform needs to represent. Product may understand the intended outcome and customer journey, while engineering recognizes patterns and implementation constraints. Finance knows what needs to appear on an invoice, operations sees the exceptions in daily work, and regional specialists understand the conditions that make one market behave differently from another.

A concrete example gives those perspectives something to work through together. Rather than asking everyone to agree with a broad requirement, the group can examine specific situations and figure out whether the same rule explains them.

That was particularly important for a platform supporting operations across more than 187 countries. New software wasn't going to make the underlying complexity disappear. We needed to understand which complexity belonged in the platform, which could be represented through reusable rules, which needed configuration, and where human judgment or operational flexibility still mattered.

The technique is useful beyond software requirements

Although Example Mapping comes from the software development world, the underlying approach is useful anywhere a process depends on operating rules and exceptions. Pricing models are one example, but the same conversations can help clarify eligibility rules, approval workflows, billing policies, permissions, routing logic, scheduling, customer onboarding, service delivery, and automation.

A nonprofit, for example, might use the technique to explore eligibility for a program. A service business could use it to understand how leads should be routed. A team building an automation could use it to identify when a workflow should proceed automatically and when a person should take over.

The starting point remains fairly simple: identify the rule, describe a concrete example where it applies, find another example that tests the boundaries of the rule, and capture the questions the group can't yet answer. As the examples become more specific, the operating model becomes easier to inspect.

That doesn't mean every question needs to become another software rule. Some questions may reveal a policy decision, a process problem, missing data, or a situation that should remain intentionally flexible. The technique helps make those distinctions visible before implementation narrows the available choices.

Understand the examples before building the rules

There's natural pressure to move from a problem to requirements and then into implementation. When a platform needs to represent rules developed across teams, markets, and years of operating experience, spending more time understanding those rules can help the team make a better decision about what to build.

Example Mapping helped us have those conversations while developing the pricing platform at G-P. We moved from broad requirements toward concrete situations that product, engineering, and business teams could examine together, which also showed us what we didn't yet understand.

Start with a rule, describe an example, then find another example that challenges your understanding and capture the questions that emerge. Bring in the people who know the parts of the business you don't.

The goal is not a perfect map. It's enough shared understanding to make better decisions about what the system should actually do.

I learned about example mapping here: https://cucumber.io/blog/bdd/example-mapping-introduction/