How we do it
1- IDENTIFY THE ACTIVITIES AND EXPECTED OUTCOMES
While detailed activities are highly contextual to each inception, the overall flow and framework will stay loosely the same.
When planning inceptions, we take the blueprint as a starting point, add or remove activities as required and adjust the overall flow for the best-fitting narrative.
We also define outcomes for each activity, so it’s clear as to why a given activity is being conducted and what the focus is on.
The inception agenda blueprint outlines a generic starting point. Alternatively you can use the example schedule.
Pro tips
Inceptions can be run for any type of initiative, not only the digital product or feature builds we focus on in this playbook. In the case of construction, change and transformation initiatives, digital prototypes may need to be physical prototypes, and wireframes of mobile apps might be replaced with sketches of a potential new office space (as an example).
Clearly articulate why you are doing each activity. What are you trying to achieve? What questions need answering? Good inceptions are all about actionable insights and outcomes.
This playbook is focused on inceptions rather than discoveries, which means we’re concerned with building foundations for delivery. Therefore we assume that the rationale for the initiative is sound and articulated (e.g. business case, value proposition, goals). We’ll want to validate and align on this, during inception and pivot to a discovery if we found it lacking.
Taking the rationale for the value proposition as solid doesn’t mean we can’t formulate hypotheses or experiments during inception or subsequent delivery Dependent on the initiative, our inception may result in a very concrete feature list and roadmap, a backlog of experiments, or a mix of both.
Inceptions may be run within a known or new domain, with an existing or new client – all of which will affect the inception activities. Some activities may be skipped. E.g. we’d skip the ways of working if we already have an established team; we’d forgo the detailed analysis if we’re working in a known domain or context (in which case we may focus on validation instead).
Inceptions can be templated and re-used. For one of our clients, we created a generic inception schedule to be run whenever one of their legacy applications was containerised and readied for cloud-deployments.
2- IDENTIFY THE INPUTS NEEDED FOR EACH ACTIVITY
We define the information needed to make each activity a success. We’ve achieved our best results by sharing expectations and knowledge on where the client wants to go and where they are now. We place less importance on preparing extensively on defining or understanding the proposed solution.
The latter can lead to heavy bias and the need to backpedal, which can further frustrate stakeholders who’ve invested time in preparation.
Pro tips
Let’s be honest: stakeholders rarely have the chance to do homework prior to inceptions. They are busy people. In any case, the quality of responses to long lists of questions list is rarely as good as having a face to face chat.
Don’t do too much research. It’s always best to balance primary research with insights and perspectives direct from the client.
Be aware that prepared material is often stale, biased, siloed or counter-agile. It can still provide valuable context and is therefore worth reading through. We often get requirements documents from our clients which we’ll use to prepare and validate against, but often don’t use during the inception.
3- DEFINE HOW TO RUN EACH ACTIVITY
Pro tips
A variety of engagement styles, techniques and tools increases engagement, motivation and attention spans. Move people around, have a mix of sitting and standing activitites, get everyone to contribute to capturing insights on post-its, walls and drawings, etc
Be confident in the tools you use. You can (and should) get scepticism and pushback, so confidently explaining and navigating this will be important. E.g. many, many people intensely dislike energisers - so framing this appropriately or having a variation / alternative will be helpful..
4- DEFINE WHO IS NEEDED
For each activity we identify relevant participants and stakeholders. We focus on cross-disciplinary groups that hold the required knowledge, as well as the authority to make informed decisions.
5- PREPARE ANY MATERIALS YOU WILL NEED FOR EACH ACTIVITY
As with inputs, we are careful to avoid over-preparation (as it leads to bias and impedes collaboration and buyin). We simply ensure we’re prepared to drive discussions and analysis, and usually have a toolkit (of tools, techniques and case studies) we use if we need to swerve and pivot.
Once you have your agenda laid out, you can head right into scheduling and running it.
Pro tips
Focus on the process of the inception, not the solution at the end of it.
Quite often, there’s a limit to how much prep you can do. That’s OK. It’s the inception’s job to tease out and answer questions, collaboratively – not to critique a solution approach you’ve already prepared with limited context.
See Design an inception agenda: deep dive for an in-depth discussion with recommendations of tools and techniques.
Last updated
Was this helpful?