Product Discovery Recipes
More info coming soon…
But, here’s the link to download the pdf
More info coming soon…
But, here’s the link to download the pdf
Your product team will need to keep its work visible to stakeholders outside the team. If your product team is doing both discovery and delivery, you’ll need to review both those things. If you’re new to dual-tracking, use this recipe as a starting point.
Purpose: Keep your product’s health, your discovery work, and your development work visible to the whole organization.
In Scrum, sometimes this is called a Sprint Demo. Some teams call this meeting a Showcase. You might know this as the thing your team needs to do every few weeks to keep your work visible to the whole organization.
There are lots of others in the organization who are likely interested in what you’re working on, and what you’ve accomplished. You’ll need to make this work visible to them. Unlike your team, these others probably don’t know the details of what you chose to build, nor where they fit into the big picture. So, you’ll need to plan on connecting what you accomplished and learned back to the product. This is also an excellent opportunity to learn from them, and to get their support.
Do use this review to show the outcome of your efforts. Stakeholders should care about that.
Don’t use this meeting as a place for stakeholders to criticize your team’s planning or the way your team works. That’s your team’s responsibility to manage.
Who: Invite everyone who’s interested.
This is a big public review. Anyone interested is welcome. Make sure your whole team is there. Seeing others’ reactions to what they’ve done, either positive or negative, helps remind them that what they’re doing matters.
Some organizations combine multiple product teams’ reviews into one larger stakeholder review. This cuts down on the number of meetings stakeholders need to attend routinely.
How long: plan for 30-90 minutes. This review should be faster, and at a higher level than your teams’ product reviews.
Bring food. I promise everyone will like what you have to say when they’re loaded up with carbohydrates. Even bad news goes down easier with sweets.
If your team is responsible for an existing product or product area, you’ll need to review how that product is doing. If you don’t currently have something in production that users are using, skip this part. Hopefully you’ll get something shipped soon.
When reviewing your product or product area’s health, make sure you connect what your focusing on to the metrics that matter for the organization.
Discuss your product’s Key Metrics, or KPIs:
Discuss any subjective data on your product:
Reviewing discovery is critical. The best time to get feedback from stakeholders is before you’ve invested lots of time building something. If you’re showing real lessons learned from putting software in front of customers and users, they’ll value learning what their customers actually think. Often, the only thing that trumps an executive opinion is a cold, hard fact.
Notice that you’re not explicitly discussing the time budgeted for discovery or reflecting on your learning velocity. Your team owns the quality of its planning and its work. You’ll certainly answer questions and share how you did thing when asked. But, their no need to open yourselves up to micromanagement.
It’s been my experience that stakeholders are focused on what and when you’ll release to customers and users. They should be because it’s not until after you release a viable solution that you’ll be able to observe real outcomes and get real value. They’ll be interested in progress made toward that goal.
Review the delivery work you’ve completed at a solution-by-solution level. Think of the solution as the big rock that’s more relevant to stakeholders. The feature or capability that you’ll release. Some using story jargon may think of this as an epic.
For each solution:
Be prepared to write stories for new opportunities, or for changes you’ll need to make.
It’s possible that others in the room unfamiliar with what you’re building and why, will suggest things that aren’t a good idea. Respectfully and gently remind them of the target audience and outcome for the solution, and why what they’re suggesting might be a great idea, but doesn’t support the outcome you’re currently focused on.
Notice that you didn’t discuss your team’s development velocity and how that relates to what you’d planned on. Keeping your commitments is your team’s responsibility. Use your team’s review and planning meetings to discuss how you’ll meet those commitments.
Keep your work visible to everyone in your company. Help them be excited about what you’re doing and learning.
If you’re using a typical Agile process like Scrum or XP you’ll work in short 1-3 week Sprints or Iterations. You’ll finish each Sprint by reviewing the work you’ve done, and reflecting on how you could change the way you work to improve. If you’re a product team doing both discovery and delivery, this review and retrospective will be different than a team doing delivery work only. Use this recipe as a starting point to learn how.
If you’re using Scrum, this is a Sprint Review and Retrospective. If you’re using XP terminology, this is an Iteration Review. If you’re like some teems I’ve worked with you might do this Friday afternoon before everyone leaves, or Monday morning before you plan the next weeks’ worth of work.
One of the core characteristics of an effective process is stopping and reflecting on the work you’ve done, and using what you’ve learned to make changes to how you’ll work going forward. Yes, it’s an Agile tenet. But, it’s just a characteristic of any effective way of working.
Purpose: The team that worked together to understand their product development—and who made a short-term plan for doing discovery and development work—must stop and reflect on the quality of their work. Use a short workshop to accomplish this.
Who: the whole product team
Constrain this workshop to include only the people who worked together to understand and plan the work. Include the product owner and any others on the product team, as well as developers, QA, and anyone whom did active delivery work. Yes, I’m saying that it’s okay to exclude business stakeholders. We’ll share with them soon enough. But right now we need a safe place to talk.
How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box you’re reviewing.
Bring food. Years ago, in my team, this workshop simply couldn’t start if we didn’t have bagels.
If your team is responsible for an existing product or product area, you’ll need to review how that product is doing. If you don’t currently have something in production that users are using, skip this part. Hopefully you’ll get something shipped soon.
Discuss your product’s Key Metrics, or KPIs:
Discuss any subjective data on your product:
Reviewing discovery is critical. Show what you’ve learned from your customers and users.
Start by discussing and showing the software built as a result of the stories. Make sure you bring it up on a screen, and get a chance to try it out. All of it. In big teams, it may be the only chance everyone has to see one another’s work.
Grade your quality subjectively as a team. Grading will drive out lots of good discussion.
Write stories to correct quality issues you see in the product.
If you were working in a time-boxed iteration or a sprint, you started by making a plan and a prediction for how much you could get done, both discovery and development. Was your plan a good one?
This process improvement discussion is commonly called a retrospective, and there are lots of great approaches to performing one.
If you’d like to look at some more comprehensive recipes for retrospectives, try the book: Agile Retrospectives by Esther Derby and Diana Larsen.
If you’re a team working together on a product you’ll need a quick review and planning meeting every day. If you’re a team doing both discovery and delivery, that daily review and planning may go a bit differently. Use this recipe as a starting point if you’re new to dual-tracking.
Purpose: Use a daily standup meeting or team huddle to review your progress on the previous day and plan your work today.
If you’re already practicing an agile process, you’re probably familiar with a daily standup meeting. And, it’s been my experience that for some teams this can be one of the most annoying parts of the day. If it is, this may be a hint you should change the way you’re doing things.
Remember: This isn’t a status meeting.
This is the team’s time to figure out how they can work together to make as much progress as possible today.
Who: the whole product team
How long: Keep these meetings 15 minutes or less. If a problem takes more than a minute to discuss or solve, use this meeting to plan a time to discuss it afterward.
The standup meeting may be the one time in the day that the whole team is together.
Review each story in progress. Hopefully there are only 2 or 3. If you have more stories in progress, it may be a symptom of not working together, or “swarming” to get stories completed faster.
For each story in progress discuss:
While discussing development work it’s helpful to look at simple visualizations:
Notice we’re discussing our progress story-by-story and not person-by-person. Remember it’s not about who’s most busy. We’re all busy. It’s about the progress we’re making on the software we agreed to build. Keep the focus there.
Part of the team’s work is refining development stories for the next cycle. If there are stories that need refinement workshops today, let people know during the standup so that can attend if they want.
We’ve saved discovery discussion for last. It’s OK for team members who aren’t involved in discovery work to leave and get to work on development work.
Review each opportunity in progress:
As with discussing development work, it’s useful to have visualizations to support the discussion:
More reading: Jason Yip, currently a coach at Spotify, has a useful paper describe lots patterns and approaches to standup meetings. While he doesn’t explicitly discuss discovery work, you’re sure to find some useful advice in it: It’s Not Just Standing Up: https://martinfowler.com/articles/itsNotJustStandingUp.html
If you’re using a typical agile process like Scrum, you’ll break your work into Sprints or Iterations that usually range from 1-3 weeks. You’ll start each Sprint with a planning meeting. If your team is a product team engaged in both discovery and delivery, your planning session will need to account for both kinds of work. This recipe will give you a starting point.
Purpose: use a team planning session to set goals and plan work together as a team. The team owns its plan. It isn’t given to them.
Who: the core product team including the product owner/product manager and the few people the lead discovery and development for your team’s product.
How long: this is a continuous activity. You may spend a little bit of time every day or every couple days. Just be ready for the team planning meeting or it makes it challenging for everyone.
If you’re a product owner, meet routinely with your core product team to discuss the progress of the solutions underway. Choose the stories that you’d like to take on next to move those solutions closer to release.
For those on the product team, make time to work together with team members ahead of the planning session. Dig into details, split larger stories, and consider multiple options. In my book User Story Mapping, look back to Mat Cropper’s story in Chapter 7. When I spoke with Mat, one of the things he most looked forward to was the series of short, half-hour ad-hoc story workshops he had us developers and testers get ready for planning.
Since you learn something after every cycle of discovery validation, it’s hard to choose these too far ahead of time. It may be as simple as carrying forward the opportunities you’re working on the in the current development cycle.
Be ready to talk about the opportunities you’ll be exploring over the next sprint. Be ready to talk about your learning goals. And, be ready to discuss the amount of whole-team participation you’ll need. You’ll need to give the team an idea of how much help you’ll need for them in the coming cycle.
And any others whose help you might need during the upcoming development cycle. Hopefully your planning session is already on the calendar. It should be a routine workshop that follows the cycle-end review.
Who: the whole product team responsible for doing the work. Optionally anyone else that may work with the product team during the next cycle.
How long: plan for 1-3 hours. It depends on the size of your team and the length of the time-box you’re planning for.
You’ve chosen some opportunities to move forward with discovery work and some stories to work on delivering. How do these opportunities and delivery stories help advance your product?
Review each opportunity – there should only be one or two. What are they? What’s the benefit for building them? What are the risks or assumptions you’ll be working to test? How might the team help in this effort. Agree on a time-box for team involvement. You’ll need to know how much team time you’ll be using for discovery to figure out how much development work you’ll be able to take on.
Don’t go into extreme detail here – just enough to give everyone the big picture. Use lots of pictures. Bring in decisions that smaller groups made in story workshops.
Remember, crowds don’t collaborate. And the people building and testing this software need to do some real thinking to create their recipes for building these stories. Give the team an hour or so to break into small groups and work together on the stories. If you’re a product owner, UI designer, or business analyst, stay close by. Observe if you like. But be ready to answer questions that’ll help them move fast.
Work in small groups that include developers, testers, and anyone else that has work to do to turn the story into working software.
At the end of the time-box, and after the team does their plan for each story, they’ll need to come back and share their plan. Not every detail, because that would be super-boring, even to them. But, what’s important is for the team to be clear about what they believe they can get done in the cycle. They should take this plan and their agreement seriously, especially if they want others to consider them reliable and predictable.
Agreeing may take a little time, especially if all the work that needs to be done won’t fit in the development time-box. It’s lucky you know some tricks for slicing stories down thinner. Try dialing back a story from better to just good enough. That should make it fit.
You’re done. In the past, we liked planning in the afternoon. We tried to finish a bit before quitting time. Then we’d celebrate by taking the rest of the day off. We showed up the next day refreshed and ready to start working on the plan we created together.
If you’ve heard the term “dual-track development” before, this article explains where it comes from, and what it means. Here are the key points:
Now, if anyone asks you what the article is about, you can answer them without reading the next 1,500 words.
Years ago, I was teaching a class with my friend Marty Cagan. It was really just my stuff and his stuff mashed together in a 3-day class. But, during my part I put up a model that I normally show when talking about how Agile thinking and product thinking work together in the same process. The model looked a little like this:
I’d hand-drawn my own version of the model, so it did’t look exactly like this. But, Marty asked me where this model came from. I opened the original paper from Desiree Sy (pronounced See) called Adapting Usability Investigations for Agile User-centered Design.
This is Desiree. You’d like her. She’s very smart.
Her 2007 article describes a common pattern which lots of people doing rigorous design and validation work in Agile development had already arrived at. Because, it’s really the only way this stuff can work. At the time, Desiree was working with Alias, now an Autodesk company, and she and her colleagues there had this working pretty smoothly. They were doing what most people at the time considered somewhere between super-hard and impossible. But, for them it seemed natural. Not easy, but it worked.
Marty asked me “what’s this model called?”
“It doesn’t really have a name” I said. “It’s just the way it’s done.”
“What does she call it?” Marty asked.
We scanned the paper and found this paragraph:
If I extract the important bit, it says
“… we work with developers very closely through design and development. Although the dual tracks depicted seem separate, in reality, designers need to communicate every day with developers.”
And that was it. Marty began using this term in his teaching to product managers. And since I often teach to the same people I began using that term. And gradually others began using that term.
Now I need to tell you I hate the term, and here’s why.
People just don’t read. It’s a miracle you’ve read this far yourself. Congratulations.
But people do look at pictures. And that picture of dual track seems to suggest different jobs for different people – like product managers and designers figuring out what to build, and developers building it. And in the worst of cases, you may interpret it as developers needing to wait weeks for product managers and designers to get their sh*t done. It’s not supposed to be that way. If the whole team is responsible for product success, not just getting things built, then the whole team understands and contributes to both kinds of work.
I’d love a different term, and a different picture. But, I don’t have a better term or picture right now. Although I’ll try to draw a few more pictures to supplement this one.
If you’ve worked in Agile development before, you know teams will talk a lot about velocity. But the velocity they’re talking about is development velocity. Teams hand-wring about their predictability. At the beginning of a sprint, they’ll estimate velocity, and at the end they’ll measure it. Ideally their prediction was accurate.
When you’re delivering production quality stuff, quality is super important. If we’re putting software into production, quality, scalability, performance, localization, and lots of other concerns are important. So, finished development work should be built, tested, and reviewed by others to look after all these concerns. Agile teams will talk a lot about “potentially shippable software” which really means that they may not have built enough of it to ship yet, but once they do, the quality is high enough that they could ship it confidently.
Development work focuses on predictability and quality
One of the tragedies in software development, and all product development for that matter, is that much of what we build doesn’t succeed. It doesn’t deliver the benefit we’d hoped. So, that’s a problem. But, even before that, it takes a bit of time to learn enough about the problems we’re solving to make good decisions about what we should build. We use discovery work to do all that. To answer questions, to test ideas, and to avoid – as much as possible – wasting time over-investing in quality stuff we shouldn’t have built in the first place.
We want to learn as quickly, cheaply, and safely as we can. So velocity is important during discovery too – but this is learning velocity.
Discovery work focuses on fast learning and validation
Because the goal is learning, not working software, a discovery learning loop looks a bit like this:
It starts by describing:
That’s our bet, our best guess, our belief, our hypothesis. All of those are uncomfortable words for people who believe they’re building the right thing. But, the truth is, we’re always making a bet that we’ll get value. Embedded in that bet are lots of assumptions, risks, and maybe some questions. To focus our learning, we’ll choose the assumption, risk, or question that scares us the most and identify an experiment or method to learn. Then do it. Then use what we’ve learned to change all those going-in beliefs about problems and solutions.
Sadly, one of the most time consuming and expensive ways to learn is to build potentially shippable software. So we don’t – unless we really can’t come up with any other way to learn, or we’re really confident our bet is good. Remember, we’re not betting we can build it on time. We’re betting that people have the problem we’re solving and will happily try, use, and adopt our solution.
The most expensive way to test your idea is to build production quality software
That’s how a learning loop works. And there’s a few things you should know about it.
We do all this as fast as we can. In hours when possible. Sometimes it may take days. But, we hope it doesn’t take weeks. So, lots of discovery learning loops should fit in a typical 2-week sprint.
Discovery work often results in killing ideas. At the end of every test you’ve got a decision to make: build it, kill it, or keep learning. Yes, what I’m really saying here is discovery work can and should result in killing ideas. Not everything goes forward. This can make some folks really uncomfortable.
We time-box discovery cycles. To keep discovery costs from running away from us, we’ll timebox a test or experiment from a few hours to a few days.
We can’t predict what we’ll need to learn next – not easily. When we learn something really valuable, it tends to really change our going-in beliefs, and really change what our next biggest assumption or question is. This can really suck.
Discovery loops chain together a little like this:
By now it should be clear that both development and discovery work are critical. But the mindset you approach the work with, and your process for doing it, are very different.
To actually start building work software, you’ll need to make a lot of tactical design decisions. These may not be the risky decisions that need validation, but they still need to be made. It’s often designers that need to spend time ahead of development to refine and finish design work in preparation for writing code.
If you’ve validated the product is worth building, you’ll likely need to finish some detailed design work before you write code
It would be super-cool if we could all focus on discovery work, get it done, then move our focus to tactical design and development. And that could work if all team members had the same skills. But since some are good at writing code, some are good at user experience design, and others are good at a variety of other things, we’ve got an opportunity to be doing many kinds of work at once. So we do.
Discovery work happens concurrently and continuously with development work.
I draw the conjoined model a little like this these days.
Discovery work uses irregular cycle lengths. It’s “Lean” in that we’re trying to make the discovery cycle as short as possible. Ideas in discovery mutate and very often get abandoned. The best move forward into more deliberate development cycles. I’m not sure how to show all that stuff in a single drawing. But, I’m trying to in the one above.
Discovery and development are shown in two tracks because they’re two kinds of work, and two kinds of thinking
But, you shouldn’t think of it as two processes – just two parts of one process. And, I think you’re doing developers and others on the team a disservice not to involve them in discovery work.
There’s usually more than enough discovery work to do and lots of ways to involve the whole team in doing it. If you feel pressure to shorten discovery work to “feed the beast,” it usually means you’re making decisions to build software before learning enough to be confident that you should. In the best case the outcomes are uncertain and usually the outcomes are just bad.
The whole team is responsible for product outcomes, not just on-time delivery
Let me hit the biggest misconceptions people have with the model again.
Myth: Discovery is a process that precedes agile development. It shouldn’t.
Discovery is a necessary part of product development. Practice it with the same agile and lean principles in mind.
Myth: All work moves from discovery to development. It doesn’t.
If we’re doing discovery right, we substantially change and kill lots of ideas.
Myth: The discovery team is different than the development team. It shouldn’t be.
While a product manager, designer, and senior engineer may lead and orchestrate discovery, they must Involve the whole team in discovery tasks wherever possible. Keep discovery work and progress visible to the whole team.
Myth: Once you move from discovery to development, discovery work done. It’s not.
This misconception is something that really bugs my friend Jeff Gothelf. He sees the production-quality software we build as our last-best experiment.
Keep measuring and learning even after you ship.
From Jeff Gothelf’s perspective, it’s all discovery and we learn from everything we make; be it a paper prototype, or the next feature in your production software. I agree with him.
I’ve talked conceptually about what discovery and development work is, and why you combine them in the same process. But, I’ve said very little about how you do this in practice. You should be feeling a little unsatisfied. Sorry about that.
But, this is the first article in a series I’m writing. Next articles will cover:
What questions are you left with? What’s your biggest challenge doing any of this stuff? Please let me know what I should be talking about that I haven’t mentioned above.
It’s Nov 1, 2019 and I’ve added a few more articles that’ll give you some dual-track tactics. Specifically how Sprint/Iteration planning, daily standups, and reviews should go in a dual-track world. Take a look at these recipes:
I teach classes in Scrum Product Ownership. But, they’re really classes about product management and design in an Agile context. Because, do you really need yet another class on Scrum? I’ve got upcoming classes scheduled with my friend Jeff Gothelf, author of Lean UX and Sense & Respond. The two of us tackle product thinking, discovery work, and this sticky dual-track stuff head-on. You should consider coming. Or tell someone in your organization that needs to understand this stuff about the workshop.