Product leaders, educate your stakeholders by adding this one thing to your sprints

This post originally appeared in Agile Insider on Medium on Jun 14, 2017.

Many product teams struggle to dedicate enough time and resources to discovery and experimentation amidst the pressure to ship new features. I’ve found that a key to developing continuous discovery and delivery practices— sometimes called dual-track agile — is to master the simple practice of hosting a “Built-Learned-Planning Demo” (BLP Demo).

In short, the BLP is a demonstration that gets integrated into your sprint cycle and emphasizes the value and takeaways from doing customer development.

It’s designed for your agile cadence and can help you nurture your user-focused practices to grow strong amongst the challenges of a growing company or the organizational inertia of a large organization.

How do you do a Built-Learned-Planning Demo?

A good BLP Demo includes three sections: what we built, what we learned, and what we’re planning. I’ll review each briefly.

What we built: Most teams already do this as part of their agile process. But in case your company’s sprint reviews need some new life, I suggest that teams pick a few of their most interesting developments and be sure to describe what user problem they were trying to solve in addition to what was built.

What we learned: This section can include updates from any team member. Engineers might describe results of a research spike or proof of concept prototype. Designers might share learnings such as usability test results or user interviews. Product managers might share product insights such as updates on the competition, new data on product usage, or results of customer discovery research. Having a place in the demo for updates from non-engineering roles also builds the team’s understanding of each other’s contributions, helping to develop a cohesive team of diverse perspectives.

What we’re planning: In this section, we share some things we’re planning, connecting it to our learnings. This might include architecture plans, UX designs, product or UX research, or roadmap updates. As we share next steps at the same cadence that our engineers deliver software, we build understanding of how product decisions are made and what valuable product discovery is happening. This also helps us develop trust with our stakeholders, so that they can attach to something other than a feature schedule.

Why is a Built-Learned-Planning demo a good way to drive change?

Because the principles behind the ceremonies used in agile software development can be used for agile discovery too. Even better, expanding familiar practices to include the agile discovery work can make these changes easier for agile development organizations to adopt. As Ken Rubin, author of Essential Scrum, explains it,

“The goal of the sprint review is to inspect and adapt the product that is being built.”

By covering not just what we built but also what we are planning, we are ensuring that both tracks of our dual-track agile software development are inspected and adapted regularly. By sharing what we learned and how we’ve updated our plans accordingly, we can keep our stakeholders up to date, coaching them to value learning as well as delivery and to trust our teams to decide their most impactful next steps. Over time, they will come to look forward to the insights as much or more than the demos of built software.

The Built-Learned-Planning Demo at work for the Shutterstock Editor team

For example, consider some highlights from a BLP Demo we did when I led the Workflow Group at Shutterstock.

During the Built section, the Shutterstock Editor team showed the addition of the outline functionality for the text tool. Instead of just showing that we built an outline tool, we described the problem — when users add text on top of an image, it can be hard to read the text if the image has lots of color variation. Because we were developing iteratively, we wanted to develop the simplest solution. After exploring the feasibility of both outline and dropshadow effects, we started with the solution that we could get to market most quickly. After this explanation, our engineers demo’ed the outline functionality. Instead of getting a “that’s neat, but so what?” reaction, our stakeholders were able to understand what value the functionality delivered and why we’d chosen the scope that we did.

During the Learned section, one update was usage data on a feature over time, highlighting how the usage changed after we rolled out a UX update. Sharing lessons such as this on how a UX change drove increased usage of a feature helped to shift stakeholder’s conversations from output to outcomes.

For the Planning section, the workflow team, which was in charge of features on the core site that support and enable customer workflow, shared a high level look at ethnographic research plans to dive into the experiences of a target set of customers. This moved the conversation to how we would flesh out details on the initiatives we were exploring for future sprints and gave us a chance for early feedback on our plans.

These highlights of a BLP Demo from my time at Shutterstock illustrates how the simple practice of adding product discovery to the sprint review pushes the team and stakeholders to add a focus on measurable outcomes and lessons learned to the usual cycle of shipping code.

Get your own Built-Learned-Planning Demo started quickly

Here’s a template that I use to get a team started on these Built-Learned-Planning Demos. Feel free to copy and edit it for your own uses.

If you are a team member, try working this into your team’s practice. If you are a leader, try putting support in place to encourage this on your teams, and hold them accountable to produce and share learnings every sprint. This will plant the seeds for your organization’s continuous discovery practice to grow.

At young companies, practicing this will help you scale without losing your customer focus. At existing companies, these teams can become the impetus for cultural change that drives innovation.

As with any process change, you need to try it for a few cycles and iterate to figure out what works best in your organization. Then please let me know how it’s working for you and what challenges you’ve encountered along the way!