I always appreciate the opportunity to test and refine the techniques I use with a new team in a new context.
As I write this, I’m in the middle of one of those opportunities and I thought I’d depart from the normal format of the newsletter the next couple of weeks to share some experiences.
This week, I’m sharing how we did an initial discovery period to understand the outcome we’re trying to achieve and build an initial shared understanding of our solution. These activities resulted in a broad (but relatively thin) understanding of our solution that helped us organize our approach to doing deep dive on thin slices of the product as we move into an ongoing delivery/development cycle.
The aim of the current gig is rebuilding an internal product. The product team started with 2 developers, a UX expert, a delivery lead (that’s me acting as the resident product person on the team), and a scrum master. During the course of the discovery period, we added four more developers, a tester, and swapped out our UX experts. We also work with a Product Owner who mainly fulfills a decision making role, and a group of subject matter experts and users.
The team started out the gig with a period of about 3 – 4 weeks where we got familiar with the existing business process and product and clarified our intended outcome.
During that time we held a series of discovery sessions which ranged from 30 minutes – 2 hours where we used a variety of techniques to clarify the outcome and build a shared understanding.
We went this route instead of having a single marathon workshop to avoid undue interruption to our Product Owner and Subject Matter Experts’ schedules and to give the product team a chance to do research and analysis in between the sessions.
Here are the specific discovery sessions we held over the course of that time. For each session, I describe the reason we did that session and the techniques we used.
The purpose of this session was to establish a shared understanding about the outcome that we wanted to deliver and established criteria we use to make decisions about what to include and exclude from the product backlog.
We used the problem statement to guide the outcomes discussion and give everyone on the team an opportunity to describe why they think we’re rebuilding the product and then build a shared understanding of the intended outcome. We didn’t necessarily create a concise problem statement, but everyone involved found the discussion extremely helpful to establish an agreement on our purpose.
The discussion also helped us establish decision filters that we use to build a shared understanding of intent and to guide decisions in a distributed fashion. We came up with three decision filters, two that help us to determine what to include/ not include in the product backlog, and one that helps guide our technical decisions about how we approach the functionality we choose to deliver.
Ideally, we would have also identified 1 – 3 outcome based metrics to quantitatively tell us whether we’ve delivered on our outcome. Since we’re rebuilding the product to reduce manual processes and reduce errors, we’re still trying to determine the best ways to measure those outcomes in a meaningful way. In the meantime, the decision filters provide sufficient guidance to help us make decisions.
The purpose of this session was to identify the interfaces the current product has and may have with outside people, organizations, and/or systems. We used that understanding to determine which interfaces we need to investigate further and account for when rebuilding the product.
We used a context diagram to guide our discussion about interfaces. We identified all the current and potential providers or users of data (external agents) that our product interacts (or may interact) with and noted each with a sticky note.
Then we noted the specific interfaces each external agent has with the system by drawing them on the whiteboard. Using a whiteboard is helpful because you’ll often find yourself writing one thing, and then changing it as you discuss the specifics further.
The interface discussion was one of the first discovery sessions we did. It helped us to determine other discovery sessions we needed and to identify interfaces with external organizations or other groups inside the organization that needed further coordination and posed higher risks.
The context diagram also provided to be a helpful visual aid that I referenced when I onboarded new members to the team.
Business Process Mapping
The purpose of these sessions was to map out the current state business processes related to the product. We took some time to discuss and map out the current state of the business processes and then discuss opportunities for improvement.
We used information obtained during a demo of the existing product and some initial discussions to identify five high-level processes. We then scheduled a separate session to focus on each process. That gave us the opportunity to keep the group discussing any particular process to key individuals.
We used process modeling to help structure the conversations around the various processes. I would ask our subject matter experts to walk through the process, and I would note key steps or decisions with sticky notes on a whiteboard and write arrows in between the sticky notes to indicate a flow.
Using a whiteboard in these situations is key because you’ll often uncover new intermediate steps or have to change part or all of your flow when you ask that one question that uncovers a whole new set of understanding, or a much better idea of the process.
We used these process models to gain a better understanding of the business process in general and to identify key product backlog items. They were also helpful along with the context diagram in getting new team members up to speed.
Risks and Assumptions
The purpose of this session was to identify and categorize the main risks and assumptions facing the rebuild effort and identify how we might address those risks.
We used the risk management game to structure the conversation around risks and provide a structure for identifying, classifying, and prioritizing the risks that we faced.
As a result of this discussion, we were able to identify a set of risks that we needed to address in one way or another. We identified plans to address those risks and the people who were responsible for addressing them. A couple of the largest risks had to deal with external interfaces that were not present in the current system. We chose to start working on those interfaces first to make sure we could address the biggest risks facing the product as soon as we could.
Identify Epics and Features
The purpose of this session was to identify potential epics and features, organize them into priority groups, and identify the first feature to understand in more detail.
To prepare for this session, I took an initial pass at identifying four epics (which roughly mirrored the high-level processes we used to organize our business process discussions) and the corresponding features. I referenced the process models and context diagram to help with this exercise.
The product team then got together and reviewed the epics and features I identified in order to provide clarification, identify features that were needed, or remove features that weren’t needed. The product owner and one of the subject matter experts provided good clarification that also helped to clarify some misunderstandings on our part.
Next, I asked the product owner to gradually the group the features. First, I drew a line on the whiteboard and asked him to place any of the features (represented as sticky notes) below the line that were not needed by our target date. These items we considered as out of scope.
Next, I drew a line above the first and asked the Product Owner to put any features there which were nice to have by our target date.
Finally, I drew a third line and asked the product owner to put any sticky notes above that which represented the most important first things to work on to reduce risks or validate assumptions.
The top group we identified as now, the second group was next, the third group was future, and the fourth group we labeled out of scope. I created a roadmap of sorts to capture those groupings.
This way of grouping the features roughly followed Todd Little’s ABC’s of prioritization, although we didn’t go to the extent of sizing the features at this point.
In between the discovery sessions, we did several other activities to further our understanding of the context, the problem, and our possible solution, as well as to prepare for development activities. Here are some of the main activities.
Because I’m new to the organization and its industry, I spent a bit of time becoming familiar with industry-specific terms and common business practices. This was especially important because one aspect of this product is to help the organization manage how they performed an industry standard process.
To help with this effort, I started a glossary and started collecting industry-specific business rules.
Data Model and Data Dictionary
I also started a data model (via sticky notes and a whiteboard) and a data dictionary (in excel). The data model helped me think through entities, key attributes, and relationships based on information identified during discovery sessions. The data dictionary helped me to start noting metadata about entities and attributes including standard definitions of data elements, their meanings, and allowable values.
I did not attempt to “finish” the data model or data dictionary, rather I wanted to put an initial structure in place that I could build upon as we took a deeper dive into the various features we worked on throughout the course of the effort.
The data model also helps us to split features into smaller product backlog items. I’ll talk more about how we’re using the data dictionary to describe those product backlog items in the next post.
While those activities were going on, the UX expert met with the key users of the existing product and used those discussions to create user profiles. We used these profiles to identify the characteristics of key user groups to establish archetypes that can be used to influence design of the information architecture and user interfaces.
The UX expert also created an information architecture for the product in order to define the overarching structure and relationship between all areas of the product based on information determined during discovery sessions.
Setup Technical Infrastructure
Having developers involved in the discovery sessions from the beginning helped them to build an understanding of the problem we were trying to solve. It also gave the team the opportunity to discuss the problem from a variety of different perspectives and to make sure we were asking pertinent questions in the discovery sessions.
Their early involvement also gave them a head start on getting their development infrastructure setup, with the hopes of hitting the ground running fairly quickly.
Although we were rebuilding an existing product, we were building it on a completely new tech stack, so the time in between discovery sessions was invaluable for the developers to start laying out the architecture and establishing their development environments.
We also used this time to start identifying how we would work together as a team. I’ll talk more about that in the next post
Keeping context in mind
The approach we took in this situation is based on the need to understand a complicated product where the problem is fairly clear, but there is a lot of missing information when it comes to specifics. Not much about the product or processes is documented, so we have to rely on looking at the existing product and discussions with subject matter experts to fill in the gaps.
This approach is well suited for rebuilding an internal product, but may not be as meaningful if you’re working a new product or service that you’re going to sell. We know who our users are. We know what problem we’re trying to solve. We need to find out all of the existing rules and data and figure out ways to make existing processes better and come up with effective ways to support new processes.
Our challenges come from making sure we build a complete understanding of the processes, data and rules we need to care about. We have to make sure we build a product that the existing users will be able to use effectively and that new users can come on board with ease.
If you’ve been in a similar circumstance I’d love to hear about your experiences.