By Nick Butler
Tags: Agile
Product discovery starts with an idea. It might be yours, a colleague’s or come from customer feedback. You might be creating software or something else entirely. Your customers may be internal, external or a mix of both. Either way, as Product Owner it’s your baby.
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
This post in our Product Owner primer shows how you can find out if the idea has real value, and how to realise maximum value if it does.
To do this you come up with your:
As you go, remember the ABC of Agile: Always Be Capturing. Record the results and artifacts of your product discovery work. You’ll want to refer back to them when you’re building the product. Make them visible. Share them with your stakeholders, it’s a great way to keep them in the loop.
Product discovery involves both the business and the builders, stakeholders and the Scrum Team. Like most team sports, it’s OK to sub in and out. Not everyone needs to be involved all the time.
The stakeholders with a stake in product discovery are:
You can learn more about these different types of stakeholders here.
The more you involve the development team in product discovery, the better they understand and are invested in the product. That’s because there’s nothing like face-to-face time with customers to get a direct and in-depth understanding of what they need.
Sometimes it can be hard to have all the Scrum Team involved in all the discovery work. If, for example, you’re partnering with a development company you might not be able to get the Scrum Team along the whole time.
In this case you could do a Google Design Sprint with your discovery stakeholders and then do a one-day Kick-off (we cover the Google Sprint and Kick-off below). You can also do the work to understand your customers before Kick-off and tackle the prototyping and testing in your early development Sprints. Or there’s the middle ground option. You can bring in one or two members of the development team for the Google Sprint or the prototyping and customer research phases.
Discovery doesn’t end when development begins. As you deliver each Increment you get new opportunities to learn about what your customers need. So you can think of discovery and development as intersecting cycles that feed into each other.
Sometimes you may need a burst of product discovery work. This is obviously the case with a new product. And sometimes an existing product needs a shake-up to keep it competitive.
With some projects, time, money and team schedules mean you want to complete your discovery work in a concentrated burst. With this in mind, we’ve created the Agile Project Kick-off Kit.
This one-day product discovery workshop helps you:
Learn more about the Agile project kick-off meeting toolkit. We’ve also distilled the kit into one 18-minute read: The discovery workshop made simple — your step-by-step guide.
If you’re based in New Zealand, Boost can plan and facilitate your discovery workshop for you. Contact us to learn more.
For projects that meet certain criteria, we can provide these services at no cost.
Is my project eligible for a free discovery workshop?
The Product Vision explains why you’re building the product.
It describes how your product will make the world a better place, showing how it will help your customers and achieve the strategic goals of your organisation. This provides both a destination and inspiration. It helps get stakeholders and the Scrum Team behind the product.
In our Kick-off kit we do this via a Vision Presentation. This then gets fleshed out along with the Strategy through the Amazon Press Release and Elevator Pitch exercises.
Getting one of your head honchos to present the vision shows the C-suite are behind the project and takes advantage of their experience communicating why work is important.
You can show how your product will help achieve the goals of your organisation by using the language of your overall strategy, and tying it back to what matters to your stakeholders. For example, Life Education Trust were building a system to help them make a fundamental, mission-critical change in the way they worked. The key stakeholders were their educators, a change-averse set of internal customers.
“The key word in our vision is empowerment. We are trying to give kids the knowledge to make their own decisions about their health and wellbeing,” says Jess Limbrick, Product Owner for the work.
“We had to let them know why we needed to make the change, why it was going to be better, why it delivered a better outcome for kids. Because that’s ultimately why educators are with us.”
You can sum up your Vision in a one-page Product Vision Board. Roman Pichler has a nice simple vision board.
Your Strategy is the way you’ll achieve your Vision by giving a set of customers something they need that they can’t get elsewhere.
In other words it wraps up and defines your:
To do this we create:
It always pays to keep tabs on your competitors. But this is especially important as you develop your Strategy. You need to understand the market your product will be entering.
In order to get clear what value is and prioritise work that delivers this value, you have to measure how well you’re doing: you need to choose your key metrics.
At Boost we use a single metric that we call One Number. Having a single target is great for communicating with stakeholders. We put it up on a big screen, so it can demonstrate what’s been achieved and build buy-in.
Jess Limbrick from Life Education found it effective. “It was clear, concise and easy to keep our focus narrowed to achieving a key performance indicator. The live number was visible to the whole team which helped with buy-in.”
Places like Google, Facebook and EBay go for between two and six metrics, using something called OKRs — Objectives and Key Results. These follow this pattern:
For example:
Here’s Google’s guide to OKRs.
To maximise the value you create, set yourself an ambitious target.
You can sum all this up on an Opportunity Canvas like this one from Jeff Patton.
Sometimes the outline, if not the detail, of your product is self-evident. But often there are a number of ways you can achieve your Vision and implement your Strategy.
Prototyping is a way to test that the assumptions you’ve made about your customers and your product in your Strategy are correct, without the cost of building the full product.
Early on there’s much you don’t know. Is there in fact an opportunity and, if so, what solution will make the most of it?
You can work this out by combining ideas from Design Thinking and Lean. You:
(In Design Thinking these steps are called: Empathise, Define, Ideate, Prototype and Test.)
You can do some or all of this before your first Sprint or in your early Sprints.
One of the most well-supported ways of doing this is the Google Design Sprint (it’s different to the Scrum Sprint but has the same Agile underpinning). The Google Sprint is a tried-and-tested, tightly-structured five-day process for creating and testing solutions. To find out how to run a Google Sprint, check out:
If you can’t get a team together for five solid days, we cover how you can achieve the same goals over a longer term below. Even if you’re not using a Google Sprint, you can pick up good tips on how to come up with and test solutions by reading the book or our guide.
If you and your product discovery team don’t already have a good understanding of your customers, here are places to look and approaches to try:
These activities give you a detailed insight into your customers that you can use to create your Personas.
For Life Education, Jess says that talking to their internal customers face-to-face got results.
“We knew that face-to-face we would be able to answer a whole lot more of their questions and gauge their reactions,” she says.
Usability testing and interviews are face-to-face and one-on-one. Often you’ll combine the two. If you can put people at ease and dig into their needs and experiences in a conversational way, these two approaches can give you great insights.
To find out how to do usability testing, read Steve “Don’t Make Me Think” Krug’s classic Rocket Surgery Made Easy. And you can get tips on making an interview feel like a conversation here.
Any time you have contact with customers, it’s worth asking if they’re happy to help you later. For example, if you run an online survey, why not ask participants if you can contact them later for user research. It’s a good way of building up a customer research mailing list.
Define the people your solution will help and the problem you’ll solve for them. Following the formula set out by Design Thinking pioneers Stanford d.school can help with this:
How can we help [type of customer]
To [accomplish some goal or perform some activity]
When [What makes it hard? What makes it rewarding?]
Note down the assumptions you’ve made in defining this problem so you can test them later.
Consider multiple solutions to solve your customers’ problems. Your first solution may not be the best. You’re after idea-generation techniques that:
That’s why Post-it notes are your friend. One good way to gather a group’s ideas uses Post-its to create an affinity map. It’s a 5S process:
Here are some other approaches.
Once you have a set of solutions, pick the best. Using the designated decider and structured voting from the Google Sprint can help you come up with quick, focussed decisions. Check our Google Sprint guide to see how this works.
Create the simplest prototypes you can to test the assumptions most likely to scupper your solutions. These assumptions might be about your customers, your solution or your business environment. One way of digging into assumptions is to think about risks. What could go wrong that would make the product a failure?
Identify the riskiest assumptions and test these first. For instance, if your target customers don’t have the problem you think they do, there’s no point in testing whether your product solves it.
Start with the simplest, lowest-fidelity prototype you need to test these assumptions. That way you haven’t put in unnecessary effort if your solution fails the test. In the Sprint book they recommend using a presentation package like Keynote or PowerPoint to create basic, clickable prototypes.
In Rocket Surgery Made Easy, Steve Krug shows how to test prototypes at different levels of fidelity, from paper napkin sketches through to working products. Here are a couple of other simple techniques for early prototypes:
Rocket Surgery also covers how to recruit test subjects. If you’ve already collected a mailing list of customers who have agreed to help, you’re off to a flying start.
You, the Scrum Team and your discovery stakeholders should watch the tests together. Seeing is believing and nothing better demonstrates the gap between our expectations and how customers actually use our products than watching them in action.
Jess from Life Education has started working on a new, public-facing product for kids. Testing the interactive InVision prototype threw up plenty of surprises.
“Some of the things that I thought that might not be obvious were. Then there were some other things that I thought were obvious that weren’t,” Jess says.
Test in pairs. That way one can concentrate on building a rapport with the test subject, the other on taking notes. Everyone else can watch via video conferencing.
Meet straight after watching the test and agree on your actions.
Feed what you learn about your customers into your next prototype, or your Minimum Viable Product.
To get to the point you can start building your product you need to map out how your customers will use it and prioritise the minimum features needed to make this experience worthwhile: your Minimum Viable Product.
User Story Mapping guides you to the point that you can start writing user stories and gives you a visual chart showing the structure of your stories. These stories and this structure will guide your development work.
A user story is a short description of something your customer will do when using your product. The user story is written:
Because the user story is written in language anyone can understand, and focuses on the customer and the benefit they get, it’s a useful tool for communicating with stakeholders. It’s clear why you’re doing the work.
You can find out more about writing effective user stories here. In our next post we also go into more detail about how Product Owners can get the most from user stories in Scrum.
Getting your early MVP in front of your customers is great but you can’t rely on them to give you feedback unprompted, as Jess from Life Education discovered.
“We probably overestimated the likelihood of the educators telling us that something didn’t work,” says Jess. “It wasn’t until we had more directed conversations that stuff really started coming up.”
To find out how to run usability tests on your product once you have a working Increment, see Krug’s Rocket Surgery Made Easy.
Once you have a set of features coming together as a unified whole that allows users to reach a goal they want to reach, you’re ready to release a new product. Or, for existing products, you’re ready when you have additional features that will make existing customers happier or attract new customers.
Before you release, prepare how you’re going to learn from the live product.
Once live, keep an eye on your analytics and bug reports. Talk to your customer service people about the questions they’re getting from users. Provide a way for your customers to give you feedback on your product. Ask those who give feedback or suggest features if they’re interested in getting sneak previews of new features. Use this group for your beta testing of yet-to-be-released Increments.
You’ll also need to keep tabs on your key metrics. Have you hit your stretch targets? If not, what might you do in upcoming Sprints to get there?
In Scrum you’re always looking at the work you’ve done and trying to find ways to do it better.
With this in mind, you could focus a Retrospective on your product discovery work or even have a specific discovery retro. Document a couple of key actions that will improve your future discovery work. Then celebrate your successes!
Make a bigger impact by mastering the Product Owner role in Scrum
We’ve expanded and revised our Product Owner Primer posts into one handy 100-page PDF.
Boost’s Guide to being a Kickass Product Owner is your one-stop guide to Product Owner success.
In New Zealand and keen to get to grips with Scrum and the Agile mindset? Check out our Agile training:
Agile Professional Foundation certification, Wellington, NZ – two-day ICAgile course
Introduction to Agile methodology, Wellington, NZ – free two-hour workshop
Agile Accelerator team assessment – Agile review and action plan
Roman Pichler’s blog: Strategy and Vision and his discovery tips
Boost blog: The Board episode on discovery workshops and From good to great product ownership
