Make Time for Product Discovery

One of the most common questions that comes up after teams complete a Lean UX or product discovery training engagement with us, “How will we find the time to do this and deliver work?” Their rationale reflects the velocity-driven demands put on them by their stakeholders. The measure of value in these organizations (and let’s be honest, these are the majority of cases) is shipping software to production regardless of whether that software actually delivers any value to its users. I’ve written before that writing code is just one part of the work of building digital products but in this article I want to get specific about how to ensure there’s time for discovery work in every initiative.?

Start Each Sprint Planning With a Different Question

The standard question at the beginning of each iteration planning meeting is, “What are we going to build?” If you start the conversation focused on outcomes you’ll end up with a backlog filled with delivery stories. Instead, start the planning meeting with, “What is the most important thing we need to learn this sprint?” This instantly shifts the focus of the meeting away from creating output and puts it on the risky assumptions in our work. As the team works together to brainstorm the risks that could break their progress or success at each given moment, they begin to objectively question the items in their backlog. Once “the riskiest” item is identified the natural segue is, “What do we need to do to de-risk this assumption?”

De-risking assumptions is product discovery work. Once the team is discussing these activities it stands a much greater chance of adding these items to the backlog for this next iteration. Framing each sprint as a learning opportunity means discovery work becomes a regular part of the team’s planning process.?

Create a New Story Type: Experiment

Product discovery work often struggles to get prioritized because there isn’t a specific story type or backlog item to reflect this type of work. If we want to ensure product discovery takes place in a sprint we need to provide a vehicle for its visualization. Enter the experiment story. This is a story type dedicated to product discovery. It captures:

• The hypothesis we are testing
• The specific assumption we believe is risky
• The type of experiment (aka product discovery activity) we plan on running
• Who is going to do this work
• And (if we’re estimating) a sense of scope for this work

Every other type of work has a story card. If we truly believe product discovery is “real work” (and it is) then it too needs to be visualized the same way as all the other types.?

One Backlog for All Story Types

The final piece of this puzzle is the backlog. If we’re going to write experiment stories then they need to be first class citizens of the backlog where the other stories live. To be super clear here: if you want product discovery work to be included in each sprint it has to live in the same backlog as the delivery work. As soon as you create separate backlogs for separate story types you put the team in an impossible situation: which backlog to pull work from each morning when they get to work. Inevitably one backlog becomes the default and the rest get abandoned. In my experience the one that gets abandoned is the one that doesn’t have delivery work on it.?

By prioritizing all of our work in the same place the team is forced to decide how much of their time will be spent on delivery work as well as discovery work. In addition it forces a conversation about when the discovery work needs to get done in order to inform the delivery work. Finally, this technique makes it crystal clear who will be doing the discovery work which means they will NOT be working on other things at the same time. The finite timebox of a sprint enforces a maximum amount of work the team can do. By defining it in a single backlog we ensure that discovery work is always a part of this process.?

No Silver Bullets

None of these tips are silver bullets to getting product discovery prioritized on your teams. The thing that makes these effective is organizational will. There has to be a desire to do this work and a level of support from your stakeholders to allow discovery work to take place. Putting these 3 techniques into practice will begin the conversation about ensuring discovery has time allotted in every sprint. It will also reveal where this work will struggle to see the light of day. It’s these gaps and organizational hurdles that can then be escalated to your leaders for further support.?