The Domain
UNDERSTAND THE PROBLEM DOMAIN IN SUFFICIENT DETAIL.
As far as inception goals go, we have until now, just set the scene: we’ve understood what the opportunity is, why it exists and where the organisation sees itself in the future.
Now we get into the nitty gritty of our problem. We analyse the problem domain in enough detail to be able to make a decision on: whether we can deliver a desirable, viable and feasible solution; what such a solution could look like; and how we could deliver it.
Note that the individual activities in this step (and their sequencing) very much depend on whether we are building a solution from scratch, or evolving or fixing a solution within an existing domain. In the case of the former ,we start building from a blank slate, for the latter we have to do as-is analysis and build on top of that.
The activities will also be influenced by the ‘type’ of initiative. A product build will need technical analysis in form of technical architecture, while a change initiative may require no technical analysis, or do so in the form of process modelling.
Why
While we believe in an agile approach, we also recognise that we’re most likely to succeed in delivering valuable outcomes when building on solid foundations.
Many inexperienced or misguided teams jump to solutions too early, which are then based on risky or random assumptions and impacted by unknowns and unmanaged risk. While agile ways of working allow us to manage some level of uncertainty, it would be neglectful to do no analysis or preparation at all.
What good looks like
We want a sufficient understanding of the domain so we can outline a solution for the opportunity at hand – and subsequently assess whether it is truly desirable, viable and feasible. We adopt lean principles, which in practice means doing the necessary minimum to learn or achieve specific outcomes: by working breadth over depth and focusing on areas of risk and complexity.
Activities
BUSINESS DOMAIN
What does the organisation do and how do they do it?
We investigate what the business does, how it delivers products, services and value and how it is affected by external factors.
Businesses are often complex organisms, embedded in an even more complex environment. Following systems thinking and domain-driven design, we focus on the smallest relevant subdomain (which may be an entire organisation, a business unit, a department or an individual team). While we want to keep the boundaries of our domain as small as possible to achieve focus, the domain we really need to look at to truly deliver value (to account for all dependencies, risks, design operable solutions etc)
is often a bit bigger than clients may initially believe. Sometimes, also the opposite can hold true: areas highlighted as needing a detailed understanding are not always relevant.
Generally speaking, we look at the business model, the top level value and supply chain, then start identifying stakeholders. From this we can understand how the organisation is embedded into the wider context that affects it.
Recommended tools and techniques
I want to create or understand what the business does and how they operate
While invented to design a business, this is an excellent tool that quickly allows us to model an existing business and identify areas affected by introducing a new system, product or service. We generally use this as our starting point to understand any domain, as it’s a great conversation starter.
I want to understand who I am dealing with
Any successful delivery is based on interactions with people. These people have different roles, interests, agendas; they may be empowered or just there to execute or inform. A stakeholder onion maps stakeholders by degree of closeness, while a stakeholder matrix arranges them on dimensions such as influence vs. interest.
I want to understand how a business delivers products and services and creation and creates value
These older models are timeless, as they provide a clear view of cause-and-effect, identify bottlenecks and areas where we can make improvements. They do however cover just one piece (of the many pieces) of the puzzle, and generally need to be supplemented with other tools to create a fuller picture of the current internal domain.
I want to identify external dependencies of a business or initiative
These are models that facilitate identifying and thinking about external dependencies that affect a business or initiative.
I want to understand strengths, weaknesses, threats and opportunities I can address or exploit
A matrix to note strengths, weaknesses, opportunities and threats, classified by whether they are external, internal, harmful or beneficial. This tool does little to facilitate identifying individual aspects in the first place and is quite limited in leading to strategy – but it can provide some structured thinking around these aspects.
TARGET AUDIENCE
Who is my target audience and what do they find desirable?
We identify users, what they desire and expect from a solution, and where we can provide value to them. It’s important that we recognise internal and external, primary, secondary and supporting users. We must also remember that even the most technical problem ultimately has a ‘user’. Arguably this is the single most important step – ultimately, every bit of value created by or for a business stems from satisfying the needs of users.
By default our thinking should be informed by market and user research, though subsequent experiments and testing the solution will provide the most robust feedback.
Recommended tools and techniques
I want to understand what my target audience needs, and how I can deliver a product that matches those expectations
The value proposition canvas zooms deeper into the alignment of expectations and capabilities.
I want to understand what users really need or desire.
Jobs to be done focuses on the things a user wants to achieve and how they want to do them, and thus is a perfectly user-centric approach to understanding ‘requirements’.
I want to understand my target audience's current experiences.
Empathy maps are a tool to identify and document what users are thinking, saying, hearing and seeing in a given situation(s), allowing us to tailor / optimise solutions to meet these aspects. They’re closely related to the user side of the value proposition canvas, where ‘empathy’ can be mapped to help identify opportunities and issues.
I want to understand and ‘define’ my target audience
User personas express the characteristics of the target audience in the form of a limited group of stereotypical users. These can be used to inform your value proposition and solution design.
I want to understand my target audience, what they desire and how I can ultimately provide value to them
We have a wide range of research tools and techniques at our disposal to understand users and situations, validate assumptions and hypotheses prior to and during design, delivery and actual operation. Research is vital and informative, as long as we’re mindful of its constraints: early user research, especially focus groups and user testing with small sample sizes are indicative at best. Monitoring (e.g. web analytics) and testing (A/B testing) in live use are more reliable, but less exploratory.
STAKEHOLDERS
Who is important in the delivery of this initiative?
In addition to identifying system users, we look at the wider picture of stakeholders that affect, impact or are interested in the initiative. This helps us validate that we have identified all users, be they individuals or organisations that we need to recognise as part of analysis, experiments definition or delivery.
Recommended tools and techniques
I want to understand who I am dealing with
Any successful delivery is based on interactions with people. These people have different roles, interests, agendas; they may be empowered or just there to execute or inform. A stakeholder onion maps stakeholders by degree of closeness, while a stakeholder matrix arranges them on dimensions such as influence vs. interest.
A stakeholder matrix allows you to easily track and communicate who your stakeholders are, their relevance and area of expertise and involvement. When doing this, be careful to consider all relevant users for input into requirements: it’s easy to focus only on the end-user and ignore operations or other important users when designing an application.
EXPERIENCE LIFECYCLE: USERS
What does this user experience look like?
We model how the target audience will be using the solution in the wider context of the customer - or more generic ‘user’ - lifecycle.
To map the user experience across the relevant parts of the customer lifecycle, we identify the flow of activities that relevant users conduct at the various touch points they have with our domain. We also note their experience (emotional, social, functional) at each stage.
Once completed by adding capabilities (see next step) the resulting model(s) is possibly the most important tool we use to understand the domain, communicate context and use as the basis for solution design.
In the case of a brown-field initiative we will usually start modelling the existing experience, then identify gaps, opportunities, strengths, weaknesses and issues and use this to inform our target experience. For a green-field initiative we would model our vision of the target experience.
As before, our thinking should be informed by market and user research, though subsequent experiments and operation of the solution will provide the most robust feedback.
As part of this we start eliciting and engineering wider (business) requirements.
Recommended tools and techniques
I want to understand how my target audience (expects to) interact with the business and its products
User experience maps illustrate users’ interactions across the various touch points they may have with an organisation, and what capabilities are required to support the interaction. We can also map user sentiment and empathy against each touchpoint, which then allows us to link back to our value proposition.
Finally, we can use an experience map to indicate threats and opportunities, areas of risk and improvement on this map.
We use these to map the as-is or to-be state, and communicate areas of recommended focus to a business.
I want to understand how a business delivers services or what will be required to deliver a service
Similar to a user experience map, the service blueprint focuses on the internal workings of an organisation. The information inherent in a user experience map and blueprint can be combined into a single diagram in many cases.
We can use the service blueprint to model the as-is and/or the to-be state.
I want to identify the capabilities and features my system needs to provide
This activity allows us to model a domain by focusing on its ‘events’. We’ve used this successfully to model heavily time-driven domains (for instance, the complex supply chain management system of a UK retailer, where most activities are determined by sales seasons, orders and arrival of stock).
I want to analyse and define processes in more detail.
User Journeys are a detailed illustration of how users interact within a touchpoint, usually from screen to screen. Activity Diagrams are a formal expression of logical flow, usually used to illustrate user interaction or system activities. BPMN is a formalised visual modelling language to document business processes. Value Stream Mapping is a technique that helps to improve processes, following lean paradigms.
I want to understand, analyse and share thoughts about a domain.
A visualisation that illustrates domain concepts. This could be a single complex model, or multiple visualisations showing different aspects. Focus on people and systems, but you can also add data, processes and events.
An example might be a systems landscape, illustrating how the various systems that support a website of an automotive company are linked to each other, or an illustration of the flow of assets, securities and fees for a securities lending project.
A Context Model is a good way to illustrate which areas are in and out of scope of your Initiative.
I want to understand my target audience, what they desire and how I can ultimately provide value to them
We have a wide range of research tools and techniques at our disposal to understand users and situations, validate assumptions and hypotheses prior to and during design, delivery and actual operation. Research is vital and informative, as long as we’re mindful of its constraints: early user research, especially focus groups and user testing with small sample sizes are indicative at best. Monitoring (e.g. web analytics) and testing (A/B testing) in live use are more reliable, but less exploratory.
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to document the non-functional qualities and characteristics of the solution.
Contrary to functional requirements, non-functionals are often well understood and documented. The challenge is to tease out and agree on the specifics, (e.g. number of concurrent users, expected throughput, etc). Where no benchmark exists, in our experience it’s best to put a gut-feel based stake in the ground, and plan for evolutionary architecture and infrastructure to scale and evolve in the future where required, rather than build for scale from day one.
Technical requirements catalogue
I want to document implementation / technology specific requirements of the solution
Technical requirements are often based on existing capabilities, business constraints or preferences. Ultimately these should be workshopped in light of context, industry best practices and requirements. A good way to illustrate the overall scope is to visualise requirements in a tree structure, with themes at the top, and features, epics and stories coming further down the tree in increasing detail. This provides an easy-to-consume overview that allows us to track delivery progress.
I want to understand who I am dealing with
Any successful delivery is based on interactions with people. These people have different roles, interests, agendas; they may be empowered or just there to execute or inform. A stakeholder onion maps stakeholders by degree of closeness, while a stakeholder matrix arranges them on dimensions such as influence vs. interest.
I want to make sure we are all aware, all on the same page and are ready to manage outstanding items
We find that key failure points of projects are often down to misalignment and unmanaged risks. Documenting assumptions, decisions made, issues to be resolved and risks allows us to identify, communicate and manage these items in a controlled manner from day one.
While ultimately we hold these artefacts in an easy to share / collaborative digital format, during workshops we reserve white-board space for each. These are constantly updated as fresh information arises.
It’s vital to recognise that we need to start populating these artefacts on day one, and continue to add / update / manage them throughout the entire Initiative (i.e. not just the Inception).
I want to map dependencies that impact my delivery
A tree or network identifying individual dependencies, their relationships (x depends on y), their status and ownership.
EXPERIENCE LIFECYCLE: CAPABILITIES
What capabilities are needed to support the user experience?
We identify and model which capabilities are required (i.e. features, systems, processes, people, data) to provide the target user experience.
In this activity, we bring together the user-centric view with the business and technology perspectives. We extend the user experience model by mapping existing and required capabilities that support the various user activities. This includes internal processes, relevant internal users, the systems and data captured and/or used. This is the time to also look into aspects of operations and support (i.e. how will the business provide the end-to-end experience from an internal perspective?) Accordingly, we often involve service designers in these activities. In a second step, we can then identify gaps, opportunities for improvement and issues that need addressing.
Dependent on the size of the domain, we may end up with a number of models which focus on different parts of the domain at different levels of granularity.
In addition, we conduct further analysis on the details of these capabilities and any related requirements the organisation may have. This can include (but is not limited to) enterprise / technology architecture, system interfaces and the technology stack, as well as infrastructure, tooling, etc.
We continue to elicit and engineer requirements as they come to light. Note: at this stage we have not yet examined the solution as our focus is still on the as-is domain and solution-neutral requirements. In practice, we will update these models as part of solution design.
Recommended tools and techniques
I want to understand how my target audience (expects to) interact with the business and its products
User experience maps illustrate users’ interactions across the various touch points they may have with an organisation, and what capabilities are required to support the interaction. We can also map user sentiment and empathy against each touchpoint, which then allows us to link back to our value proposition.
Finally, we can use an experience map to indicate threats and opportunities, areas of risk and improvement on this map.
We use these to map the as-is or to-be state, and communicate areas of recommended focus to a business.
I want to understand how a business delivers services or what will be required to deliver a service
Similar to a user experience map, the service blueprint focuses on the internal workings of an organisation. The information inherent in a user experience map and blueprint can be combined into a single diagram in many cases.
We can use the service blueprint to model the as-is and/or the to-be state.
I want to identify the capabilities and features my system needs to provide
This activity allows us to model a domain by focusing on its ‘events’. We’ve used this successfully to model heavily time-driven domains (for instance, the complex supply chain management system of a UK retailer, where most activities are determined by sales seasons, orders and arrival of stock).
I want to understand, analyse and share thoughts about a domain.
A visualisation that illustrates domain concepts. This could be a single complex model, or multiple visualisations showing different aspects. Focus on people and systems, but you can also add data, processes and events.
An example might be a systems landscape, illustrating how the various systems that support a website of an automotive company are linked to each other, or an illustration of the flow of assets, securities and fees for a securities lending project.
A Context Model is a good way to illustrate which areas are in and out of scope of your Initiative.
Architecture outline
I want to model how the various technical components of a system are related to each other.
We use lightweight, low-formality architecture diagrams to analyse, align on and communicate information about the technical domain.
Ultimately this allows us to explore and agree:
Architectural approach
Architectural patterns
Technology choices
It also feeds into team profile and shape, and informs scope, feature and solution design related decisions.
It’s important that we consider this in close conjunction with all other aspects of solution design (UX etc).
I want to document technical details in an industry standard.
A standardised model which can be beneficial to express system behaviour and implementation in a formalistic way. Be mindful with overly early detailed design; analysis paralysis and the overheads to update such models are potential pitfalls here. Working and self- explanatory code is always better than specification.
I want to analyse and define processes in more detail.
User Journeys are a detailed illustration of how users interact within a touchpoint, usually from screen to screen. Activity Diagrams are a formal expression of logical flow, usually used to illustrate user interaction or system activities. BPMN is a formalised visual modelling language to document business processes. Value Stream Mapping is a technique that helps to improve processes, following lean paradigms.
I want to summarise requirements
Where we gather requirements during an inception, they should be user-centric and at Epic level. It’s too early to go down to implementation level at this stage. We generally stay at feature / epic level during inception, only moving to a ranked backlog (Requirements Hierarchy) for prioritisation later in the inception.
I want to understand who I am dealing with
Any successful delivery is based on interactions with people. These people have different roles, interests, agendas; they may be empowered or just there to execute or inform. A stakeholder onion maps stakeholders by degree of closeness, while a stakeholder matrix arranges them on dimensions such as influence vs. interest.
I want to make sure we are all aware, all on the same page and are ready to manage outstanding items
We find that key failure points of projects are often down to misalignment and unmanaged risks. Documenting assumptions, decisions made, issues to be resolved and risks allows us to identify, communicate and manage these items in a controlled manner from day one.
While ultimately we hold these artefacts in an easy to share / collaborative digital format, during workshops we reserve white-board space for each. These are constantly updated as fresh information arises.
It’s vital to recognise that we need to start populating these artefacts on day one, and continue to add / update / manage them throughout the entire Initiative (i.e. not just the Inception).
I want to map dependencies that impact my delivery
A tree or network identifying individual dependencies, their relationships (x depends on y), their status and ownership.
NON FUNCTIONAL REQUIREMENTS
What qualities and characteristics must the solution have?
We elicit and agree expectations towards the non-functional qualities of the solution.
It is vital that we elicit and agree on the non-functional requirements or qualities of our solution early in the process, as this will affect solution design and delivery. We should consider that these will change over time (e.g. expected throughput), so we should allow our system to evolve too – not only functionally, but also in relation to its non-functional characteristics.
Recommended tools and techniques
Non-functional requirements catalogue
I want to document the non-functional qualities and characteristics of the solution.
Contrary to functional requirements, non-functionals are often well understood and documented. The challenge is to tease out and agree on the specifics, (e.g. number of concurrent users, expected throughput, etc). Where no benchmark exists, in our experience it’s best to put a gut-feel based stake in the ground, and plan for evolutionary architecture and infrastructure to scale and evolve in the future where required, rather than build for scale from day one.
HYPOTHESES
Do we believe this will lead to success?
We define what we believe to be valuable ‘experiments’ to run.
Based on our understanding of desirability (what users need), viability (what will contribute to longer term business success) and feasibility (what the business can provide), we define a hypothesis (or potentially several) against which we will build ‘experiments’ to validate our thinking.
Please note that we use the term ‘experiment’ in a very wide sense: an experiment can be something we want to try out, or it can be a feature or broader solution which we actually implement (based on high confidence that it will be valuable) to test and validate during live operation.
At this stage we will have arrived at a list of hypotheses which we prioritise based on associated value (to user and business) and, as far as we can tell at this stage, cost, complexity and risk. We will update these priorities as we come to solution design – when feasibility and viability become more concrete.
Recommended tools and techniques
I want to articulate what am I doing and why, and know when I have been successful
Whether we design and build a totally new product and have to validate whether there is a market at all, deliver a sound value proposition but need to be sure it was done in the right way, or simply want to explore potential opportunities, we are always – often subconsciously – working to a hypothesis. Articulating and formalising this in terms of expected outcomes streamlines our subsequent design and planning and makes sure we’re always focusing on delivering value against strategic goals. Note that a hypothesis or related experiment can be in regards to the solution itself (value, usability) but also to delivery (to validate technical feasibility or an approach or process).
I want to make decisions in the most objective and consistent way
Decision-Making Frameworks are a way to formalise the criteria by which decisions are made, and ensure these are made with strategic goals and outcomes in mind.
We use them for all aspects of decisions, whether they relate to investment, feature design, prioritisation or technology choices.
Do note that such models do not take into account the nuanced contextual factors that are sometimes at play. We need to be careful not to make bad choices by applying inappropriate models.
I want to prioritise items so that I know that to focus on.
We use a range of prioritisation techniques, dependent on context, but generally find that simpler methods work at least as well as complex methods. Humans are good at comparison, but not great at absolute values. A range of biases also play into supposedly more “scientific” decision methods. As such, we advocate for being pragmatic: be data-informed, acknowledging your instinct and biases in parallel.
Pro tips
This is one of the trickiest, yet most vital phases of an inception. Use a wide range and mix of tools, techniques, and let your colleagues lead sessions in their own area of expertise. Keep it relevant, focused and fresh.
When trying to understand a domain, focus on people, process, systems, data and events.
Be careful if presented with detailed specification of existing systems: user requirements move on, system design becomes out of date.
Where requirements documents exist, use them for inception planning, then put them alongside the actual inception activities and compare the outputs you create with them. Highlight and discuss any mismatches. Until proven otherwise, assume that requirements documents created in advance are indicative at best.
Discuss functional requirements early in the process. They always turn out to be more painful to define than expected.
Ensure engagement with all relevant stakeholders in terms of their requirements, expectations and needs. Specifically engage with ‘secondary’ stakeholders such as brand, infosec, compliance, operations and support. Ignore these gatekeepers at your peril.
Start discussions regarding expectations towards technology and infrastructure stack, as well as any other constraints and requirements that infosec or other regulatory departments may throw at you.
Work lean and just-in-time: keep the analysis as light as possible.
The trick, or rather the challenge, is to do enough. Too little, and risk increases; too much, and risk again increases (as there’s greater certainty in unvalidated assumptions) and you will also be compromising lean values and will incur waste. Stay at epic level.
Initially, think slightly bigger. Often the business will tell you to ‘focus on the task at hand and don’t worry about bigger concerns’. But it’s these bigger concerns (for instance, the business going for an IPO), or what’s happening just outside of your domain that will put things into perspective or flag important dependencies.
Use tools and techniques that drive insight and provide actionable outcomes. Many old-school MBA tools don’t do that. Use them in a way to drive a shared understanding or actionable outcomes.
Last updated