19/36 : 🧠 Product Discovery - Inception
Innovation is the ability to see change as an opportunity, not a threat. - Steve Jobs
What is a Lean Inception?
An Inception is a meeting typically dedicated for the majority of a business day to prepare a team to start a new product iteration. Inceptions may also be used to realign on an existing product that has been going on for several months. Ideally a development team can start work on prioritized, concrete and actionable stories the day after the Inception meeting. Sometimes an Inception results in the healthy early discovery that stakeholders and goals for the project are unclear and additional work needs to be done to refine and agree on the shared goals before the team can start working. Achieving clarity and alignment on issues before the team starts is far better than learning this after a team has been working for weeks or longer on work that is later thrown away.
What’s the purpose of inception?
Particularly when a new product or feature set is being introduced, it can be a challenge to ensure that the team and the stakeholders have a shared understanding of what needs to be built. As Rasmusson says in his book,
Assumption of consensus where none exists is what kills most projects
Rasmusson goes on to say that two of the worst things that can (and often do) happen when teams are just getting started on something are when …
People fail to ask the right questions
People don’t have the courage to ask the tough questions
Who should attend the Inception?
Inception attendees should include the core team doing the work and the sponsoring stakeholders or their designates. Typically this will include business, product, development and perhaps other teams like operations and support. It may also include representatives from upstream or downstream teams that are producers or consumers of this teams work. Practically the effectiveness of the meeting starts to diminish when the number of people is over 10 people because there is a lot of group participation and having 20 people all contribute effectively is difficult. If the invitee list is getting too large, the Inception facilitator or project sponsor may ask invitees with the lowest ongoing involvement on the team to have other attendees represent their views in the meeting. Sometimes larger sized Inceptions are unavoidable, but the tradeoff is lower participation from each attendee and the likelihood of lower alignment.
Who needs to be present?
Who needs to be present for an inception session depends on the business context. At a minimum:
The team(s) that would potentially be doing the work
The Product Manager/Product Owner
A neutral facilitator (typically an Agile Coach or Scrum Master)
Note: Depending on the context, it is often wise to ensure that customers or other stakeholders are also present.
Why do a Product Inception?
When it comes to building a new software product, every stakeholder may have a different idea of what an effective solution looks like. At the product inception workshops we gather stakeholders as well as representatives from the design and development team so that we can come up with a unified vision for the product and agree on a road map to take us there.
Save time. Product inception ultimately accelerates time-to-market. With a defined scope and clear priorities, the development team can focus their efforts on creating what delivers the most value to your business. Time won't be wasted on unnecessary features, and the team can minimize the need to rework parts of the solution to truly fit the business need. When everyone is on the same page about what's important, the team can collaborate efficiently on building a high-quality product that achieves the desired outcomes.
Save money. Hand-in-hand with saving time is the ability to reduce costs. Product inception sets you up for a more focused development process in which the team can truly deliver value every sprint. The learnings from a product inception allow developers to better understand your business, which makes them better equipped to tackle challenges with your users and your business interests in mind.
Reduce risks. Product inception enables you to anticipate and prepare for potential challenges. Aligning stakeholders before a single line of code has been written allows you to work out the product's priorities and avoid future headaches and misunderstandings. In addition, product inception provides you with a better understanding of users' goals and journeys, ensuring that your product will truly fulfill their needs.
Build a better product. Ultimately, product inception sets you up to build a more effective and successful product, one that truly addresses the most important opportunities and that will help users achieve their goals. Product inception puts you on track to building a scalable MVP that you can adapt and add to as you collect user data and receive feedback.
Questions for an inception triage
Before planning the inception, I will try to get some context on it. Please find below some questions I use to find more information about the inception context.
What is the culture of the organisation? Siloed? Component teams? Product Teams? Internal teams? External teams?
Is it ok to have a collaborative workshop? Or shall we plan to work isolated and later find out if whatever we came up with is good enough?
What do we want out of this inception?
What happened or is happening, before the inception?
Is there a plan for after the inception? Any dates already defined?
Who are/should be the people actively involved? What are their roles? technical? UX? Business? Other?
Who are the stakeholders (people very interested with the inception result but that cannot be part of it)?
Who is organising it? Is there a draft agenda already?
Who will facilitate it?
Has anyone already sent a “save the date”?
Who will send the invitations?
Will the inception have one facilitator or will it have a shared facilitation style?
Which online board will we use?
Which videoconferencing tool we will use?
Typical Inception Agenda
Introductions - Keep the introductions brief as you will be spending most of the day together as a team and will get to know each other well throughout the day. It can be helpful to have the facilitator prompt each attendee for a few key pieces of information such as who they are and why they are here.
Vision and Goals - The project sponsor and product owner should deliver a succinct long-term vision for the project and indicate what the immediate goals are for the next few months. Allocate time for questions and discussion from the group.
Non-Goals - Just as important as the goals, it is important to explicitly state what are not immediate goals. Often times stating non-goals clearly is a way to constrain scope for the current work stream and give the team permission to deliver value faster by excluding certain things that may be wanted eventually, but not essential to have now. Make sure to allow time for group discussion on non-goals.
Risks - Everyone in the room should identify the main risks for the project using the index cards. Have each person write down one risk per index card using as many cards as they wish. The facilitator should categorize the related risks together in a stack of index cards, reading them off and providing a chance for people to explain the brief definition of the risk they wrote down. This is not the group discussion of each risk yet, this is just to understand what the risk may be. Then the facilitator should instruct everyone to use the candy or props for voting and give each person 3 votes to place on the categories with the highest risk to the team achieving the project goals. You may cast all 3 votes for one category of risk or spread out votes on up to 3 separate categories . After voting the top categories of risk should be discussed with the highest number of votes going first. Note the categorized risk ranking on the whiteboard or with a photo. The team should redo the risks voting exercise at the end of the day and see if anything has changed. It almost always does.
Roles / Personas - The facilitator should conduct a group exercise to identify either the roles or the personas that are involved in the project. I have observed the approach used to elicit the roles or personas vary a lot from simply having the product owner state who they are authoritatively to having the whole group do a brainstorming exercise. They key objective is that everyone on the team understand who the users are.
Activities / Workflows - The facilitator should work with the group to identify the activities or workflows for each of the user roles or personas scoped to the immediate goals of the project. The facilitator should pick an approach that is well-suited for the group dynamic. It can be as simple as asking the product owner to identify the key activities and allowing for group discussion or it can be something more creative like a game. These high level descriptions of how the user interfaces with the system to accomplish something form the basis for project epics and can typically be broken down later into stories. An example of a high-level workflow may be “Bobby the student searches the store catalog for a book, adds the item to his shopping cart, and completes the purchase”.
Stories - If there is time, break the activities and workflows down into smaller, concrete actionable stories. Do not worry about being too precise with the wording. The product owner can refine the language and details later. Sometimes there is not time for this activity during the Inception itself and the higher level activities and workflows are the granularity that must be used for estimation and prioritization. This is okay as it is the product owners job to work with the development team lead to ensure the stories do get written as fast as possible following the Inception.
Estimation - For the most important stories, quickly get a rough estimate from the developers in the room. If you estimate at a story level, try to use the point system and sizes your team will use during development. If you are at an epic, activity or workflow level then try to use a rougher estimate like developer weeks. Martin Fowler’s Thrown Estimate technique is very effective for quickly getting rough estimates. If you have a large number of items to estimate, my colleage Evan Willey recommends the Affinity Estimating. The important result is that client sponsors and the product owner receive estimates directly from the team responsible for the implementation.
Prioritization - Have the product owner put the stories in priority order and allow for group discussion and validation. The product owner should be able to justify the priorities to the team based on business value. Are these features “must-have” for this phase of the project or just “nice-to-have”? See if the estimates based on points can be roughly translated into to project weeks based on the team size. In almost every Inception I have attended, the estimates and priorities indicates the team must cut scope to deliver in several months. Now is a great time to have a discussion about trade-offs with the project sponsors and product owner since they are likely getting semi-accurate estimates from the team accountable for delivering the project for the first time.
Risks - Repeat the risk exercise from before and see if the risks have changed.
Next Steps - Have a group discussion about how the next few days and weeks will play out. This might be used to align and inform everyone on the process the team is going to use going forward for development and checkins. Usually the facilitator and product owner take pictures of the whiteboard, collect the index cards used for exercises, capture action items and agree on who should send out an electronic summary. Occasionally I have seen teams use Inception assets like flip-over sheets, index cards and whiteboard images displayed in the team work area. As time passes, the assets start to get out of date and have less value.
Retrospective - Use an agile retrospective to discuss the Inception meeting itself, what worked, what things people have questions or confusion about, what did not work as well, and any ideas for next time.
Fun - By now everyone is pretty tired from being in a room for most of the day. It’s likely toward the end of the day and it can be good for team to go have some fun outside the office by having an optional gathering somewhere socially. Often times people that were not able to participate in the Inception meeting want to know the outcome and interact with the team, so inviting people that were unable to attend is an option. Keeping this part optional is important for people on the team that need time to decompress.
Additional Inception exercises include:
The elevator pitch. The basic construct here is to arrive at a brief description that could be used to explain the what, why, and how to somebody who knows nothing about it, typically in 60 seconds or less. The Inception Deck referenced below provides a useful template.
Product box. This is a popular exercise in training contexts like the Certified Scrum Product Owner (CSPO) course. The idea is to create basic content (images and text) that would go on a box containing the product. (Whether it would ever actually be a shrink-wrapped product is beside the point; the idea is for the team working on it to be able to describe it in a way that would make sense to a prospective buyer/user.)
Your project community. This conversation focuses on making sure it’s understood who the stakeholders are.
How big is this? A preliminary conversation where the team tries to arrive at how large an effort this is, in comparison with other work they’ve done.
Trade-off sliders. A visual technique that helps reinforce the notion that only ONE thing can be fixed. If there is a deadline, then schedule is fixed; and if there is a must-have feature set, then scope is fixed.
The Team. An initial conversation about who’s on the team. Hopefully all of them are in the room for this conversation ; ).
The first release. It can also be helpful to talk about which feature(s) could potentially be released the earliest.
Inceptions Duration
Inceptions vary in length. I have been on inceptions that last from a few hours to a few weeks. I prefer an inception agenda that fits in a week , from Monday to Friday. But I do recognize the need to plan the inception duration as per your specific context. For example, many times I will start with an agenda template and adjust it.
You should plan each activity duration and be very careful not to under allocate time to it. During each activity, you should plan enough time for the people interaction, not only for the artefact generation. For example, you can build an MVP canvas in 10 minutes and ask everyone to be on mute and follow you. On the other hand, in a more collaborative way, you can plan and facilitate a collaborative session to build the MVP Canvas. It requires more time, probably a few hours, or a fill day.
Be aware (and respectful) of people’s energy level. For example, it is usually better to plan a sequence of 12-hour sessions in three consecutive days than to have it all in one day. Usually, it is more productive and more respectful of people’s energy level and agenda.
Anthony O’Connell created the following graph and explanation to help teams understand and plan the length of a Lean Inception.
SHORTER INCEPTION (less that 3 days): Simple product, small number of features, little or no integration with existing systems
MEDIUM INCEPTION (aprox. 5 days): Medium complexity product, larger number of features, some integration with existing systems
LONGER INCEPTION (more than 5 days): Large, complex product, large number of features, significant integration with existing systems
I like Anthony´s work because it depicts a visual representation to help teams assess their context for deciding the Lean Inception length. You should consider a similar approach for planning your specific inception length.