It is important to enlist an experienced group facilitator that can impartially lead the meeting. This person’s ability to be an efficient master of ceremonies is extremely important. They are responsible for working through the agenda efficiently, ensuring the team is communicating effectively, sensing areas where the team should deep-dive for awhile, and figuring out which conversations that are going on too long should be paused so they can be worked out later with a smaller group.
See also: EqualExperts Inception Playbook
Inceptions typically run for 1-2 full days. This is difficult to manage with remote teams and across multiple timelines.
This doc breaks down each of the activities in a way that they can be run as standalone sessions over multiple days.
The goal of an Inception, and of each Activity, is to achieve alignment on a product. Sometimes people will have vastly different pictures in their heads of what should be accomplished. The plan is to get everyone on the same page.
The Activities start from a very high level and by the end we should have "zoomed into" the individual tasks which we will have to complete to accomplish the Product Goals. The result at the end of all Activities should be a near fully-stocked backlog with stories all engineers would feel confident picking up immediately.
An Inception facilitator must be completely neutral and not involved with the project in any way: you should have no skin in the game. If that is not you, try to find someone else.
- Pre-Inception/Activity Preparation
- Leading the Inception activities
- Activity Breakdown
- Additional Notes and Minutes
- Send out calendar invitations to all involved
- Set up a Miro board
- Instruct everyone to join the Inception meetings from a quiet location.
- Ensure Product Owners (and whomever else) are aware of the sort of information they are expected to provide.
- Ensure all participants are aware that they are supposed to be heavily involved in the activities
- 10 mins before start, ensure all have a Miro account and have full access to the Inception board
- Set out the rules (eg mute when not speaking; no talking over others; all distractions away/muted)
The biggest bit of preparation is information. None of the activities will work if participants do not have enough information to hold in-depth discussions. Before any Inception activity is even suggested, it is presumed that the following has been accomplished:
- Product research and discovery
- User research
- A series of validation spikes
- One or more high-level technical design doc and review
- A high level product feature specification or Feature Narrative
If all participants have not had time to thoroughly read and understand all material around the product, then any Inception activities must be pushed back.
The core engineering team, the product manager and any major stakeholders.
Stakeholders include:
- Clients
- These can be internal (another team consuming the api) or external
- Product people
- Sales people
- Marketing people
- Other upstream or downstream team representatives
- Support teams
Attendees should be limited to around 10, since group participation becomes harder after that point.
Ensure that whoever you do invite knows why they are there and what is expected of them.
If a sponsor or stakeholder cannot make the time to attend this single important meeting yet still wants to heavily influence or control the project decisions, then that is a signal that the team may not get the support and attention it needs and deserves both now and in the future.
While preparation is key to an Inception, there is only so much you can anticipate without biasing yourself. Conversations in an Inception have to grow fluidly, while also staying on track.
Inceptions are really hard to Facilitate, some much harder than others. Recruiting a buddy/deputy to help is a good idea.
Since facilitating is hard, it is generally a bad idea for a stakeholder (who will also want to actively participate the discussion) in the project to take this role. Wearing both hats will mean struggling to fulfill either roles difficult. A Facilitator should therefore be someone who has zero skin in the game.
Here are some principles/tips to bear in mind:
- When you start each Inception Activity, recap the outcomes of the previous Activity, confirm the expected outcomes and how the upcoming Activity will be run.
- Ensure participants understand why they are there, and what value they will get out of it, and what they are expected to provide (Inceptions are a team sport! There are no free rides!).
- Balance attendees meeting their own needs (to vent, be heard, etc) with moving forwards on the topics at hand.
- Reinforce the rules of engagement (e.g. if someone breaks the rules of engagement, point to the rule being broken and confirm whether the group still signs up to this).
- Stay on track. Summarise decisions, insights and outcomes. Write them down. Park topics that are not relevant right now, explain why, and note them down for future revisiting. Park and revisit whenever you’re going round in circles, can’t make a decision, or where a stakeholder hijacks a session.
- Note down assumptions, risks, dependencies and actions. Assign owners to Actions to ensure they get done.
- Keep momentum going, but also provide space to think and reflect.
- Read the room and make suggestions based on what you observe (breaks, focused break-out discussions, revisit topic another day, involve (different) experts or decision makers in future sessions).
- At regular intervals, play back outcomes, insights and confirm the next session/activity
- Throughout the Stage, you are continually building up a picture of the current context and potential future state. To make the knowledge count, tie in what you learn in each subsequent session/activity to the work done before (e.g. when talking about a feature, you can refer back to a specific pain point raised a day earlier).
- Take notes of the dynamics you’re observing, where you think there might be un-addressed (or taboo!) topics and risks; raise these with the group so the problem(s) can be addressed.
- Be flexible with your agenda: you’ll find some of your assumptions to be incorrect, and there might be some fundamental conversations or alignment needed among the people in the room. Be comfortable with updating your agenda accordingly.
- Direct proceedings and show leadership, but allow everyone else to participate – especially the quiet ones, who will often make high-value contributions when given space to do so. If you notice someone has not spoken much, invite them to do so (ensure they know it is fine to say "I don't know" so they don't feel pressured if they feel insecure.)
- Try not to push your own opinions or agenda. Your purpose is to keep the conversation of others moving, so try to talk as little as possible and encourage all the other participants to do so by asking targeted and succinct questions.
- Don't forget to record sessions!
- Remember to let people take regular scheduled breaks (5-10 minutes every hour). Make sure they are back on time. If you sense people flagging, throw in some extra 5 min breaks.
- If running remotely, take even more breaks and make sure people get up and move around. Remote inceptions are way more exhausting than in-person ones.
- Again for remote inceptions: try to ensure everyone uses the best remote presence technology available such as high quality microphones and stand-alone video cameras
Timebox: 15 mins
At the start of each activity, introduce everyone to the session and what will be happening.
- Ensure everyone can access the whiteboard
- If there are new people, or if not everyone is known to everyone else, get each attendee to introduce themselves and explain their role and expertise.
- Explain what an Inception...
- Is - A method of onboarding engineers and achieving consensus on a project. They should feel free to ask questions, challenge the design, and establishing purpose collaboratively.
- Is Not - A lecture from anyone on what the design should be, although those who have been involved in spikes may naturally steer the process towards their plan. The key thing is that Engineers can question/dispute it. (Of course there are Product requirements which cannot be ignored. For the most part the "how" is flexible. Other stakeholders are present to enforce Product requirements... but engineers should still ask why.)
- Explain what the Inception (or Activity) Goals are
- Walk through the Agenda
- Explain the Rules
- Explain the Parking Lot
- Explain the Glossary
- Explain Known Unknowns
- Explain that Inception Activities only work if everyone gives their full attention and participation: everyone is here for a reason, their input is essential and valued
- Understand that if the Inception feels hard going then one of 4 things has happened:
- The Inception was rushed - it happened too soon without sufficient preparation
- Solved by rescheduling to give people more time to read all the things
- The format is not correct
- Solved by reconsidering and rescheduling
- The Facilitator is not properly trained
- Solved by finding a better one
- Discovery for the Project was not properly executed (ie nobody knows if this is the correct thing to do)
- Solved by [whoever is in charge of this] returning to square one, Inception rescheduled
- Not enough people on the team are sufficiently informed to be able to conduct an intelligent conversation
- Solved by rescheduling for 1-2 weeks later, with lots of learning in the meantime
- Key players necessary to the process do not attend for the full duration OR do not participate fully
- Solved by explaining the benefits, getting feedback on what would make it work for them, accomplishing buy-in
- The Inception was rushed - it happened too soon without sufficient preparation
Timebox: 30 to 60 mins
This is a group exercise which aims to drive out a succinct explanation for the product's existence. It should answer the questions: "what problem are we trying to solve?" as well as "how is this different from anything else?".
The exercise is also useful in that it can reveal contradicting assumptions of the product's purpose (some people's ideas may differ from others') and therefore provides alignment and clarity around a single, true motivation.
A Product Manager should present (in stunningly simple language, from the perspective of an eventual customer):
- What this Product needs to achieve
- Where it fits into the company Product vision
All attendees should be able to ask questions and demand clarification until they are satisfied with the answer.
At certain points, ask an individual person what they think the Project purpose is*. If the others do not agree with their summary, the Product Manager needs to try again. Everyone should be on the same page.
Use the following template to drive out idiot-proof language (this is a rough format, re-frame and alter language as necessary):
For [final client/end user],
who would like [a certain service to solve a problem they are experiencing],
the [name of the product]
is a [product category]
which [key-benefits, reason to use/buy it].
Different from [competition alternative],
our product [key-difference].
- Each participant will use sticky notes to fill in the gaps and form the statement which makes sense to them. It will look messy with a lot of mixed ideas, but that is fine.
- Afterwards the facilitator will lead a discussion around all the "versions of the world", gradually discarding notes until there is only one version remaining.
Don't forget to fill out the Glossary as you go.
* Make it clear that their knowledge isn't being tested, but rather this is to check that the explanation is good enough.
Timebox: 30-60 mins
Everyone works together to determine the (current) scope of the Product.
Goals are within the current scope, Non-Goals are not in this scope but may end up in future ones.
There is no such thing as "nice-to-haves": it is either in or out.
If attendees are struggling, it may help to prompt along the lines of "The Product is/is not, does/does not". Ask the Participants to, in simple words/sentences, determine:
- What is this product?
- What is this product not?
- What does this product do?
- What does this product not do?
- What will this product never do?
Remember these are user-facing things: discourage talks about implementation.
- All participants spend 5 mins (timed) independently adding sticky-notes to both columns, stating is in scope and what is not.
- The Facilitator then goes through each of the Goals one by one
- Duplicate/similar sounding Goals should be grouped together and maybe re-worded to snappily convey intent
- The Product Owner should verify whether each suggested Goal is in scope, BUT
- The Engineers can argue if they disagree
- Any misplaced Goals are moved into Non-Goals
- The Facilitator then goes through each of the Goals one by one; are they correctly placed?
Timebox: 30-60 mins
The Facilitator draws a 2x2 grid. The ‘Y' axis runs from “Low Risk” up to “High Risk”. The 'X’ axis runs from “Easy to Fix” to “Hard to Fix”.
Participants (working independently) use post-its write down everything which could get in the way of fully accomplishing the Goals and add place them on the grid. (Stick to things which are likely to impact the product: all AWS data centres simultaneously exploding is unlikely.)
The Facilitator leads a discussion on how the risks in the top right quadrant can be mitigated, should they arise, placing different coloured sticky-notes next to the risk to summarise possible mitigations.
Don't forget to use the 'Known Unknowns' and 'Parking Lot' sections.
If there ends up being more Risks in the top-right quadrant than there is time for, a cheeky trick is to move the axes up and to the right. The Engineers may be sad that they can't discuss everything... but they will live.
If there ends up being a relatively small number of Risks overall, then all / more quadrants can be discussed.
Timebox: 30-60 mins
Everyone works together (the Facilitator types/asks leading questions, participants discuss and direct) to establish a list of the people or entities which will interact with the finished project.
These are not necessarily human and can be any of the following:
- customers
- app developers?
- platform deployers?
- etc
- internal developers
- other internal teams
- is someone/something consuming metrics?
- is someone/something expecting an API?
- any 3rd party entities
To arrive at a concrete User/Actor/Persona we can use the following template:
- Who are they? How have they come to use this product?
- What characteristics of the Actor are relevant to the design?
- What is their background and expertise?
- What are their needs/goals and pain-points?
- How and when would they use the product?
Timebox: 30-60 mins
This section is for establishing high-level flows for each Persona. ie: What should a user be able to do, and what should they expected the outcome to be once they have done it.
Another term for this is establishing Contracts: our project will end up fulfilling them.
Format A: Everyone works together (the Facilitator types/asks leading questions, participants discuss and direct) to establish High-Level Actor expectations/actions.
Format B: Participants are split into groups (evenly distributed skillsets) and are assigned a Persona each. They set out the High-Level user need (lite-epics) for their persona. Afterwards, everyone comes back together and the Facilitator leads a discussion through the stories for each group.
- Some of the Goals may already be full Activities, you can just transcribe these over.
- Some of the Activities may end up small enough to be directly translatable to Tasks.
- Some of these Tasks may end up small enough to be directly translatable to Stories. Others will need to be broken down further in Story Mapping.
- There will be some overlap of Activities between Actors (eg they may fulfill those of another). This is fine, the Activities still need to be acknowledged.
High level activity / user need example:
Actor: A hungry person.
Activity: As a person who is hungry, I can go to This Awesome Cafe and order a sandwich.
Timebox: 60-90, can take longer
Story Mapping is the toughest and most time consuming section. If the other sections felt like pulling teeth, this one feels like pulling teeth one-handed. Maybe you even have some fingers missing.
Format A: Everyone works together (the Facilitator types/asks leading questions, participants discuss and direct) to break down the Activities into stories.
Format B: Participants are split into groups (evenly distributed skillsets) and are assigned a Persona each. They break down into stories for their own Persona. Afterwards, everyone comes back together and the Facilitator leads a discussion through the stories for each group, removing dupes.
Using our cafe example from earlier:
Actor: A hungry person.
Activity: As a person who is hungry, I can go to This Awesome Cafe and order a sandwich.
Stories:
- I can see a menu
- I can give someone my order / choose what I want
- I can pay for my order
- I can receive my order
- etc etc
These may need further breaking down if engineers wish:
Actor: A hungry person.
Activity: As a person who is hungry, I can go to This Awesome Cafe and order a sandwich.
Stories:
- I can see a menu
Tasks:
- Items can be added/removed to/from that Menu
- Items are displayed somewhere
- etc etc
The Facilitator then leads the team into organising the stories into a prioritised list. Drag the stickies around and build a mock backlog.
Timebox: 30 mins
Quickly run through the Risks and Goals, making sure all are covered in the stories.
Timebox: whatever
Head over to the Parking Lot and check if folks want to discuss. Can things be handled now? Or do some things need their own spin-off meeting?
You can also do this section at the end of each Activity if you have broken them down across multiple sessions.
Timebox: 30-60 mins
The last stage of the Inception is the retro. This is crucial for obtaining feedback and improving on the process. Attendees can write about anything, but Facilitators should specifically request feedback on the following points:
- Did the Inception work for you? What did you get out of it?
- Did it meet expectations? Or not? In what way?
- Was there an Activity you felt was not needed?
- Was there an Activity you felt was okay, but needs tweaking?
- Was there an Activity you wish had been included?
- What did you think of the overall format and flows?
- Was there anyone whose skills you missed who should have been invited?
- Did you think the various stages were separated logically? Is there any you would think better re-ordered?
- How was the length of the sessions for you? Were there enough breaks?
- Remote inceptions are hard, do you feel you were able to participate fully? What could be done to improve the remote experience?
Get them to initial their cards.
The Product Manager fills in the backlog with the stories. The Facilitator should not be needed here, but may want to be available just in case.
The Engineering team then points the stories in the next planning. Again the Facilitator should not be needed here, but may want to be available just in case.
The Facilitator may want to re-watch the recordings of the sessions and transcribe any questions, things of note, etc. which did not make it onto the board during the session.
These can be added to the Miro Board which should be made available to all in the company who wish to see.
Optionally the Facilitator may wish to create a summary in a googledoc.