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

Image for post
Image for post
The BLP Demo helps user-focused discovery grow in both old and new organizations

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.

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.

Image for post
Image for post

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.

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.

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

Image for post
Image for post
The Shutterstock Editor team showed text outlining during the Built section of a BLP Demo

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.

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.

Image for post
Image for post
The three parts of the BLP Demo

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!

Image for post
Image for post
Image for post
Image for post

Agile Insider

Exclusive & practical insights about rapidly delivering value.

Sign up for All Things Agile

By Agile Insider

The best of Agile Insider delivered to your inbox Take a look.

By signing up, you will create a Medium account if you don’t already have one. Review our Privacy Policy for more information about our privacy practices.

Check your inbox
Medium sent you an email at to complete your subscription.

Holly Hester-Reilly

Written by

Founder and CEO of H2R Product Science, where we teach you how to use science and empathy to build high-growth products. Learn more at H2Rproductscience.com

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Holly Hester-Reilly

Written by

Founder and CEO of H2R Product Science, where we teach you how to use science and empathy to build high-growth products. Learn more at H2Rproductscience.com

Agile Insider

Exclusive and practical insights that enable the agile community to succeed.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store