Having aligned on the overall goals and identified expectations, requirements and constraints, we can now head into defining the solution. Depending on the type of initiative, it may be conceptual or quite concrete. It may be defined in terms of concrete features and functions, actions for change, or defined as ‘experiments’ to explore and validate. Ultimately, we’re seeking to define the concrete things we need to do to achieve the given goals in the most reliable way.
Dependent on initiative, the different types of areas, business architecture, product and user experience, technology and infrastructure will differ in focus.
If time allows, user research and other prototyping / technical exploratory activities could be built in to de-risk and validate thinking at this early stage.
At the end of this phase, you will want to know what the solution would look like to users, but also what’s ‘under the hood’.
In this phase we define the most appropriate solution option, taking into account desirability, feasibility and viability.
We lay the groundwork for the feature roadmap, delivery plan and subsequent delivery.
We want to devise a solution with sufficient detail so that we can demonstrate and assess its value (desirability) and feasibility, and conduct subsequent planning for implementation and viability assessment. This will often mean staying with Epics and indicative user experience or service design for the time being.
What features will the solution have?
We specify the overall shape of the solution (usually top-level features and functions) in light of the target user experience. At this early stage we keep this at Epic level, using mockups rather than detailed designs.
What the solution will look like and how it will be realised
We identify solution options and specify and ‘design’ the solution at top level, from user, business and technical perspectives (covering experience, service design, architecture and infrastructure).
At this stage we may refine wireframes, create visual designs, draft architecture, agree on the tech stack, define the infrastructure and the path to production, as well as define operational and support capabilities. It’s very important that we provide a design that works across the entire business and for all stakeholders.
‘Working for all stakeholders’ doesn’t mean there won’t be any changes on the part of stakeholders or their teams: but rather that we will work together to codesign the changes needed to work for the business as a whole.
Which solution option will we go with?
Based on desirability (value), feasibility (context) and viability (constraints and business goals) we choose the most appropriate solution option.
Either the solution was defined before the inception, or defining the solution is a goal of the inception. In the former case we will want to validate the solution (and flush it out in more detail). For the latter, we need to determine the most appropriate solution design and how to deliver this. Note that a final decision may not be possible until much later, when we have an idea of not only value but also cost.
Factors impacting this decision include device (desktop vs mobile), hosting (AWS vs Azure) or delivery choices (build, lease, buy).
The choice is to be made in context of objectives, business capabilities, constraints and total cost of ownership.
What will we do first?
Based on business goals, milestones, roadmap and dependencies, we identify ‘release’ goals, and which features and capabilities are in each release.
Dependent on the type of initiative, we may have to break down an existing system into manageable parts, divide target scope in a meaningful way, or simply prioritise desirable features.
When doing so we need to recognise value, cost, constraints, ‘fit’ and risks. We may find that the subsequent estimation exercise will require us to revisit and refine our earlier prioritisation.