Outside-in Domain Landscape Discovery

--

Mapping out your business’s domain landscape has many benefits: knowledge sharing, generating product ideas, providing the foundation for software architecture, aligning on requirements, but a common challenge is… “where do we start?”

There’s a pretty endless list of techniques to choose from and an unlimited combination of ways in which they can be applied. Discovery feels more of an art than a science. However, I find myself gravitating towards an outside-in approach most of the time.

An outside-in approach starts with the business model, the user needs, and step-by-step zooms into the inner-workings of domains. I like this approach because it’s value-driven and it fits with my style of thinking and facilitation skills. You may find that other approaches work better for you, and in reality every workshop is different so you need to be flexible.

The following steps are my baseline format for a series of discovery workshops. When working with a new client, I always spend some time understanding the problem and challenges before designing a series of workshops. But this baseline gives me confidence that I’ve always got a reliable starting point to work from or fall back to.

Q: What is a domain landscape?

A: Your business’s domain landscape is its landscape organised into conceptual areas of interest. At Google, search and advertising may be two of the major domains of interest in their landscape. Wardley Mapping is one way to learn and visualise a business’s landscape.

Step 1: Find the Value Exchange

In Escaping the Build Trap, Melissa Perri talks about the system of value exchange. This is the first part of the landscape I try to get a grasp of; what value exchange is taking place?

Businesses create products or services to solve the problems, needs, or wants of customers. The customers only realise the value when the problems are solved, the wants are realised, and the needs are met. Then they give value to the companies in return, in the form of money or data.

— Melissa Perri

The Business Model Canvas is still my goto technique. The Customer Segments and Value Propositions sections represent the value that a business creates for its customers. The other sections of the canvas, including Key Activities, Key Resources, and Revenue Streams tell the story of how the business creates and monetises value.

The Business Model Canvas can be applied from the level of an entire organisation down to individual products or even features. The scope of the workshop will influence how many levels is necessary.

Step 2: People, Personas, and Roles

A system of value creation and exchange involves people, each with their own purpose, responsibilities, and jobs to be done. There are a few reasons why I find it useful to map them out and keep their needs in mind throughout the discovery and design process:

  • It’s an engaging warm up activity that everybody can contribute to before getting into the mechanics of a domain
  • It helps to think broadly about all of the people involved so that parts of the landscape or particular roles aren’t neglected during the discovery process
  • Just the act of describing the different roles can lead to valuable domain insights which influence the discovery initiative (e.g. where to start, gaps in knowledge, important people missing from the workshop)
A small extract of the domain roles identified during a workshop (the above are not 100% accurate, they have been obfuscated to protect confidentiality)

Step 3: Experiences, Journeys and Value Streams

An outside-in approach focuses on the perspective of the customer or user receiving value before exploring how the business creates the value. This can be achieved by mapping out the user journeys and high-level value streams.

If existing user/customer journey maps have already been produced, they can provide a great starting point. Although something simpler is often good enough. Most of the time you can capture the 5–10 high-level steps in a user journey marked out along a timeline as milestones. This is what we want to end up with anyway for subsequent steps.

An extract of a user journey showing key/high-level milestones

Q: Is there a risk to using existing documentation, e.g existing customer journey maps?

A: There is always the risk that existing documentation is not up to date or reflects the perspective of a single person. The opposite can also be problematic too: starting from a blank canvas can alienate the workshop attendees if they feel time is being wasted on something that has already been done.

This is a tricky problem for facilitators. I can’t think of any simple solutions. Timeboxing and frequent, short retrospectives are valuable so that you can try things (e.g. start from a blank canvas) but detect quickly if engagement and satisfaction are low.

Protip: try to identify before the workshop if existing documentation exists so that you have time to review and prepare.

Mapping out user journeys, even at a high-level, is far more difficult than it looks, especially in some domains; steps may not always occur in the same order, some steps may be optional, there can be a high level of overlap between the steps of multiple users so the perspective from a single user is largely incomplete and misleading.

Experiment and see what feels right as a starting point, and continuously review as you uncover more of the domain. You can map out journeys from individual user perspectives or you can combine them into single value streams using a different colour to represent the steps of different users.

Q: What if the high-level structure is wrong?

A: It depends what you mean by wrong. The high-level structure is not design structure (e.g. business, software, teams), it’s discovery structure. It exists to help you map out the landscape which you then use to identify design structures (see: searching for domain boundaries).

Step 4: Outlining the Landscape

A principal objective of discovery is uncovering important information. But we don’t know where all of the important information is hiding. We can increase our chances by outlining the landscape and highlighting key areas of interest. Seeing the big picture then helps to decide where to zoom in and explore.

Having an overview of the entire landscape reminds us which parts have been explored and which parts haven’t. It’s incredibly easy to get laser-focused on certain areas of the domain, bike-shedding hotspots, and spend large amounts of time discussing irrelevant topics like user log-in. Keeping the big picture visible reminds us how much we don’t know, helping us to better manage time and focus.

Initially, the landscape will be the high-level journeys loosely-organised. They can be combined into larger timelines or just placed on the Miro board using your artistic talents.

When working remotely, tools like Miro are powerful for laying out a whole landscape and visualising the progress made. It’s also good to keep copy and paste the landscape at each step.

Step 5: Zooming In on Value

The landscape outline give us a broad understanding. Getting into the details, however, is usually where the big discoveries happen.

When looking at a large landscape, analysis paralysis can easily kick in. There is so much of the landscape to explore, where should we zoom into first?

One of the techniques I use frequently (I probably over use it) is working backwards from value exchange. For example, “at what point does value exchange from the customer to the business occur” or more specifically “when is a payment made by the customer or a commitment to pay?”.

This information is recorded using a domain event. For example: 3 Month Subscription Purchased. The initial event is then added to the landscape at the appropriate place.

The initial event (a value exchange event) is added to the landscape approximately where it occurs. In this example, a seller signs up when they receive inquiries during the free trial period.

Q: Is value exchange always the best place to start?

A: Not necessarily. It’s a sensible default I gravitate towards when more obvious alternatives do not arise. The best place to start will depend on the goals of the workshops, who is present, and other factors.

It’s also possible to use chaotic modelling techniques (popularised by EventStorming), where everybody in the workshop is free to add domain events anywhere they want to.

Value exchange could happen in multiple places, and it’s worth exploring a few. For example, Renewed 12 Month Subscription may be a better starting point if the business model is focused on long-term subscriptions with a high customer lifetime value.

You can also map out some of the negative value events and explore ways to mitigate or prevent them. For example Subscription Terminated or Subscription Not Renewed.

Step 6: Fleshing out the Landscape

After adding the initial domain event the real magic can begin. More domain events can be added to visualise the domain as a timeline. There are an infinite number of ways this can be done, from chaotic modelling to mob modelling.

After identifying where value is exchanged from customer to business, I like to work backwards and find the next closest event that enables the value exchange, for example “what is the thing that happens immediately before that leads to the customer signing up for the 3 month subscription?”.

In the previous example, the customer signed up for the 3 month subscription after receiving leads. They signed up because they wanted more. It’s now clear that in order for the business to receive value from the customer (the subscription) the value it needs to provide to the user is providing good leads via inquiries. This should tie up with the business model canvas, but it’s worth revisiting to ensure.

Mapping out the domain working backwards using EventStorming’s domain events notation

From this point on, there is no set plan for fleshing out the domain. You can continue to work backwards, move forward, move to other parts of the landscape…Alberto Brandolini’s Introducing EventStorming is my top reading recommendation if you want to learn more.

Q: Is it necessary to complete step 3 & 4 (mapping out journeys & value streams) before starting step 5 & 6?

A: No. It’s not necessary at all. In fact, as you zoom in you will uncover insights that change your perspective of the higher level details. Be concerned if you are not switching between high and low level details fairly frequently.

I do like to get a sense of the size and shape of the landscape before zooming in, but sometimes it’s more valuable to zoom in on whats important and focus there before trying to visualise the whole landscape.

Step 7: Searching for Domain Boundaries

Breaking up the landscape into areas (aka domains and subdomains) becomes possible as more of the domain is explored. I find that the more details added when fleshing out the domain (e.g. domain events) the better the domain boundaries will be leading to a better design of business architecture, software architecture, and team topologies.

Domain events organised into domains and subdomains.

Q: How do we find good domain boundaries?

A: No simple answer unfortunately. This is quite a big topic. Check out my presentations and articles. If you still have any questions feel free to contact me or leave a comment.

Continuous Discovery & Design

Good discovery increases your chances of good design. Mapping out your domain landscape effectively is a key part of architecting your business, your software, and your teams.

In reality, the lines between discovery and design are quite blurry. I think it’s healthy to be thinking about design as we discover (up to a point) and thinking about discovery as we design. Design isn’t a phase that happens after discovery.

Perhaps the most important aspect of discovery is embedding it in your culture and making it a continuous activity for leaders and for makers. Unfortunately, making continuous design & discovery part of your engineering culture cannot be achieved in a single workshop. With that being said, engaging and productive workshops can definitely be a very strong catalyst so I hope this article helps you to think of ways you can improve your domain discovery workshops.

--

--

Nick Tune
Strategy, Architecture, Continuous Delivery, and DDD

Principal Consultant @ Empathy Software and author of Architecture Modernization (Manning)