Issuu

Smart Scrum Product Ownership

Using Agile, Design, and Lean Thinking to Discover and Build Products People Love Aug 2019 Edition

Workshop Instructors:

Jeff Patton

Jeff Gothelf

jeff@jpattonassociates.com www.jpattonassociates.com twitter: @jeffpatton

jeff@gothelf.co www.jeffgothelf.com twitter: @jboogie

Download this handout, quick reference guides, and other course material at: http://jpattonassociates.com/handouts

Table of Contents About this workshop ..................................................................................................................... 3

Product Thinking and Process .......................................................................... 6

1. Focus On Outcome and Impact ................................................................................................ 6 2. Understand the Whole Product Lifecycle............................................................................... 11 3. Continuously Evaluate and Improve Your Whole Product Development Process ................ 16 4. Product Teams Own Products ................................................................................................ 20 5. Map product teams to your portfolio of products ................................................................. 23 6. Map & Evaluate Your Product Team ...................................................................................... 29 7. Product Teams Must Collaborate Effectively ......................................................................... 34 8. Use Stories and Story Driven Development Throughout the Product Lifecycle.................... 38

Sense .............................................................................................................. 42

9. Use Data to understand product use and business impact ................................................... 42 10. Use face-to-face observation and interviews to gather subjective data ............................. 46 11. Build simple models to understand your users and their product experience ................... 47

Focus .............................................................................................................. 50

12. Product Vision is Science Fiction .......................................................................................... 50 13. Product Strategy & Roadmaps.............................................................................................. 52 14. Tools for Keeping Focus Visible and Helping to Prioritize Options ...................................... 54

Discover (Respond with Tests) ....................................................................... 57

15. Learn Fast, So You Don’t Have to Fail ................................................................................... 57 16. Use a Canvas to Frame Product Improvement Options....................................................... 59 17. Use simple visualizations and collaboration for analysis and design................................... 63 18. Focus and Ideate to Consider Many Possible Solutions ....................................................... 66 19. Declare your hypotheses ...................................................................................................... 68 20. Identify & Design Tests ......................................................................................................... 69 21. Interview and Test to Gain Empathy and Insight ................................................................. 80 22. Keep Learning from Each Test Visible................................................................................... 85 23. Identify A Release Strategy ................................................................................................... 88 24. Use a Lean Canvas to Distill Hypotheses and Identify Your Next Test ................................. 92

Deliver (Respond at Scale) ............................................................................. 93

25. Create a Development Strategy to Minimize Development Risks ....................................... 93 26. Plan and Workshop Stories Ahead of Development (AKA backlog refinement) ................. 94 27. Support Predictable High-Quality Development .................................................................. 99

Balance Continuous Discovery and Development ....................................... 103

28. Continuous Discovery and Delivery in Parallel Tracks ........................................................ 103 29. Plan Discovery AND Delivery .............................................................................................. 111 30. Standup to review and plan every day ............................................................................... 114 31. Review Sprints with the product team ............................................................................... 116 32. Review product team progress with the organization and stakeholders .......................... 119

About this workshop

Appendices & Quick References .................................................................. 122

Reading List ............................................................................................................................... 122 vAgile Product Development Lifecycle Quick Reference ....................................................... 123 vUser Stories Quick Reference................................................................................................ 127 vStory Mapping Quick Reference ........................................................................................... 129 Warning, this document may include typos and grammatical errors. My apologies for that. It’s a constant work in progress with changes made monthly. Please let me know about any suggestions you have for corrections or improvements at: jeff@jpattonassociates.com You can always find a most current version at: http://jpattonassociates.com/handouts

About your instructors Jeff Patton, author of User Story Mapping Jeff Patton helps companies adopt a way of working that’s focused on building great products, not just building stuff faster. Jeff blends a mixture of Agile thinking, Lean and Lean Startup Thinking, and UX Design and Design Thinking to end up with a holistic product-centric way of working. Jeff has worked in software development for over 20 years in a variety of roles include product manager, engineer, project manager, coach, and consultant. Find out more about Jeff here: www.jpattonassociates.com See what he as to say on Twitter @jeffpatton Jeff Gothelf, author of Lean UX and Sense & Respond. Jeff is a designer, product strategist, team leader and author. He's been teaching teams across the world to rave reviews. Jeff has been creating software products for over 17 years with companies like AOL, Fidelity, WebTrends & TheLadders and Neo Innovation. Read Jeff's blog here: www.jeffgothelf.com See what he has to say on Twitter: @jboogie

About this workshop

About this workshop Passionate Product Leadership is a workshop focused on the concepts and practices that help teams create successful products. Even if you don’t think what you make is really a “product” – because you don’t package and sell it commercially, my hope is that you come to see it as a product. And, once you do that you’ll begin to see that applying product thinking helps you and your team create something you’re truly proud of, something that really makes an impact on the people who use it. This workshop qualifies as a Certified Scrum Product Ownership course. But, what’s important to know is that this isn’t just a course about filling the product ownership role in Scrum. It’s a course that teaches the practices you and your team needs to create successful products. That’s a mouthful of jargon and hype. But the impact we're focused on bringing about is:

You apply new thinking and practices to the things you make and those things are more successful than ever before. That’s a lot.

This workshop is for the whole product team Too often organizations adopting agile approaches and Scrum are lead to believe a single person in a product owner role is responsible making all the decisions about the product down to the last detail. The result is a stressed overworked product owner that’s become a bottleneck for everyone else in the organization. Others with critical input and valuable skills are often shut out of the process. In the end the product being built gets worse, and people in the company are less happy than ever before. But that’s not the way agile development is supposed to work. This class is about an approach to agile product ownership that does.

While a Single Product Owner may lead, product ownership and product success is a whole team responsibility This workshop is for:

You’ll be practicing a team-based approach to product ownership where a product owner leads a small focused product discovery team and together they collaborate with delivery team members, customers, users, and business stakeholders. § § § §

Product managers, business stakeholders, and product marketing professionals: to understand the practices that lead to valuable products User experience practitioners, and business analysts: to understand the practices that lead to usable and desirable products Senior engineers: to understand the practices that lead to feasible products Project managers, Scrum Masters, and agile coaches: to understand how to guide successful product discovery and delivery

Workshop learning objectives Ultimately the impact I’d like to have weeks and months after you’ve attended this course is that:

You and your team work together with your company to create more successful products About this workshop

While this course covers the details you’ll need to fulfill or support the Scrum Product Owner role, we believe that understanding the role and its requirements isn’t enough to be successful. In this course you’ll engage in a process simulation that models a different way of working; a way that emphasizes working collaboratively with others using a user-centric product design approach. At the end of this course you’ll be able to:

• Envision and describe the day-to-day work practice of a Product Owner and a Product Team • Draw from a variety of effective product design principles and practices to support product discovery and delivery • Gain enough hands-on experience with product ownership practices that you feel comfortable trying them in your workplace

Workshop Instruction Workshop instruction will be a mixture of discussion and hands-on exercise.

The class is fast-paced and interactive. Wherever possible you’ll be engaging in practice with others. If you didn’t come with other members of your team at work, I promise that you’ll wish you had.

There are no slides, well not many…

I’ll use slides primarily to show pictures and examples, and sometimes figures that are difficult to draw by hand. Throughout the class I’ll use words and pictures to explain key points. What you’ll see is my hand projected as I talk and draw through key points. It looks like this:

About this workshop

One of the key points in the workshop is that communicating is much more effective with words and pictures. And, that if you draw pictures yourself, it’ll help you remember, and others listening to you remember.

Take notes, and draw along Use the open space in this workbook to write and draw along. Yes, I’ll share all the drawings I make during the workshop. I’ll post them on the wall as the workshop proceeds, and then share them back to you in a Dropbox folder. For public workshops, you can find them at: http://jpattonassociates.com/handouts For workshops inside a company, I’ll email a direct link to your photos after the workshop.

Pay attention to your takeaways A good friend of mine says that teaching is like “pushing string” – which sounds impossible except that learners can pull the string put before them. You can pull on interesting strings by listening, and asking questions. Make note of your takeaways – the ideas you find useful or valuable. Some call these light bulb moments because it feels light a light bulb turning on when you hear an idea that you can really use, or a concept that resonates with you.

Write down your takeaways to share You’ll share them by posting them on sticky notes, or during a 1-word share out that we often end the day with.

You’ll be working collaboratively in small teams One of our first activities will be to form small balanced product ownership teams.

This handout is a work in progress, and always will be Please forgive typos and grammatical errors. Often, content is added at the last minute to tailor this handout for your group, or to incorporate new ideas. I’d love your comments and feedback on its usefulness. You can download the most recent version of this guide, and any handouts used in this workshop at: http://jpattonassociates.com/handouts

About this workshop

Product Thinking and Process 1. Focus On Outcome and Impact Effective product development is focused on maximizing outcome and impact of product development effort The curious thing about product development is that if you focus too much on the product, you’ll fail. In fact, your goal isn’t to get the perfect product built, as a product team, your goal is to change the world. Here’s how:

Q: How does your organization measure output?

Q: How does your organization measure product outcomes & impact?

Q: Which does your organization pay more attention to measuring and improving: output, or outcome and impact?

Product Thinking & Process

The simplest way to visualize output and outcome If you’re already using an agile process like Scrum, you may be tracking the number of backlog items you complete every sprint – your velocity. But, you know that every backlog item usually isn’t a releasable feature or capability.

It usually takes several backlog items to create a releasable feature or capability. Outcomes can only be observed after that whole feature or capability is released so users can see it, try it, use it, and then get some benefit out it. Those are all things your customers and users must do – not your team. So, it’s nearly impossible to reflect on the outcome of what you build immediately after building it. Depending on the type of product you’re making, it can take weeks, months, or even longer to observe outcomes. If your organization is new to product thinking, you likely haven’t invested in the kinds of metrics and tools it takes to measure if your users have in fact seen, tried, and are using the features you released. So, you may need to rely on talking with them or observing them directly.

It will take time and effort to evaluate the outcome of a feature or capability you released. This is all bad news if you haven’t worried about this stuff before. You’ll need to: § §

Track the individual features or capabilities you release – not just backlog items Find ways to measure and/or directly observe the outcomes from those features

Here’s a bit of a shortcut to make doing this as painless as possible. But, it’s still going to take a bit of effort for you and your team.

Use a simple 2-dimensional visualization to track features and their outcomes. Sticky notes on a whiteboard is the easiest way to start. Keep the visualization where your team and leadership can see and discuss it easily. Use the left-to-right axis to track effort Use the top-to-bottom axis to track outcome.

Product Thinking & Process

As a feature or capability is completed, discuss the ACTUAL effort it took to create it Place a sticky for the feature on the left to right axis. The left side is days or weeks of effort, and the right side is months of effort. And in between is, well, in between. Use the actual effort – not the estimated time. You’ll find lots things took about as long as you expected. But some things that might have been estimated at a couple weeks took months. For the things that took longer than expected, tag them. I like just marking them with a red dot. Trust your intuition. If team members disagree on the actual effort, then I promise you’re going to have an interesting conversation.

Every week to two weeks reposition the feature vertically based on the actual outcome you’ve observed The bottom of the Y-axis is the “don’t know” area. All features start here - since immediately after their release, we don’t know if people will see, try, and use them.

As time goes by, reposition the features on a scale of awful to awesome. Awesome is at the top. §

You’ll know awful because people will likely complain. You may need to apologize, fix it, or roll it back. You’ll know awesome because people will see, try, use it and then say good things. You’ll get unsolicited compliments for it. But, you’ll notice lots of things end up between those boundaries. Not awful, but not awesome either.

Trust your intuiting here too. If you don’t have precise data, trying to figure out what the outcome actually was may drive you and your team to talk to more customers and users. That’s never bad. If your team disagrees on where to position the feature vertically, then you’ve got another useful discussion to look forward to.

Use this 2-dimensional chart to reflect on the effort and outcome of what your team builds. If you’re a product owner or part of the core leadership of your team, it’s a key responsibility to keep this stuff visible. Discuss it with your product team routinely. At the end of every sprint is a good time. And, as you get fresh information about the outcome of a feature. Celebrate moving a feature up the outcome axis. Celebrating actual successful outcomes vs. celebrating delivery is a sign your team is really becoming product-centric. Notice how the effort you spend building a feature doesn’t correlate well with the outcome. Small features are just as likely, if not more, to have an awesome outcome. Notice how high-effort features are much more likely to take longer than expected. Knowing this may help your team work harder to find smaller successful features. Or at least be better prepared for the disappointment of finishing late. Notice how long it takes to really understand the outcome. Discussing how you measure outcomes frequently will likely result in your team finding better ways to measure. That’s good.

Product Thinking & Process

Backsliding into vendor mode There are many businesses which create things to order, or do custom repair. We deal with these kinds of businesses all the time. Businesses like auto repair shops, home remodelers, or wedding cake bakers. Their product is the work they provide and it works like this:

In this model the client is responsible for the value, and the vendor is responsible for time, cost , and quality. Together they must agree on scope. § § §

When they client gets more “scope” at a lower price, the client wins. When the vendor does less work at a higher price, the vendor wins. When the vendor finishes the work, the client owns the resulting product.

You can see the motivations of these two groups aren’t exactly aligned. You can see the client is responsible for value, and ultimately owns the product or result of the work. Applying this model inside our own company is where the disfunction starts. The business is treating IT like an outside service provider. Or even the product owner treating their team as a vendor.

The client-vendor anti-pattern finds its way into the “Business – IT” or the Scrum “Product Owner – Team” relationship. Since we both work for the same organization, neither party gains when we try to negotiate a lower price. And, when we build technology products for ourselves, we all own the resulting product. A real outside vendor would transfer ownership to their client upon completion of the work. But, IT doesn’t transfer ownership to the business on completion. They still support and maintain what they’ve built. While this idea may serve us in the outside world, it hurts us inside our organization. Product teams can’t work that way.

Product Thinking & Process

Signs you are or aren’t working in a product-centric organization Here are a few things to look for in your organization that may signal that your technology organization is treated more like a vendor. Contrast these with what an organization might look like if the technology it creates is understood as part of the product or service the company makes, and those creating the technology are responsible for its success.

Try to be less like this…

More like this..

Output focused

Outcome focused

Teams and the organization are focused on time, cost, scope, and quality. The organization celebrates successful release.

Releasing frequently and at high quality is assumed. Teams and the organization scrutinize outcomes, celebrate successful outcomes, and focus on improving unsuccessful outcomes.

Project funded

Product funded

Teams form and are funded to create large releases. Teams disband after the project releases.

Teams are funded to cover a customer, user, area of business need over time. Product teams release many times during the funding period. Refunding is based on the outcomes achieved.

Deciders and doers are separated

Whole team responsibility

Roles and responsibilities strictly separate those responsible for deciding what gets built from those responsible for building it.

While individual team members have specializations that make them better at different types of decisions, the whole team is considered accountable for successful product outcomes.

Delivery risks emphasis

Outcome risks emphasis

The risks that threaten on time delivery of promised scope are weighted high. Project managers expose and manage them. Risks that we won’t get the expected outcome and value aren’t exposed or discussed.

The risks that customers want and can and will use your product are exposed and discussed. Risks with technology working as expected or scaling are discussed. Teams spend time engaged in discovery activities to expose these risks and then consider and test multiple solutions.

Apply product thinking to whatever you create When you treat whatever you do or make as a product, you’ll spend more time focusing on the people who will actually use what you make and their success. In Jeff Gothelf’s article: “DO HR, FINANCE AND LEGAL MAKE PRODUCTS?” Jeff asks everyone, regardless of your department or role to consider what they make, who will use it, and what good outcomes are. Try this throughout your organization. https://jeffgothelf.com/blog/do-hr-finance-and-legal-makeproducts/

Product Thinking & Process

2. Understand the Whole Product Lifecycle The whole product development cycle starts before, and continues long after, any single product or feature delivery. While a project may be considered completed at delivery time, the life of a new product or feature begins at delivery. And, if you’re with a product company that already has a product, which most of you are, you know this cycle is continuous and overlapping.

Let’s clear the air about MVP Before we can talk about product development, we need to first get a couple terms straight. The term Minimum Viable Product, MVP for short, is one of the most misused and abused concepts in software development. During this workshop I’ll discuss 3 definitions for the term.

Minimum Viable Product is officially a messed up term. If you use it, be clear about what you mean. Robinson’s smallest successful release Frank Robinson of SyncDev originally coined the term in 2001: http://www.syncdev.com/minimum-viable-product/ Frank was encouraging product teams to identify the smallest product that could be successful in their desired market. Frank pointed out that the way to identify what that smallest successful release could be was to use discovery work. By that he meant understand your customers deeply, and use iterative prototyping and testing to validate that your solution really would be viable.

Robinson coined the term and used it to describe the need for a smallest successful release. When Robinson coined the term he used it to describe that smallest release that maximized return on investment for the company that made it. By now you understand that to get ROI we’ll need to ship something that lots of people will see, use, keep using, and say good things about.

Ries’s next best test Eric Ries redefined how we use the term MVP today in his 2011 book The Lean Startup. He used the term to refer to the smallest thing you could make or do to test your hypothesis. By 2011 products were commonly built and released on the web. It was much more common for a product to release and evolve continuously. By changing the definition, Eric moved focus from big releases to learning faster. Eric Ries described Validated Learning, the process we use to declare our hypotheses, identify risks and assumptions, then create tests that help us reduce risk. Eric leveraged lots of concepts from Steve Blank and his book Four Steps to Epiphany, although Steve has more recent and better books out today.

Product Thinking & Process

We’ll talk through validated learning. Make your own notes as we do. Eric was right that the biggest risks in product development aren’t that we can’t get software built on time. Rather, the biggest risks are that we’re building something that really addresses a customer need. And, that enough customers need it for it to be a viable product for your organization. But, referring to our next best test as a “minimum viable product” only resulted in lots of confusion for people that understood the term before, or who hadn’t read Eric’s book.

Eric Ries moved focus to the next best test – although calling that next best test a viable product left lots of people confused. When only output matters, you’re left with bloated crappy releases If you didn’t know who Frank Robinson was, or hadn’t read Eric Ries’s Lean Startup and you heard the term MVP, you might be confused about what people mean. Sometimes they mean test, and sometimes they mean that something users really want and will use. That’s why you might sometimes hear terms like Minimum Loveable Product, or Minimum Marketable Product. Robinson originally meant lovable and marketable. A side effect of the client-vendor anti-pattern is focusing on getting as much output as you can at the lowest cost – or shipping as many features as we can by the promised delivery date. To get more in, we sometimes make concessions about how well designed or built those features are. Focusing on maximizing output is ironic for a couple reasons: it’s not “minimum” and those concessions we make often result in a release that’s not viable. In many organizations “MVP” is synonymous with “first crappy release.”

MVP should never mean first crappy release.

Product Thinking & Process

Understand the whole product development cycle To create a complete product development process, we’ll need both concepts of smallest successful release, and next best test. Let me say that again with emphasis:

Your product development process must include both smallest successful releases, and the next best tests that help you identify them. Together we’ll discuss this whole product development process. It’s actually not a process so much as naming the parts of product development every company does. I promise your company does all these things. The question isn’t if they do these things, but how well they do them. This model is built keeping Gothelf and Seiden’s book Sense and Respond in mind. They describe that for a contemporary product company to be successful, it must continuously listen to its customers, sense, and then respond with improvements. The 4 parts of the process are: 1.

Sense

Focus

Discovery (Respond with Tests)

Delivery (Respond at Scale)

Product Thinking & Process

1. Sense If you have a product in use by customers and users, your organization will need to be deliberate about sensing if that product is performing as expected. You’ll need to listen for opportunities to improve the product. You’ll need to listen for insights that could lead to whole new products, or sunsetting mature products. You’ll do that listening by collecting data on your product’s use, and by engaging directly in conversation with customers and users. Use metrics and data to understand how your customers use your product today. Use face-to-face conversation to collect subjective data to get the “why” behind the more objective data. All this listening will result in a pile of ideas for improvement, or problems to solve. I call that ever-growing pile an options or opportunity backlog.

2. Focus Listening to customers and users isn’t the only source of ideas. Your company’s vision should give guidance on where you’d like to be years into the future. And, that vision should describe something your customers aren’t likely asking for today. If vision is where you’ll be years from now, your company's strategy should give guidance on the stepwise approach you’ll use to get there. Your strategy will say more specifically where you intend to go next quarter, and maybe the quarter after that. Your current strategy will add opportunities to your backlog too. Objectives and Key Results, OKRs, are a good way to make your current strategy visible and measurable. Use OKRs to clearly state what your current product goal is and specifically how you’ll measure product outcomes.

OKRs, or target product outcomes, drive the prioritization of opportunities. Your company will likely have a roadmap that supports its strategy. Be sure that it doesn't just list the features you’ll build and when. Make sure your company’s roadmap also describes the target outcomes and how you’ll measure success. You may have to help your company articulate these. Make sure your company listens and learns from your customers to see if the strategy expressed in its roadmap is really working in the real world. That’s actually a “sensing thing” which feeds the focus thing. Data on whether your strategy is working informs your next strategic iteration. A sad reality is that your focus will need to be distributed. In your personal life you’ll need to budget time for sleep, exercise, eating well, time at work, and time with friends and family. None of those things is higher priority than the other. In your product organization you’ll need to do the same. Budget time against: § §

Strategic work: including both functional and technical roadmap activates Tactical, or responsive work: such as improving features you just shipped or fixing bugs. These things will never be in roadmaps or built into your OKRs because they’re emergent. They pop up because you’re continuously sensing the satisfaction of your customers and the health of your product.

Budget time for strategic work and tactical responsive work 3. Discovery (Respond with tests) Discovery is the work we do outside a traditional Agile delivery process like Scrum. Often Scrum thinking alone is optimized for predictable delivery velocity.

Product Thinking & Process

Discovery is about Learning Velocity Unfortunately, we don’t yet have easy ways to communicate learning velocity like we do delivery velocity. Discovery has two basic parts: 1. Forming strong problem and solution hypotheses 2. Focus on risk and uncertainty and use small tests to reduce that risk In traditional processes, we’d seek to collect the requirements for the product or feature we’ll build. We’d estimate time, and then create a plan to deliver it. In a discovery process we’ll still do that, but focus our work here on:

Building shared understanding within the product team of the problems we’re solving, the solution we believe will solve them, and how we’ll measure success after delivery. Most importantly we recognize that our solution idea is a hypothesis, that product outcomes aren’t guaranteed. We’ll need to ask ourselves:

How wrong are we willing to be? If we’re confident that we’re right, we can proceed with delivery – respond at scale. If not, we may want to engage in the second part of discovery work, testing our hypotheses. To test your hypotheses you’ll engage in a variety of activities like interviewing and observing customers and prototyping and testing solutions with customers. Your development team may aid in creating prototypes used in discovery, or even creating versions of your product to release to small audiences. But never forget that these are tests. Their benefit comes from learning. Don’t expect your organization to get big financial benefit until you scale the solution to be part of the product you ship to all your customers.

4. Delivery (Respond at scale) When it’s time to deliver a solution into use by all your users, you’ll need to pay extra attention to quality and scale.

Don't build products to scale until you’re confident that you’ll get the outcomes you expect. Don’t over-invest in prototypes by building them at production quality. Delivering your solution to all your customers is your last, most expensive, bet. And this is where the cycle restarts. You’ll need to sense how well your solution did using metrics and face-to-face customer engagement. Despite our best efforts in product discovery, we still release solutions that don’t perform as well as we expect.

Product Thinking & Process

3. Continuously Evaluate and Improve Your Whole Product Development Process Use a quick collaborative process reflection workshop to evaluate and improve your process Why?

To become more effective as a product organization, you’ll need to pay attention to how you’re doing things and find small ways to continuously improve. Improvement may mean adding new practices into your process, or turning up the volume on things you’re already doing.

When?

Evaluate your whole process routinely to reflect on how you’re doing. When adding new team members or reorganizing, stepping back and reflecting on how you do things will help everyone build shared understanding around how you work, your strengths and weaknesses, and where you’d like to improve.

How?

Use a quick collaborative activity to evaluate your current process.

Who participates:

Involve your whole product team.

You’ll need: § § §

A whiteboard or large flipchart paper Sticky notes Markers

For each of the 4 process parts: 1. Discuss

Briefly discuss what “ideal” means. Review the qualities described under the process area. § § §

Are there qualities you don’t understand? Discuss them with your team members Are there qualities you disagree with? If so, strike them out. Are there qualities missing? If so, discuss and add them.

2. Rate

Everyone give their own subjective rating on a scale of one to five, where 5 is best. You’ll disagree with each other, which is ok. You all see things from different perspectives. To rate fast, do it “rock-scissors-paper” style: Everyone think of their rating, then count to 3, then hold up a hand with one to five fingers up.

3. Discuss highs and lows

For those with lower ratings, 1 or 2, ask: § §

What do we do poorly? What lowers our evaluation? Discuss and note the deficiencies that could benefit from your attention.

For those with higher ratings, 3 to 5, ask: § §

What do we do well? What raises our evaluation? Discuss and note the competencies that make you great.

No matter what your rating, join in on the discussion of what you do well, and how you can improve.

Product Thinking & Process

4. Discuss small changes you could make to improve your ratings

Together discuss the smallest simplest changes you could make that would improve your product development process. Focus on small continuous changes. You and your team likely can’t change your organization and culture all at once. But, I suspect you can find one small thing you could do to improve things today. Do that. Then check back in a few weeks and see how it worked out. Then repeat the whole process. The secret to big improvement is making lots and lots of small improvements.

It’s impossible to have all these qualities For each quality I can cite an organization that has it. You might be able the think of examples too. However, even in the organization having the quality, it’s likely inconsistent. For example one area may have great metrics on the use of their product, while another area may have none. And, while I can cite an organization that does have many of the qualities below, I’m sure there isn’t an organization with all of these qualities. Finally, some of these qualities may not make sense given the kind of product your organization creates. When self-evaluating, trust your intuition and disregard things that don’t apply.

High ratings don’t equal product success When evaluating your organization, don’t expect to be perfect. It’s likely impossible. And, here’s the really bitter truth, even if you were, it wouldn’t guarantee your success. In fact, you may already be wildly successful even though you might score yourself low on this scale. Customers don’t care if you follow the right process. They only care if your product is awesome. Doing some of these things make it more likely you’ll build an awesome product. Nothing replaces experience and insight. And, sometimes just luck and timing.

Process parts and qualities: This, likely oversimplified process, breaks product development down into four different and broad parts. Under each part are a number of qualities. Each quality describes an ideal way of doing things in a technology product company.

Product Thinking & Process

Sense 1.

Product Metrics: You have usage metrics on your product down to the feature level and a subset of them are key performance indicators you monitor and discuss routinely with your team.

Frequent Customer Contact: You and your team build domain knowledge and empathy with your users through routine customer and user contact.

Visualization and Shared Understanding: We use visualizations to describe our customers and how they use our products today. We use those visualizations to build shared understanding within our product teams.

Reflect on What You’ve Released: You and your team reflect on both the effort and outcome of what you release. You improve or remove under-performing product features.

Monitor Technology Health: Your organization and team monitors the health of the underlying code and technology your product is built on. It routinely identifies technical improvements to make, or technical debt to pay down.

Strategic Research: Your organizations does some research to understand the market your product is in, competitors, and market trends. Your team leverages that research when it supports your work. If growth is important, your organization searches for new types of customers, or new problems to solve for the customers it has now.

Focus 1.

Vision: Your organization has a long range vision of what the world looks like with your product(s) in it. Since it’s years out, this vision looks a bit like science fiction. It’s aspirational and motivational.

Strategic Product Planning: Strategic plans describe how your organization will move towards its vison. Your organization focuses product strategy on what customers and problems it will solve when, what technologies it might apply to solve them, and how both customers and competitors might respond. Strategic roadmaps describe longer term bets your organization is taking, and the expected market outcomes it’s betting on and not just the features it hopes to ship.

Focus: Target metrics or OKRs look ahead 1-3 months to help product teams prioritize their work.

Budgeting Time: Your org and team budgets time for strategic product improvements, responsive improvements based on routine measurement and learning from customers, and technical improvements.

Product Discovery (Respond with Tests)

Customer Focused Analysis and Solution Design: We understand who our customers and users are and the challenges or goals our solution address. We design solutions that address specific user needs. We design for usability aspects like learnability, memorability, and efficiency. For functionality with visual user interface, we strive for visual design that inspires confidence and is consistent with our brand.

Smallest Successful Release: instead of large solutions that take a long time to build and deliver, we strive for small solutions narrowly focused on specific customers and needs. We know we’ll learn from this release and follow with subsequent releases that improve our solutions incrementally.

Hypothesis and Success Metrics: For a proposed solution, we declare specifically the customer and need we’re focused on, how we expect they’ll use it to get benefit, and

Product Thinking & Process

how our organization might benefit as a consequence. We identify metrics that will help us test during discovery and then measure this benefit after release. 4.

Visualization and Shared Understanding: We use visualizations and prototypes to show our solution and storytelling to help explain it. This helps build shared understanding in and outside our team.

Right-sized Tests: We expose assumptions, risks, and questions in our solution ideas, identify the riskiest, so we can focus on the most important thing to learn next. We identify the fastest and most effective way to test our assumptions, or learn what we need to learn next. If we spend more time and money to learn, we may get better data, but we also risk more money and slow testing our solution. We focus on right-sizing the tests scaling what we spend as our evidence and confidence increases.

Visible Learning: After each test we reflect on what we’ve learned, specifically what we were wrong about and new information that changes our hypothesis. We track what we’ve learned and use it to change our problem and solution hypotheses. What we learn changes our assumptions, risks, and questions, which changes our next best test.

Defer and Kill Ideas: We routinely reflect on solutions we’re testing. If testing and evolving our solution doesn’t increase our confidence in building at scale, we routinely defer or kill ideas. If the cost of the solution is low, and risk to damaging our customers or reputation is low, we may choose to release and measure, but then pull back the idea if it doesn’t perform as we expected.

Variety of Learning Approaches both Technical and Manual: We have a variety of tools we can use to learn such as ways to talk to customers frequently and remotely, various ways to prototype solutions quickly and at different levels of fidelity. We continue to invent new ways to test as technology and our experience progresses. Our technology stack allows us to use testing approaches such as split testing, feature toggles, or releasing functionality to a small subset of customers. When appropriate, we build technology that allows us to rapidly create live-data prototypes using our data and infrastructure.

Product Delivery (Respond at Scale) 1.

Predictable Delivery: Given a reasonable description and visualization or prototype of a solution, our development teams can reasonably predict the time it takes to build. Where there is uncertainty, our development teams have strategies for identifying and addressing risk early in development. We use what we learn early to adjust our predictions and our solution to best hit deadlines.

High Quality: We rarely find bugs in production. When we do, they can usually be addressed quickly.

Technology Stack Supports Quality and Speed: Our technology stack supports fast testing and release. We use automated regression testing to be reasonably confident new functionality doesn’t break existing functionality. We continuously integrate and deploy code. We can release unfinished functionality “dark.” We can release at a team and feature level.

Small Targeted Releases: We release production code into use frequently. We can target releases at specific groups of users. We can gently roll out big releases by region or customer group.

Match Engineering Rigor to Scale: When releasing smaller “releases to learn” to a small audience, we defer adding functionality to address unneeded scale, performance, or to address unnecessary operational concerns. We identify this “work not done” so that if and when it comes time to scale the functionality, we have a starting point to begin that work.

Product Thinking & Process

4. Product Teams Own Products A product team brings decision makers AND executors together on the same team Product teams include both decision makers, and executors. While they work with people outside their team to understand the outcomes they’re striving to achieve, the team is responsible for creating, and continuously improving their product.

Good product decisions balance value, usability, and feasibility Valuable for our business: § § §

Helps our business sustain itself Furthers our businesses vision and strategy Works within the operating constraints of our business

Valuable for our customers (those who choose to buy & adopt the product): §

For business products, has a value proposition that helps them sustain their organization For consumer products, it offers a similar value proposition, or is desirable as a luxury or indulgence Is better than competitor’s offerings or other alternatives

Usable: §

Users can easily try it, use it, and incorporate it into their lives or work

Feasible: § §

We can build it given the time, tools, technology, and team we have We leverage new emergent technology options that allow us to provide solutions that are better than solutions today.

A product team is composed of the people that have all the skills they need to identify and build a valuable, usable, and feasible product. Glube: Coaches, Scrum Masters, Delivery Managers, Project Managers A product team needs to both work tightly together and keep moving. An old friend of mine used a term I love to describe the job role that help makes this happen: Glube. If it’s not obvious, it’s the conjoining of “glue” and “lube.” It’s a pretty sticky term. If you’re using an Agile process like Scrum, you should have a Scrum Master. And being the Glube that keeps teams collaborating closely together and moving fast is a key responsibility of that role. Some companies have variations of that role with a variety of titles like: Agile Coach or Delivery Manager. In some organizations a Project Manager could be doing similar work. If you don’t have a person with that specific role, you might notice that someone does it informally.

Product Thinking & Process

You’ll know who they are because when they go on vacation, things seem to get worse. Finally in some organizations teams are self-aware enough to do this for themselves. Helping teams reflect on and improve the way they work so that they can work quickly and collaboratively is critical. Having a role focused on that helps.

Product Managers and Owners are collaborative leaders If you believed the product owner was the one that made all the decisions about what to build, or prioritized all the work, I’m sorry, you’re wrong. It’s rare that a single person has the experience and skills necessary to make good product decisions alone, so an effective product leader must work closely with others.

Product managers and product owners must act as strong collaborative leaders. I’m using the term product owner synonymously with product manager. In your organization you many not. In organizations like game companies, “producer” is a more common term. It doesn’t matter what term you use, it’s valuable for your team to have a collaborative leader. The product owner isn’t the functional manager of the team. They’re not responsible for approving time-off requests, or hiring or firing. They lead by inspiring, motivating, and collaborating well with their whole team. Yes it’s true that a product owner generally is a bit more business and organization focused, while a product designer might be more user experience focused, and engineers are technology focused. But when things are going well, all team members are aware of and take into account business, user, and technology concerns.

The Core Product Team For small product teams, 5 or less, the team may collaborate on most product decisions. For larger teams, a smaller core product team collaborates more frequently to make decisions faster, and involves the whole team wherever possible. For teams creating user-facing software, a core team is usually the product owner, a product designer, and a senior engineer. Although the composition may vary, the core should be the people who need to work closely together to make good product decisions fast.

The core product team works closely together to make good product decisions fast Some organizations use jargon like “triad,” “trio,” “nucleus,” or “team of three” to refer to a product team’s core. Even when there are two, or four people in the core you’ll hear the term “trio” used. That’s because it refers to the three concerns of value, usability, and feasibility. Many organizations don’t have the concept identified in their process. But, if you observe the way they work, their most successful teams have an informal core that work closely together. Think back to a product, feature, or capability you released successfully.

Q: Whom did you work closely with to make product decisions? Was your relationship formalized as a core team, or informal?

Product Thinking & Process

Core product teams orchestrate collaboration with everyone Core product teams must collaborate with a wide variety of people to be successful. They must: § § § §

Build ownership and accountability within the whole product team Become successful advisors and co-creators with business stakeholders Build deep understanding of, and empathy with, customers and users Look for and leverage the experience of outside experts when it’s needed

User Experience practitioners have a variety of specialties There are lots of misconceptions about what user experience work is and what a UX professional is. All products have user experience, even though they may not have a graphic user interface that appears on a screen. Some of the user experience may be handled by live people. If you build a technical API or service, the users are often developers, and the UI is the API you design for them. I’ll simplify UX to these three concerns: utility, usability, and aesthetics. Add your own notes to the model as we discuss it.

You’ll find UX practitioners like visual designers may be stronger at the top of the pyramid, but less comfortable doing the research and concept testing needed for the bottom of the pyramid. Interaction designers are generally trained to be strong at the bottom of the pyramid. Those skills are critical in product discovery work. But, just like software engineers can do front-end or backend work even if they have a specialty in one of the other, designers can often do the work that covers the whole pyramid.

Product Thinking & Process

5. Map product teams to your portfolio of products One product to one team In the simplest of situations, a single technology product is supported by a dedicated, collocated product team. Ideally the team is small, 5-10 people total. For startups, or even small single products in a larger organization, you can work this way.

Ideally one product maps to a single team that owns it One team to many products Time slicing

You may have a small engineering organization that is responsible for 2 or 3 products. This can be tough. The team will need to do all the sense and respond activities for each of the products they manage. They’ll need to get good at budgeting time towards different products. They may need to “ignore” some products while focusing on others. But like a parent with multiple children, you can never completely ignore them. Left on their own too long, they’ll go unwashed, malnourished, and staying up too late playing video games.

If you have lots of products, a single team must own a portfolio of products Multiple product owners?

Some organizations may allocate an separate owner for each product, but only one team of engineers, testers, or designers to create, maintain, and improve those products. If you’ve been a product owner in this situation, you know how tough it is. So, ideally, don’t do it. But, since the world is less that ideal, you’ll need to get really good at working with your peer product owners to prioritize your products and the work against them together. Whatever you do, don’t make your team decide “which parent to listen to.”

Transitioning from an IT project model to a product team model

If you’re an organization that’s historically used an IT model, you may have lots of technology you’ve installed, created and manage. Often projects were used to create these digital things. Then they were turned over to maintenance where they’re no longer actively owned or managed. In some IT-centric organizations there may be hundreds of these, many of them in poor condition, many used rarely, or not at all. If you make sense of your portfolio of technology assets, you may find many that duplicate each other’s functionality for different groups of stakeholders in your organization. This is all bad. Make sense of your portfolio of products by: 1. 2. 3.

Identifying all the technology assets your organization manages For each asset, discuss its health today, and where it fits into your businesses vision and strategy Identify teams that can own groups of related technology assets and let the teams manage them as products

There’s a lot more to transitioning from a traditional IT process to a product-centric way of working including: § § §

Moving from project to product funding Changing the IT relationship with business to a partnership Creating real ownership within product teams

Product Thinking & Process

This is a big topic I won’t cover completely here. But if you’re struggling with this, now’s the time to ask some good questions.

Cut up large products into product areas Apologies in advance to my vegetarian and vegan friends. This isn’t a vegetarian friendly metaphor. But, it’s just a metaphor, so bear with me. When I was at Trader Joe’s recently, I saw the sign in the picture to the right. I’m sure you’ve seen these in grocery stores or butcher shops. They tell you how a butcher disassembles a cow, sheep, or pig into the cuts of meat you see wrapped up in front of you. When you’ve got a big animal like a cow, sheep, or pig, we butcher it into smaller parts because it’s easier to buy and cook. You’ll need to do the same thing with your larger products.

Most mature products are too large to be managed by a single team. You’ll need a team of teams structure. It’s an uncomfortable truth that it takes 50, 100, 200, or even more team members to build, manage, and continuously improve a mature product. You’ll need a team of teams.

Organize your team of product teams You’ll need to “butcher your product” into smaller product areas where a team of 5-10 can manage and improve the area they own.

Large products are cut up into product areas each owned by a product team

Product Thinking & Process

When you cut up the whole product team into smaller product teams you’ll see a couple team types emerge: § §

Product area teams are responsible for an area of a whole product. Of course they’ll need to understand the whole product and where their product area fits into it. Platform or component teams create services that are consumed by other product area teams. Their first layer of customers and users are the product area teams that consume these common services. Product owners here are sometimes called platform owners and they know their job is to create components and services that help product area teams move faster.

Minimize dependency

Ideally each team can evaluate the quality of their product area, identify areas for improvement, and then release changes that improve their product experience all without needing to delegate work to other teams. Often it helps to: § §

Organize teams by user type: for example if you create a marketplace product, it’s common to have buyer teams, and seller teams. Organize teams around parts of the user’s journey: for example if you’re an eCommerce company, it’ll make sense to have a search team, a product page team, and a shopping cart team that map to parts of your user’s journey like “searching for a product,” “evaluating a product,” and “purchasing a product.”

There’s no right answer

I’ve got bad news for you. Bad news you may already suspect. There’s no right way to slice up a product into teams. We’re often choosing the least bad of a variety of bad choices. And, even worse, as your product grows and you add people you’ll need to re-organize teams. Pay close attention to the leadership, synchronization, and dependency management strategies below. Doing those things well helps ease the pain.

Whole product leadership Each product area team must own and continuously improve their product area. But, if they do this without driving to a common vision and strategy, you’ll end up with a franken-product.

Don’t build a franken-product: a product assembled out of different parts clearly built by different teams that don’t share a common vision Ideally it’s strong product leadership that creates that vision and strategy. Ideally they do that in collaboration with product team leadership and, of course, in collaboration with their organization’s leadership.

The team of teams product leader is often called a group product manager In some organizations product manager refers to the group leader, and product owner to the individual team leader. Whatever title you use, leadership is critical to help individual teams: § § § §

Share a common vision across product area teams Share common strategy and objectives across product area teams Coach individual product teams to help them develop vision and strategy aligned with overall vision and strategy Coach individual product owners and teams to help them improve their product design and development process

Product Thinking & Process

To keep decision making sound at the whole product, or team of teams, level, you’ll need user experience and technology leadership here too.

An architect and head of UX provide whole product engineering and UX leadership Just like a group product manager may be responsible for whole product vision and strategy, a head of UX must develop a UX vision and strategy, and an architect must develop and architecture vision and strategy. Head of UX and architecture must work across all product teams to develop and socialize that vision. They must support teams by coaching and helping them improve. Just as the core product team must work closely together to make good decisions, the leadership team must be strong collaborators.

Team of teams synchronization and planning While each team has its own share of autonomy, individual product teams are all part of the same bigger team of teams.

Product area teams must routinely plan and synchronize their activities with each other If you’re familiar with some basic Scrum process, you may have heard of a Scrum of Scrums – a routine standup meeting where one person from every team participates to share what’s happening across Scrum teams. This is an important tactical meeting. But you’ll need different meetings at different frequencies to support planning and synchronizing discovery and delivery work across your whole product team of teams. The table below gives some examples of synchronizing activities and different frequencies: Frequency

Purpose & activities

Participants

Example meetings

Tactical: multiple times weekly

Discuss ongoing discovery and delivery work

A member from each team

Scrum of scrums: 15-30 min

Core product teams

Bi-weekly OKR review: 60-90 minutes every 2 weeks

Core teams + other interested and relevant team members

Dress Rehearsal

Discuss dependencies Discuss opportunities for collaboration Every 2 weeks

Discuss ongoing discovery and delivery work Discuss dependencies Discuss opportunities for collaboration Discuss progress on OKRs Discuss emergent opportunities

Every 4-6 weeks

Integrate features and capabilities across dependent teams Demonstrate or simulate the use of the product with new cross-cutting capabilities

Product Thinking & Process

Quarterly

Review prior quarter’s OKRs and outcomes Discuss upcoming strategic goals Create OKRs or shared objectives

Core teams with participation from whole teams

Quarterly planning meetings: 1-3 days

Identify dependencies for strategic goals Rebalance and reorganize teams to address strategic goals and minimize dependencies

Dependency management No matter how well you structure your teams, there will be dependencies to manage. Synchronization events give teams the opportunity to detect and manage minor dependencies on their own. But, you’ll need some additional strategies:

Open source model

When a product team relies on another team to make a change in their product area, one way to handle this is to let the team needing the change to make it themselves. Treat the product as if it were “open source” where anyone can see and change the code – but only those with rights to “commit” and make the change permanent. Here’s how it works: § § §

Allow the team who needs the change to make it themselves Support the changing team with guidance and help – but don’t do it for them The owning team reviews the change and then accepts it, or asks the changing team to make some adjustments

Yes, this creates work for the owning team – but much less than being asked to add the work into their own backlog of work. Platform or component teams often do this since, by definition, other product teams depend on their product area. And, it sucks to be everyone’s bottleneck.

DRI: Directly responsible individual

Apple is known for creating the DRI or directly responsible individual role. Now I honestly don’t know much about how Apple defines it or uses it, I just know the role is a tough one. But I like the name, so I’m going to borrow it. When your team of teams has a large feature or capability they’re working on, one that crosses multiple product teams, it works to identify someone who’s responsible for shepherding that capability through. This is a “glube” concern – so you’ll need someone to connect all the teams working on the capability and keep them moving forward. A project manager may fill this role. Delivery managers or Scrum masters may step forward to take on this role. At Spotify the term “road manager” is used for this role and it’s often filled by a product manager who steps up to fill the role temporarily until the big capability is complete and successful. Ideally it’s a 1-3 month assignment.

Create an ad hoc mission team

If your team of teams has a capability to work on that crosses through several product teams instead of managing dependencies across those teams, try creating a perfect team with no dependencies. Here how it works: § § §

Charter a team focused on that new capability Give the team outcome-centric goals to achieve – an OKR works well here Ask at least one person from every dependent team to step forward to join this team

Product Thinking & Process

§ §

The team works together for 1-3 months until they’ve achieved their objective, or decided to kill the effort Team members then disband and return back to their home product teams

You may have tried something like this in your organization and referred to it as a “tiger team.” The most common name for this ad hoc team is a mission team. But I also hear pop-up squad, heist team, flex team, or boomerang team – because team members “boomerang” back to their home team. Some product team of team groups do this so frequently that at any given time at least half of team members are engaged on ad hoc mission teams.

Team-of-teams identity The concept of a team that takes pride in the product they own and create is critical to product thinking. But given how many people it takes to maintain and improve a mature product, and given the natural limits to how many people can work effectively together, you’ll likely need a “team of teams” structure. It falls on whole product and team leadership to help keep the team of teams identity healthy.

Leadership must strive to help everyone understand that we’re part of a large team of teams with a common vision and objectives.

Product Thinking & Process

6. Map & Evaluate Your Product Team Map your product team Use a product team map to visualize your product team, the product they’re responsible for, and who they must work with outside their team to succeed.

Why?

Working together as an effective team relies on everyone knowing their other team members’ skills and strengths. When a problem or question arises, a team member should go directly to the person who can help solve the problem. This is a different way of working than a traditional command and control organization where all problems are taken to “the boss,” a team leader or project manager. In an effective team, all roles collaborate.

When?

Create a map when chartering a new team, or reorganizing teams. Use a product team map to help orient a new team member.

How?

Use a quick collaborative activity to expose what you know, or don’t know, about your product team.

Who participates:

Involve your whole product team.

You’ll need: § § §

A whiteboard or large flipchart paper Sticky notes Markers

1. Create a product team canvas

Using a whiteboard or large sheet of flipchart paper, draw a canvas that looks like this:

2. Identify your team:

On the top, write your team’s name if you have one. Write down the product or product area your team is responsible for, which for some organizations is the same as the team name. If your team is responsible for an area of a larger product, write down the name of the parent product.

Product Thinking & Process

3. Identify your team members and their skills: Each member of the team: write your name on a sticky note.

Place your sticky note somewhere in the Venn diagram in the middle of the map. Think about your skills and interests: Are you more business focused? User experience focused? Technology focused? A mixture of some of these? For example: If you’re an engineer or tester, you may place your sticky note in the technology area. If you’re a front-end developer you might place your sticky note in the intersection of user experience and technology. Let participants place their sticky notes where they feel most appropriate. You may be surprised where people put theirs. Look for gaps in skills you’d need to have a balanced cross functional team.

4. Identify eternal deciders, experts, and executors: Outside leadership are the executives, heads of product management or others that provide guidance for vision and strategy. Write names of specific people in your organization that supply your team with high-level vision and objectives that your team must leverage in order to make good product decisions. Think about people or groups in your organization you must work with in order to release your product and continue to support it. In some organizations they’re referred to as “go to market” people. Write them on sticky notes and place them on the left side of the map. For example: you likely must work with sales and marketing at release time. They’ll need to know what you’ve released and when so they can sell it to customers. Customer service likely needs to be aware of what your team is releasing before it releases so that they can support it in the field. If your team is responsible for an area of a larger product, you may have other product area teams you must coordinate with to release. Write the names of those teams down here too. Outside subject matter experts help fill in knowledge gaps your team might have. You’ll likely need to supplement your understanding of how your business works, how the market works, regulatory or compliance rules, or deeper insights on your customers and their needs. Name the people your team relies on outside the team for expertise.

5. Identify customers and users:

Customers are the people who choose to buy or adopt a product. Users are the people who actually place hands on keyboards or fingers on touch screens. For some consumer products, they may be the same. For business-to-business or internal products, they’re likely different. For example, customers for Netflix might be the families, but the head of household is the decider, and users would include all the family members including parents and children.

Product Thinking & Process

For a large ERP system, we might name the kinds of companies that buy our product such as large multinational corporations. These are our customers. But there may be a huge variety of different types of users such as accountants, administrators, asset managers... Name each type of customer or user and write it on a sticky. Place the sticky note on the right side of the map. You’ll find the team members who know their business may be best at naming customers. You’ll find team members strong at UX can name the users.

Retain and communicate your results

Photograph what you’ve done. Place it in a shared team wiki or just on the wall in your team area. Adjust it as your team adds or removes members, or as the organization changes around your product team.

Alternatives and other practices:

Building a team map helps team members understand their team, their product and who they’ll work with outside the team. It’s a good team chartering activity. But there are others such as: § § § §

Team working agreement Team mission Key Performance Indicators OKRs

All these help the team work together to achieve their goals.

Product Thinking & Process

Evaluate your product team After you understand your team, where it fits in the larger systems of teams, and who it relies on to make good decisions and deliver, evaluate the strength of your team.

Why?

A characteristic of contemporary product development process is continuous improvement. Product team evaluation gives your team some criteria in order to evaluate and continuously improve.

When?

Use product team evaluation as one of your tools for team and process quality reflection. Use it routinely at an end of development cycle retrospective. Use it when you add or remove team members, or after reorganizing product teams.

How? Discuss each of the qualities below as a team.

Individually assess the qualities below on a scale of 1-5 where 5 is a strong “yes” and 1 is a strong “no.”

As team discuss your answers. If you answered a question with a 1 or 2, but, other team members answered 4 or 5, discuss your reasons for your rating. Where possible, try to agree on a team rating. But, it’s not agreement that’s important, it’s the discussion that is. After discussing your assessment, ask:

What’s the first simplest things we could change to improve our overall score? Together discuss the smallest simplest changes you could make that would improve the effectiveness of your product team. Focus on small continuous changes. You and your team likely can’t change your organization and culture all at once. But, I suspect you can find one small thing you could do to improve things today. Do that. Then check back in a few weeks and see how it worked out. Then repeat the whole process. The secret to big improvement is making lots and lots of small improvements.

Product Team Qualities: 1. Balanced Team

Do you have the people on your team you need to make good business, user, and technology decisions? Do you have the skills necessary on your team to design and create your product? When your team doesn’t have the expertise that it needs, does it maintain relationships with outside subject matter experts to help answer questions and help the team build its expertise? Every team must rely on outside expertise to make good decisions and at times to perform work. But, if your team often looks to outside experts or outsources execution to other teams or outside organizations, it may not be well balanced.

2. Mission and Shared Understanding

Does your team understand the product, product area, or platform components it’s responsible for? Everyone will need to understand who their customers and users are, how those users use it, and how your organization measure success. This gets messy in larger organizations where it takes lots of teams working together to build a whole product. Ideally each team understands their part of the product, and how that part fits into the whole product and product portfolio.

Product Thinking & Process

3. Healthy Leadership

Does your team have a strong inside leadership? A product manager, or product owner that acts as a collaborative leader is usually critical here. This person works collaboratively with those that best understand users and technology leveraging others’ experience and expertise to make good decisions. Do the most capable people work together to make good decisions and strive to include everyone? Or are decisions handed down without collaboration? Or, sometimes worse, are decisions made democratically where the majority without experience often overrule those with experience? Does your team have a healthy relationship with outside leadership? If your organization is bigger than a startup, you’ll rely on outside leadership for vision and strategy. Does that leadership help everyone understand the bigger vision for the product and the immediate strategic goals the organization is pursuing? Does that leadership focus teams on outcomes to achieve and not features to build?

4. Minimized & Managed Dependencies

Can your team make changes to its product area routinely with minimal dependency on other teams? Teams working on larger products and services must work with other teams to make sure their decisions work for the product as a whole. Given this constraint, can your team make and act on its own decisions? If your team is usually waiting on other people or teams for decisions or approval, the answer may be “no.” If your team usually can’t deliver a feature without working directly with other teams, your dependencies are high. Does your team have strategies for managing dependencies with outside teams? While we’ll try to structure teams to minimize dependencies, it’s pretty much impossible to eliminate them. Does your team have strategies for routinely coordinating with teams you must work with to ship a new feature or capability? Often a person or small group will look after these dependencies and orchestrate coordination across dependent teams.

5. Ownership

Does your team own product success? To do this, your team must work directly with its customers and users to learn about them and how they use the product. Can your team make changes to the product and deliver them to those customers and users? Can your team learn from those customers and users if those changes were used and improved their experience? Can your team take responsibility for the outcomes, good or bad, that come as a result of the changes it made? If the answer is “no,” “maybe,” or “sort of” to most of those questions, your team may not be able to take ownership of its product. In larger organizations this means coordinating with other teams responsible for other parts of the product, and that often share the same customers and users. Although those other teams may be responsible for other parts of your users’ journeys, you’ll need to work together with those peer teams to own the whole product. Ideally leadership one level above the product team helps a group of teams understand the whole product and how the parts fit together so they can own their part.

6. Continuous Delivery & Learning

Most mature organizations have some formality around releasing changes to its products. But, ideally that formality doesn’t slow down release much, especially when making limited small releases or tests. Given the rules in your organization, can your team ship changes to its products routinely and easily? If your team can’t ship without coordinating a release with other teams, or spends lots of time waiting for approval to ship, you may have challenges here.

Product Thinking & Process

7. Product Teams Must Collaborate Effectively As you worked together collaboratively, you may have noticed a few things you were doing that made it more effective. Even if you didn’t, I’ll point them out.

Sharing documents, or words alone, doesn’t work We may name the same features and agree we need them. We may agree on priority. We may agree on who our customer is. But, we’re often imagining different things.

It’s when we discuss our ideas more using words and pictures to explain our understanding that we can detect we have different understandings. It’s not that any one person’s understanding was the right one. We all bring useful information to the discussion. It’s combining and refining our respective understandings that lead to a common shared understanding. In the end we may still name the same features, priority, or customers, but now we actually mean the same thing when we do. This is the intangible state of shared understanding. The presence of a document doesn’t indicate we have it. It’s a critical quality for effective teams.

Shared documents are not shared understanding Build simple visualizations while collaborating Making our ideas visible helps us confirm others understand. Then others can add to them, build on them, and reorganize them. Together you’ll build a shared understanding that includes everyone’s contribution.

The goal of effective collaboration is shared understanding The details in the models and drawings are brief. You couldn’t share them with someone else and expect them to understand. Keep these drawings, photograph them, or shoot short movies with participants describing them.

Photos and videos of our simple models work like vacation photos. They help us remember. When you look at your own vacation photos you recall huge amounts of details that aren’t explicit in the picture. Someone else who wasn’t there won’t.

Product Thinking & Process

5 Collaboration Tricks 1. Visualize your thinking in simple models

Represent ideas with simple card models and drawings. Allow everyone to participate in drawing and modeling. Photographs and video recordings of simple models become mementos, like vacation photos, that help us remember more details of the conversation than we could ever record. To avoid lots of talking with nothing to show for it:

Think-write-say-place Our usual impulse when we think of an idea in a group is to simply say it. Don’t. Write it on a sticky note or index card first, and then say it as you place it in the shared model you’re all working on.

2. Say less

Let pictures, gestures, and the organization of cards do the communication. Finding common and precise language can slow down collaborative work. Brainstorm silently: While some people do well when brainstorming out loud, most don’t. Give everyone quiet time to think and then write or sketch their ideas. After sharing ideas, then build on and combine other’s ideas.

3. Intuition before analysis

You’ll be able to go faster if you don’t over think or deliberate decisions. Trust your intuition, especially as you begin collaborative work. Don’t spend time during collaboration deliberating or discussing if you should or shouldn’t add a sticky note, or where to move a card. Just add it. Just move it. Once you put your idea into the context of the other ideas, it’ll be easier to judge if it’s a good addition or not. And since your investment is low, it’s quick to remove if you change your mind.

4. Fewer People

Break large groups into smaller working groups of 4-6 people to discuss and model. Integrate and review results as a whole group later. For faster decision making and creating complex work products like UI prototypes, break into pairs or triads.

5. Time-box and satisfice

Use short time-boxes of 10-25 minutes to do work. At the end of a time-box, stop and reflect. Is your work good enough to proceed to a next step? If not, how many more time-boxes might you need? At the end of a time-box when you ask yourself: “Is this good enough for now?”. This is satisficing. Design and decision-making work can go on indefinitely. What’s more you’ll find you often need to revisit early decisions based on what you learn in later activities. Don't over-invest in early decisions. Satisfice. Working in small time boxes is described in the Pomodoro Technique. Break a larger task down into several small time-boxes. Use small breaks between time-boxes to recharge, check email, get coffee, and reflect on your progress.

Product Thinking & Process

Collaboration is difficult to scale 2-5 people can work together effectively given a goal, a time-box, and effective workspace that supports creating a shared visualization. 5-12 people need everything small groups do but add facilitation, and a simple structure to support their collaboration. Common Agile practices like planning poker are examples of facilitation structures that help groups work together effectively. 12 or more people will need what medium-sized groups do, and will likely need to break into smaller groups to work and then merge results.

Diverge before you converge The results of collaborative work will be better when you allow time to get more ideas and information into the room before making sense of the ideas, and converging on specific themes or solutions. Don’t prematurely shut down the generation of ideas and information. Remember, the middle is messy. Expect things to be chaotic just before they come into focus.

The divergent to converge flow from the book Gamestorming.

Product Thinking & Process

Plan and run collaborative workshops Involve a variety of people in short, 60-90 minute collaborative workshops. Together they can collect and make sense of information, and use that to find answers to problems. 1.

Plan workshops to include those who bring information in and those who need to learn and build empathy. For instance, workshops that include end users should also include development team members who need to better understand those users.

Facilitate workshops with an eye on participants being engaged and feeling productive. Make sure your workshop produces a visible model that helps build shared understanding. Photograph or video the results so you can better recall what you learned.

Consolidate what you’ve learned, and share it back with participants. Photograph and shoot short videos to quickly document. Convert photos to more formal documents as needed.

A workshop with good wall space to record, and lots of effective collaboration.

Immediately consolidate and record information collected during the workshop. Your memory of what was said fades fast.

Product Thinking & Process

8. Use Stories and Story Driven Development Throughout the Product Lifecycle The concept of a “User Story” is used to guide the delivery of your solution iteratively and incrementally. Use a story driving process to continuously build shared understanding and encourage problem solving within delivery teams.

Agile Stories solve two problems found in traditional document driven processes Agile stories solve two big problems with requirements in software development.

1. Documents aren’t effective ways to communicate: Effective story conversation builds shared understanding. Use conversations to build shared understanding and eventually agree on specifically what to build.

2. Requirements aren’t the same thing as value: Focus conversation on minimizing output, and maximizing outcome and impact. Focus conversations, especially early story conversations, on understanding users and the problems we’re solving for them. Strive to come up with the most economical solutions to user and business challenges.

Stories require changing the way you work, not the way you document You may use many traditional requirements specification practices such as use cases, workflow models, UI sketches or prototypes, or even UML. But use them in support of a conversation. Use the conversations to build shared understanding. Communicate that understanding with subsequent conversations.

The moment documents are handed off without conversation and storytelling is the moment you’ve fallen back to a traditional document-driven process. 38

Product Thinking & Process

You may be making using stories harder than it needs to be You made have been told that good stories must be written using a specific story template. Or, that good stories must be small enough so that several of them may be built in a single sprint or iteration. Or, that good stories should have acceptance criteria so we’re clear on exactly what to build. But, that’s not exactly true. Those qualities should be true before development work begins on any single story. But, ideas don’t come to you in that form. And they’ll get into that form only after lots of discussion and refinement. With luck, you’ll kill off many of the ideas that come in before they get to development. But, all those ideas are still stories. No matter how large. No matter how unrefined. No matter what format they’re written in. And, what’s more, those big vague stories are just right for early story conversations.

You don’t need to get stories “right” the first time. It’s story discussions with your team that improve them. This makes stories the most forgiving of approaches to specifying what to build. Continuously decompose and refine stories from idea to delivery Many mistakenly believe that the only good stories are those that are ready for the next sprint. In fact, guidelines for creating good stories are often misinterpreted to mean that it isn’t a good story unless it meets all those guidelines.

Stories start big and vague. It’s a product owner’s responsibility to collaborate with their team to: evolve, refine, thin out, and break down stories over time. The journey of story from idea to delivery is long. As a product owner and product team, you steward ideas from stakeholders, customers, users, your team, and yourself through this journey.

Product Thinking & Process

Use stories and storytelling from initial idea all the way to development. Decompose, cut away, and refine as you and your team work with them. You’ll use a variety of practices as you work with stories. In this workshop we’ll discuss the Opportunity Canvas, Story Mapping, and Story Workshops.

Early stories are about ideas or opportunities The big ideas people bring in or that you think of yourself deserve good story conversations. I call these early conversations Framing discussions. And, I like using an opportunity canvas to frame a new feature idea.

Use an opportunity canvas to frame new feature or capability ideas Use your framing discussion to make go or no-go decisions where “go” means you’re ready to invest time to learn more and move the story into discovery.

Break down big stories during discovery As you explore an opportunity for product improvement the discussions you have will help break that story down into lots of details and options. The story map is my favorite way to break big ideas down.

Use a story map to break big ideas down while keeping your user’s experience with your product in mind. Use the shape of the map to understand product user and help figure out what risky assumptions you’ll need to validate in discovery. Use the map to explore different release and development options.

Stories become ideal for development at the end of their journey These INVEST guidelines originate from Bill Wake. Remember:

Good stories don’t start with these qualities. They end this way only after lots of effort and collaboration with your team and the rest of your organization. Independent: The story should be independently buildable and testable, but we know that a single small story often can’t be released independently and be valuable to users and the business paying for it. Negotiable: Which is a bad word for the notion that good story conversations often change what we thought we’d build, coming into the conversation in favor of minimizing output while maximizing outcome and impact. Valuable: Every story when turned into working software has value. But each small story’s value comes from the learning we get as a delivery team. The really important value comes from the delivery of many stories in small viable features or releases. Estimable: We hope to create and finish a piece of work in a small amount of time, so we’ll need to be able to estimate it.

Product Thinking & Process

Sized Right, or Small: We used to just say small, but now we acknowledge that good stories may not always be small, that they break down in size during good story conversations. Testable: To really finish a story, we’ll need to verify that it’s done, usually with testing. But we know that there’s still more testing to do to verify the sum of lots of stories is still high quality. And, to really validate the sum of the stories we release delivers the outcome and impact we hope for.

The simple story lifecycle 1.

Card: Break your solution up into a set of small parts written on cards or sticky notes.

Conversation: Discuss each part with team members who’ll create the solution. Make sure the discussion covers who and why, and not just what to create. Make sure the discussion includes lots of words and pictures so that you build shared understanding.

Confirmation: Come to an agreement of exactly what you’ll create to turn this small piece into something finished. The bulleted list of things you’d check to confirm you were finished is called the “confirmation” or acceptance criteria.

Construction: Create the piece of the solution. Make sure the person doing the creation was in conversations that built shared understanding.

Consequences: Evaluate each small piece and make adjustments to the solution as you go. Write stories that describe the changes you’d like to make.

Product Thinking & Process

Sense 9. Use Data to understand product use and business impact Product Metrics: How Will You Measure Progress? The product success metrics you’ll need to pay attention to have little to do with how fast you’re building, or if your release is on time. Those things are important, but in the end what matters most is how your product performs in the market. Simple metrics funnels help you think through what metrics you could use to gauge success. For more on metrics funnels and metrics in general see Croll and Yoskovitz’s Lean Analytics.

The Pirate Metrics Funnel

The Pirate Metrics Funnel popularized by Dave McClure is one of many approaches to identifying and measuring outcome and impact. But, I’ve decided a funnel is the wrong metaphor – because nothing falls out of a funnel. We’re going to use a mountain instead – because depending on how steep the mountain is, falling and giving up on your climb is pretty common. Just like your users may be giving up on your product. Annotate this drawing as we discuss it.

Sense

Acquisition: How do customers and users find, evaluate, and choose to try the product? Activation: How do they get started using the product? Activation ends when they use it for its intended use and really see value from it. Retention: Do users keep using it? How frequently? Do they expand their use of the product to solve more of their problems? You’ll have to decide what frequency is typical. For some products it’s daily, for some it could be weekly monthly, or quarterly. Revenue: How do those users that use our product routinely earn our organization money? Save our organization money? Referral: How do users feel about our product? Do they say good thing? Do they recommend it to others? Or, are they using our product, grumbling, and looking for something better?

Leading and lagging metrics Notice how the funnel is organized by time left-to-right beginning with customer’s first encounter with your product. Notice also that there’s a bit of dependency. For example if users fail to activate, that is they try your product and never really see the benefit, then you likely won’t retain them. Notice how the metrics that might matter most to your organization are those on the right – especially revenue. But that’s the challenge. The metrics that matter most to your organization are lagging indicators. You’ll only see that revenue growth and great brand image after users have seen, tried, and then continue to use your product.

The metrics that matter most to your company are lagging indicators. If you only focus on lagging indicators, not only will learning if your efforts are paying off take a while, you’ll always find out too late when something is wrong. Your job as a product team is to help your company get those things it needs to sustain itself. To do that you’ll need to keep a close eye on the leading indicators that help you better predict revenue increases, or warn your organization if a decrease is coming.

Product teams must focus on leading indicators to know sooner if their decisions were successful Create whole product funnels, and single feature funnels You’ll need to think through how you’ll measure outcomes from every release. Whole product metrics will help you keep an eye on the health of your whole product. But, after a new feature is released, you’ll need to closely monitor feature specific metrics.

Sense

Enterprise class products? Internal products? Rethink the funnel For enterprise class products or products built for internal use inside your own organization, the user is usually a different person than the chooser: the buyer or stakeholder. Adoption by users is often mandated. You’ll need to think through what each step of the funnel means in this context. Here are a few suggestions for things to measure.

Acquisition: Do your customers find, try, buy, or adopt?

What does it mean to acquire new customers? What might it mean to get existing customers to try a new feature or capability? § § § §

Sales cycle length Win/loss rate Competitors evaluated Existing customers reviewing information on new features or capabilities

Activation: Can they get started using the product at scale?

Activation may be all the work it takes to onboard new customers, or even groups in your own organization. § § § §

Time to onboard new clients Amount of customization necessary by client Time it takes for all client/org users to begin to use the product Amount of training time needed

Retention: Do users continue to use it as expected?

Users might need to use the product as part of their jobs, but do they use all of it? Do they use it as you expected they would? Or, do they find workarounds to make their job easier? § § §

Client renewals Capabilities still used by client, or group of users within clients Expansion rate of the number users/seats within a client

Revenue: Does the usage of the product have a financial impact?

Do we keep earning money from our product? For things we make for ourselves, are we saving money or making people’s jobs easier? Try connecting feature usage with revenue or cost savings. Features that get used a lot likely contribute. Those that don’t may be hurting you. § §

Cost savings by using the software Efficiency – time to complete transactions or process work

Retention: Are users happy with the product? Are choosers?

Your users may hate the product but still continue to use it. Their level of satisfaction or dissatisfaction may signal bigger problems. § §

User satisfaction Buyer or business stakeholder satisfaction

Try different funnels or invent your own A popular favorite framework is Google’s HEART framework: Happiness, Engagement, Adoption, Retention, Task Success. But if you look close, those metrics aren’t organized in a nifty timeline. That’s why we started with McClure’s Pirate Metrics. As software development has become more deliberately productcentric, a variety of good metrics frameworks have emerged. Do some searching on line and you’ll find lots to choose from.

Sense

Focus on metrics that matter If you start identifying what you can measure, you’ll quickly realize that there’s way too much to measure. And, you can’t pay attention to all these metrics at once.

Choose 1-3 metrics that help you quickly assess product health and detect if your improvement efforts are working. KPI: a key performance indicator is a metric that you can pay attention to that lets you quickly see if your product is working as expected in the market. For products like twitter that might be the number of tweets per week, or average time spent reading tweets per day.

Look at the intended uses of your product and identify metrics that help you see the product is being used for that purpose. OMtM: The One Metric that Matters concept from Lean Analytics is valuable here. [http://leananalyticsbook.com/one-metric-that-matters/ ] Depending on where your product is in its current lifecycle, there are usually 1-3 metrics that you’ll need to keep a closer eye on. For example, if a product or feature is new, it’s usually important to pay closer attention to metrics that show the product or feature is sticky – that is metrics that show the users are moving from activation to retention. Because, if you can’t retain them, then there isn’t much sense in trying to get more users into the mouth of the funnel.

Sense

10. Use face-to-face observation and interviews to gather subjective data “Data is exhaust, not fuel” My friend Archie Miller, UX designer for CarMax, said this to me. I’m not sure where he heard it, but it makes sense. Data alone isn’t enough to provide the insight you’ll need to really improve your product. You’ll need to regularly spend face-to-face time with customers and users to understand the way they use your products and the challenges they face that may fall outside the user interface of your product.

Good data tells you what people do, but not why. This core product team at Kodak is responsible for a Kiosk customers use to print high quality prints of their photos directly from their digital cameras. They get the empathy and insight they need by watching customers use their product and talking directly to them.

Continuously interview and observe users, even when nothing is wrong I guess it could be possible your product is perfect as it is. And, maybe your users’ needs aren’t changing. Or maybe new users with different needs aren’t trying your product. Or maybe you and your product team already have deep understanding and empathy for your customers. However, if all of those things aren’t true, then you’ll reap big rewards from making it a weekly habit to interview or observe at least a user or two every week. Use weekly open ended interviews and observation to: § § § §

Continuously evaluate the product you have Identify opportunities for improvement Identify emergent customer needs Build deep customer understanding and empathy

Strategic research For your company to grow you’ll need to acquire customers you don’t have. You’ll need to solve problems you don’t currently solve. You may need to solve problems that no other company has chosen to solve yet. Use strategic research to § § §

Look at your broader market including customers not using your solution Look more broadly at how your solution fits in with your customers’ lives and other solutions they use along with yours Look at competitor’s products and how your customers use them

Since strategic research is broad and not always focused on a single product or product area, some organizations have dedicated researchers that do this work. It becomes their role to § § §

Share the insight and empathy they get with product teams Coach teams on doing better research Expose problems and opportunities your organization could be exploiting

Sense

11. Build simple models to understand your users and their product experience Your product team will need to build shared understanding of who your customers and users are, and how they work.

Use simple models like personas and journey maps to build shared understanding within your product team Segment your audience using differences that make a difference What differences in users’ goals and behavior would change the way they choose to buy and use your product? Use these differences as a basis for segmenting your audience. There are many ways to segment your audience. Look for:

Differences that make a difference Differences in the way people would use your product to meet their goals. A user with different needs is likely a different type of user.

Types –> profiles –> personas Segment your audience into types. Types could be based on job roles for business software, or the primary activities and goals people engage in for consumer software. Add information that you understand today about each type. This collection of information helps profile each type. Create an example user, customer, or company that uses your product by selecting representative data from your profiles. These examples are called personas for users and customers, or organizational personas for companies. Consider the product design implications of the information in your personas and the profiles you communicate.

If a detail in the profile or persona doesn’t impact the design, leave it out Leverage what you know today Sketch personas that leverage what you understand today. Create them collaboratively, involving team members and others inside your organization that have past user experience.

Call out your assumptions clearly so that you can plan your research to validate them. Personas, persona hypotheses, and proto-personas Personas we build based on assumptions and anecdotal experience are considered hypotheses. In practice a persona is never pure hypotheses or pure fact. In most product organizations, teams start with a mixture of data and hypotheses. After creating personas, discuss and identify what information is hypothesis, what the riskiest hypotheses are, and what you could do to validate these hypotheses.

Sense

Create a persona sketch that describes your target user As a group, discuss the audience segment that has a need that you believe you can address. Create a simple persona sketch: § Use information you heard when talking to others as well as assumptions and anecdotal information. § Speak in examples. Instead of saying “tech savvy” say “Uses an iPhone that he’s jail broken in order to run software not available through the App Store.”

User characteristics to Consider General information: § Age, gender, education, economic background § Subject matter expertise § Technology skills

Behavior: § Activities or work which users engage in routinely where your solution is relevant § Frequency: how often might they use your solution? § Collaborators: do they work with others to do the work? To share information? § Locations: where are they when doing things that might use your solution? § Other tools they use in conjunction with your solution, other tools they like using to get things done § Alternatives and work-arounds – the things they use instead of or in addition to your solution

Motivations: § Pains: what pains are your users trying to avoid? § Obstacles: what problems get in the way of users accomplishing their work? § Rewards & joys: what makes your users happy, delighted, pleasantly surprised?

Sense

Map Your Customer’s Journey Today A story map that describes a customer or user’s journey today is often called a journey map. It includes the steps they follow, but also questions they have, problems, joys, and other context that helps us empathize with them.

Create a map to build shared understanding within your design team of user’s journey today

Simple User Experience Map Recipe Use simple journey maps or story maps created on sticky notes to describe how your users do things today. Later, use the same map to describe how you envision them doing things with your solution.

1. Start by identifying users and activities Identify the types of users you’d like to focus on

Identify the activities your users will be engaged in Identify a starting point and an end point for your story

2. Tell users’ story using steps

Organize steps into a narrative: remember your narrative is never perfect for all users, start with a typical user’s journey Get to the end of the story, then go back and add alternatives and variations Add Activities: Activities help categorize lots of steps that help users reach a bigger goal

3. Add pains, and rewards

Where in the flow do users encounter big challenges? Problems? Where’s the fun? The payoff for doing the work?

4. Add details and context:

Other details and context may help you better understand your user’s story: § § § § §

Frequency: how often do users do this step? Many times daily? Daily? Weekly? Monthly? Rarely? Duration: how long does a step take? A series of steps? An activity? Location: where are users when they do this? Tools: what technology or tools do they use today? Other people: who else is there?

Sense

Focus 12. Product Vision is Science Fiction Imagine the world 5 years from now, or even 10. Imagine the type of technology that exists then. Imagine how people will be living then, what they do every day, what their interests are. Now imagine how your product fits into that future world. I bet that was at least a little hard. That’s what creating product vision should feel like.

Product vision isn’t setting revenue targets or creating a list of features you wished your product had. It’s imagining a future world with your product in it. And, that’s exactly why it’s a bit of an exercise in science fiction.

Your organization’s mission statement isn’t its vision. On Tesla’s website their mission reads: “Tesla's mission is to accelerate the world's transition to sustainable energy.” That definitely tells us what they want to accomplish – but reading it doesn’t help me, or any Tesla employee imagine what that future world might look like, or what kind of technology Tesla will be putting into that future world. The Tesla vision is in the stories Tesla’s founder and leaders tell. And, it’s not shared on their website. If you’re a product leader, you’ll need to get good at telling stories about a future with your product in it.

A “vision statement” or “elevator pitch” isn’t vision There are a variety of vison statement and elevator pitch templates out there. And they don’t work. This one for example:

For [target audience] Who [need, want] [Our product name] is a [market category] That [one key benefit] Unlike [competition or current situation] Our product [competitive advantage] You might have seen this one before. It nicely describes a product, who it’s for, and why it’s better than alternatives. Which is critical to know, and I hope you do. But, it doesn’t help anyone imaging the future 5 years from now. My friend Luke Hohmann correctly identifies this template as a product positioning statement. Because it positions your product relative to its customers, market, and competitors.

Vision paints an inspiring picture for teams working on a product To tell your product’s future story you’ll need a narrative or storyboard. You might communicate it in a white paper. You might try something like an article written about your company 5 years in the future. Or you might just tell great stories But whatever form you choose it should: § § §

Help listeners imagine a future world Be emotional and inspiring Motivate people and teams to want to make this vision a reality

Focus

Visiontypes: prototyped experience of your product vision In 1987 Apple created a short video describing their vision for the future. Today it looks an like an old science fiction movie in that old science fiction movies always guess the future slightly wrong. But in Apple’s Vision-type you can see the seeds of the iPad, FaceTime style video phone calls, and a way of working with it that feels like Siri does today. Microsoft’s 2019 concept video produced in 2011 explores lots of touch controls and new ways to interact with computers we see finding their way into its Surface products today. It’s now 2019. How did their vision hold up? How did it help steer their product development work?

Apple Knowledge Navigator Future Vision (1987) https://www.youtube.com/watch?v=JIE8xk6Rl1w

Microsoft’s 2019 concept video was produced in 2011 https://www.youtube.com/watch?v=bwj2s_5e12U

Your vision doesn’t need to be as big or as far reaching as Apple’s or Microsoft’s, but it does need to say more than how much revenue you hope to generate.

Contextualize vison for your team Unless you’re the founder of the company, you likely inherited the vision for the product you’re working on now.

To inspire your team, you’ll need to adapt the vision you inherited and make it real for the specific product or product area you manage You’ll need to tell stories, write narratives, or build visiontypes that contextualize the vison for your product area. It’s your job to inspire them. Just make sure your product or product area’s vision supports your organizations larger vision.

Co-create vision If your leadership isn’t good at telling stories, or your organization hasn’t written white papers or built visiontypes, you may not have a clear understanding of that vision. And, I guarantee if you don’t, no one else does. A common problem for many companies is that the organization has already achieved the vision that motivated the founder. That founder may not even be with the organization any more. That company today may be searching for a vision – searching for its place in the future. In the meantime vison gets replaced by revenue and growth targets. Start by imagining your product or product area in the future. Tell those stories to leadership and your team. Listen to their responses and feedback. If you’re vision isn’t aligned with leadership, they’ll tell you. So, be careful to make sure you’re not using any career limiting ways of communicating.

If vision is missing, co-create vision with leadership and your team. Focus

13. Product Strategy & Roadmaps Product vision is a distant view of the future with your product in it. Strategy is the step-wise approach to getting there. It doesn’t need to get you all the way there – just a few quarters out. Some organizations go out years. But you’re predicting the future here. Not just what your organization can build over time, but how your customers and users will respond to what you’ve built.

Use strategic thinking to describe how you’ll move your product towards your future vision Product Lifecycle: What Stage is Your Product in Now? Every individual product goes through a lifecycle of: market development, growth, maturity, and decline. This old model introduced by Theodore Levitt in 1965 is still drawn today. Although today you’ll see lots of folks trying to help you reposition your product into a growth stage, or extend the cycle. Because digital products can evolve quickly, they have the potential to really extend their lifecycle if they can be responsive to changes in the market. But, because digital products often have a shorter development and innovation cycle than traditional products, they can become irrelevant faster. Where is your product in its lifecycle? Are you trying to move it forward into “growth,” or keep it from moving into a “decline” phase?

Declare you strategic intent with your product. Then identify metrics that will help you know if your product is succeeding in its introduction, growth, or slowing its decline. Who is your product for? Who isn’t it for? In the HBR article “The Big Lie of Strategic Planning,” Roger Martin distills strategy down to 2 simple questions:

1. Where will you play?

What customers and users are you currently focusing on? The sharper the focus, the clearer the strategy. Apple’s first release of its iPhone targeted a premium consumer market. It was priced way above other consumer products. And, it didn’t have security features and email connectivity that competitors like Blackberry did for the enterprise and government market. Apple has generally been pretty sharp about understanding who its customers are, and aren’t.

2. How will you win?

What solutions will you offer this market that’re better than other options it has today? Your customers and users have other choices. Competitive products or solutions they invent themselves. We call those workarounds sometimes. How will your solution be better than those other options?

Focus

Declare who your product is for, and not for. Be clear about how your solution will be successful for those customers and users. If you intend to grow your product, say how If you’ve got an existing product, your directional choices are pretty simple. 1. Grow in your current market. If your product is in growth mode, focus on this. Trying other things can be a distraction. 2. Bring a new product to your current customers. If your growth with your current product has plateaued, this is a good idea. Having understanding, access to, and trust of existing customers will allow you to discover new products faster. 3. Bring your current product to new types of customers. Your product will likely need to change. Explore new types of customers and learn how to adapt your product or service.

bring%a%new% product%to%your% current%customers

launch%something% completely%diﬀerent%

new products

bring%your%current% product%to%diﬀerent% kinds%of%customers

grow%in%your% current%market

new markets

4. Bring something completely different to market. This strategy leverages your company’s product design knowledge and technical ablutions, but puts them back into a startup mode to discover new products. Every direction you move in this simple model will likely require that you add to or change your product. It may be obvious, but trying to go multiple directions in this model at the same time is a bad idea. At minimum it’ll spread what are likely scarce resources over multiple areas of your product.

Say how your organization intends to increase the impact of your product. Roadmap outcome and impact When you combine these ideas you can see that at each strategic move you’ll need to be clear about: § § § §

Which specific customers and users you’re focusing on Why you’re focusing on those customers – to grow in an existing market? to get a toehold in a new market? How your product will be successful with those customers and users you’re focusing on Metrics that will help you measure that success – look for leading indicators

Most organizations’ roadmaps are usually communicated as the specific features or capabilities we intend to deliver and when. You can see that knowing the features doesn’t help answer any of the questions above. Even worse, knowing only the features to deliver and not the strategic intent leaves your product team accountable for the output, but not really the business outcome. It’ll push you deeper into that client-vendor way of thinking.

Roadmaps should describe what you’re building, for who, why, and how you’ll measure success Focus

14. Tools for Keeping Focus Visible and Helping to Prioritize Options If I were to ask a product manager or any member of a product team what their biggest challenge is, at least half the time I’d hear “prioritization.” Prioritization is hard. And, if anyone tells you it’s simple, they’re lying. That said, if you get your head around the forces that drive prioritization, it will make your life a little easier. Keep in mind there are generally three types of prioritization you’ll need to worry about: 1.

What features or capabilities should your product team be focused on?

How much do we need to put into that feature or capability for it to be successful?

What specific items should our team be working on in the next week or two?

You’ll use product discovery work to best answer the second question. You’ll use tactical development work and development strategies to answer the third. We’re going to focus on the first one here: “what features or capabilities should your team be focused on?” The answer is actually pretty straight forward:

What outcome or impact is most important for you to focus on right now? Focus on the options that are most likely to achieve that outcome. Now identifying that most important outcome our impact isn’t trivial. Look to your vision and strategy for guidance. Or make sometime up. I promise if you do, leadership will correct you. Or, at minimum, it’ll start the kind of discussion you need to have. That most important outcome may take a few forms: § § §

A business problem to solve A KPI that needs to be improved A business objective that needs to be achieved

Focus product teams by giving them a problem to solve For product teams to take responsibility for the success of their products, they must take responsibility for successful outcomes. But, there’s a temptation for leadership to simply tell teams what to deliver based on their own beliefs and assumptions. This steals responsibility for success from the product team.

Don’t steal the responsibility for success from the team The goal: frame work as a problem to solve, not a solution to implement Why: solving problems allows product discovery to happen since we’re not dictating a solution to the teams How: identify current sub-optimal customer behaviors or changes in the market that could threaten the business in some way or provide a new opportunity for the business, determine where the current system isn’t meeting the goals to take advantage of or address these concerns, ask for improvement to the system/product with “improvement” measures as an outcome — a meaningful change in customer behavior

Focus

Try summarizing the business problem using a problem statement:

This problem statement is borrowed from Gothelf and Seiden’s Sense and Respond.

[Our service/product] was designed to achieve [these goals] We have observed [in this way] that the product/service isn’t meeting these goals which is causing [this adverse effect] to our business. How might we improve [product/service] so that our customers are more successful as determined by [these measurable changes in their behavior]?

Given the product team understands the problem they’re solving, identify leading indicators of success. The success criteria in the business problem statement are high-level and strategic — i.e., revenue, customer satisfaction, engagement, etc…often these are lagging indicators.

For the team to know if they’re making progress, look at specific customer behaviors that lead to business benefits. Then identify ways for the team to measure those behaviors.

Identifying business problems and leading indicators of success keeps your team focused on the right problem. The KPIs, or Key Performance Indicators, you choose reinforce your strategic intent A Product Scorecard identifies the 2-6 key metrics that your product team is currently focusing on. The scorecard will change as your product strategy changes. Expect to revisit scorecards at least every quarter. Look at this example eBay Scorecard from Marty Cagan. You’ll see 4 metrics that support an objective.

Increase the number of high-volume sellers at eBay through encouraging use of promotional seller tools. 1. Average revenue/seller Because we want to encourage sellers to sell more goods

2. Average promotional revenue/listing

Because we want to encourage sellers to promote their listings as aggressively as possible

3. Absolute number of high-volume sellers

Because we want to grow the number of high-volume sellers

4. NPS of high-volume sellers

Because we want the sellers to consider ours their preferred marketplace

Focus

OKRs help teams focus and prioritize work OKRs, or Objectives and Key Results, were popularized by Google and Facebook. Lately they’ve become popular in lots of organizations – maybe yours. OKRs are a great way to make your strategic intent clear. Create OKRs just as you might create a scorecard with 2-6 metrics that support an objective. Give each metric a specific target. Make the OKR ambitious - a stretch goal. You shouldn’t be too confident you’ll reach it. For each metric you choose, expect your confidence to be at 50% when you create it. Create the OKR for a short time period, usually 3 months. A 3-month or quarterly OKR should help your product progress towards its longer-term vision. Some organizations create annual objectives that quarterly OKRs move towards. Every week or two review your progress towards the OKR. At the end of the quarter score each metric from 1-10. Then average the score across all metrics. 60-70% is good. Remember you set metrics with only 50% confidence going in. Christina Wodtke’s “Radical Focus” is a good starting point for using OKRs in your organization.

Budget time across multiple sources of options Now, all this sounds great, but if you’re currently part of a product team, you know that things will come up that seem urgent, but aren’t aligned with your current OKR, or biggest problem to solve. Expect that. Things like OKRs that align with your strategic plans are usually created quarterly. And, they didn’t take into account the problem that came up over the weekend. Or, the feature you just shipped that, with a few simple changes, could be performing much better. How could your long range plans take into account those things? They just happened this week. Account for predictably unpredictable things by budgeting time for them. Successful product teams manage their time budget similar to the way you might manage a household budget. They might budget time like this: Strategic goals: This quarter’s OKR

60%

Responsive improvements Improvements options we see as we monitor metrics for items released over the past few months

20%

Bug fixes and emergencies

10%

Technical debt

10%

As a product leader and product team discuss how to budget time for the opportunities you’ll work on. After every development cycle, evaluate how well you’re living within your budgets. Adjust your budgets as necessary.

Focus

Discover (Respond with Tests) 15. Learn Fast, So You Don’t Have to Fail You’re sensing and focusing… You understand your users and the way they use your solution today. You understand their challenges, both inside and outside your solution. Doing that has generated lots of problems worth solving, and lots of ideas for solving them. You’ve identified your biggest challenge from a business perspective and can use that to help focus your attention on specific users and challenges – the users and challenges best aligned with your organization’s vision and strategy. Now it’s time to make sense of your best options.

Analysis, design, and testing To create anything new in your product you’ll need to do some analysis and design. The process you have today likely has a step where you do some analysis and design, and maybe some testing. I spent most of my career being fuzzy about what these words really meant. But, I’m less fuzzy now, thanks to some smart people, and years of getting it wrong. Research and analysis: are for making sense of the world as it is – the facts. There are lots of facts out there about your users and the way they do things, about your competitors, about your technology… the list goes on. It’ll take research to obtain those facts if you don’t already have them. It takes analysis to separate the important facts from noise and to recognize patterns in those facts. Design: is imagining how the world could be different – specifically if we were to add or change our product, how would that change the way people behave in the outside world. The changes we imagine, and how we expect people to behave differently, aren’t facts – just beliefs, or hypotheses. Testing: It’ll take a bit of humility to recognize that your beliefs might be wrong, that they are hypotheses. But once you do recognize your designs as hypotheses, then you can start being deliberate about questioning them. It’s testing your beliefs that generates more facts, facts that you can use to create better designs. Where humans often go wrong here is to try to do these three things thoroughly and in sequence. If you’ve been in technology for a while you’ve seen projects with weeks and months of research and analysis followed by weeks and months of design. This, of course, is followed by everyone falling in love with the design so much that no one believes it could possibly fail. After all, our analysis and design has been so thorough, why should we test? You know the rest of the story.

Discovery work is about doing just enough research, analysis, design, and testing so that we can move forward to invest in solutions with confidence built on facts.

Discover: Respond with Tests

It’s a loop, a fast loop

o Start by leveraging the facts you already have. If you’ve been continuously sensing, you’ll have facts to leverage. o Backfill facts with intuition and assumptions. That’s OK, because we’ll test them. o Consider many design solution ideas. Don’t just go with your first. o Combine and refine your best while focusing on the simplest solution that could work. o Elaborate your best design solutions just enough to expose your risky beliefs and missing facts. o Find fast ways to test those risky beliefs as quickly as possible. It’ll take a learning activity and maybe a prototype. o Take what you’ve learned from your tests and update you facts. o Repeat. If you’re used to being thorough, doing just enough may feel sloppy. But, I promise you that the first time you expose and test a belief, you’ll be addicted – even if your belief was wrong. You’ll wonder why you spent so much time focusing on facts that didn’t matter. You’ll wonder how you ever felt confident proceeding with building anything at scale without testing it first.

Make your first cycle fast – ideally hours. Strive to get around the loop as many times per week as you can. Exit when your beliefs aren’t that risky The goal of this loop isn’t to do it thoroughly, but to stop doing it. At some point you’ll decide the risks aren’t that large, and you can proceed to build your solution at scale with confidence. Or, the risks are too large and you can kill your idea with good evidence to support your decision.

Discover: Respond with Tests

16. Use a Canvas to Frame Product Improvement Options There will always be more possible products, features, or feature improvements to build than there is time to build them. Think of these ideas as potential opportunities. Before you begin to engage in deliberate discovery work with any opportunity, it’s best to size it up in relation to other opportunities you have. Framing also helps you constrain your design and discovery process to specific customers, users, and challenges to solve. Without these constraints, a design process can expand out of control very quickly.

Canvas approaches The “canvas” approach to looking at business models described in the book The Business Model Generation is an effective way for groups to work together to size up a startup business. You can use a similar canvas approach to sizing up product opportunities. Using a canvas approach has real benefits like: § Seeing important concerns of an opportunity in a single view § Seeing the relationships between these concerns § Building shared understanding, ownership, and alignment by working together and leveraging everyone’s knowledge As a product discovery team, fill out the canvas initially based on what you understand today. Use sticky notes to make it easy to change your mind as the discussion progresses. Iteratively improve the canvas as you learn more.

You could proceed through the canvas starting with the first box, and continuing to the last. However, if you don’t have good answers for a box, record what you do know, or your assumptions now, and proceed on.

Discover: Respond with Tests

Fill out canvas in one flow, read in another The boxes in the canvas are numbered in a logical order you could use for discussing an opportunity. But, if you’re sharing the canvas with someone else, you may want to read it left to right, and top to bottom. You’ll notice the left to right flow is from “now” to “later” in the output vs. outcome model introduced earlier. You’ll also notice that top to bottom moves from “users’ needs” to “business needs.” This isn’t a form to fill out. This is a set of topics to discuss and iteratively refine your understanding of. Remember: “design by community isn’t design by committee.” Involving lots of folks helps everyone learn faster. But, ultimately the go/no-go decision to proceed with an opportunity falls to the product owner. The best product owners leverage their teams to help make the decision, and usually find that they and their teams are in agreement.

Canvases and abstraction level Canvases like the Business Model Canvas or Maurya’s Lean Canvas are useful for thinking through new products. A new product needs to generate revenue, and will have costs associated with it. It needs to respond to a strong enough need from customers so that they’ll choose to use it. A new product needs to achieve some amount of product market fit. With existing products where we already have some degree of product market fit, we’ll look to improve the product by adding features or capabilities. The Opportunity Canvas described here works best at this level. Osterwalder’s Value Proposition Canvas is useful for discussing new features as well. Many companies create their own variations of canvases tailored to fit their organizations.

The Australian Football League (AFL) has tailored the Opportunity Canvas to meet their need.

Atlassian’s Experience Canvas blends ideas from several canvas styles.

Guidelines for filling out a canvas collaboratively: 1. Work fast

Sketch a canvas in a single sitting: 30-90 minutes with a small cross functional group. Don’t get caught in long debates over what the right thing is to put in a box.

2. Skip what you don’t know

You should find information you don’t know or can’t even guess at. That’s OK. Just skip the area for now. Come back to it later.

Discover: Respond with Tests

3. Guess

If you’re working with a reasonably experienced group, they’ll have educated guesses. Write those down, but note that they’re guesses. You could use more polite words like “hypotheses” or “assumptions.”

4. Plan to iteratively improve

If you’re honest with yourself, you’ll have vague items, missing items, and guesses. That’s OK. If you expected to have nothing to learn, then you’re likely fooling yourself. Make a list of those things you don’t know, prioritize the riskiest things first, then discuss specific things you can do to replace missing information or guesses with facts.

Opportunity Canvas Use an Opportunity Canvas to explore a new capability, feature, or enhancement to a product.

Here’s the flow of spaces in the Opportunity Canvas: 1. Start with User’s Problems or Solutions 4. Business Problem Ideally we should start with a clear problem we’re trying to solve. However, the world is rarely ideal. We’re often given a feature or enhancement idea and then need to work backwards to understand the problem. Start with what you have.

Solution ideas

List product, feature, or enhancement ideas that solve problems for your target audience.

Problems What problems do prospective users and customers have today that your solution addresses? If you’re building a product for entertainment like a game or tool to share fun stuff on a social network, they may not have a real “problem” to solve, just a desire to be entertained.

2. Users & Customers

What types of users and customers have the challenges your solution addresses? Look for differences in users’ goals or uses that would affect their use of the product. Separate users and customers into different types based on those differences that make a difference. It’s a bad idea to target “everyone” with your product.

What problem for your business is created when users have the problems you described above?

5. User Value

If your target audience has your solution, how can they do things differently as a consequence? And, how will that benefit them?

6. User Metrics

What user behaviors can you measure that will indicate they adopt, use, and place value in your solution?

7. Adoption Strategy

How will customers and users discover and adopt your solution?

8. Business Metrics

What business performance metrics will be affected by the success of this solution? These metrics are often a consequence of users changing their behavior.

9. Budget

How much money and/or time would you budget for discovery and validation? How much money and/or development would you budget to discover, build, and refine this solution?

3. Solutions Today

How do users address their problems today? List competitive products or work-around approaches your users have for meeting their needs.

Discover: Respond with Tests

Ash Maurya’s Lean Canvas Use a Lean Canvas to evaluate a new product idea. Lean Canvas is a more customer-centric alternative to the Business Model Canvas. Brainstorm multiple customer types and fill out a lean canvas for each. Use a Lean Canvas to evaluate opportunities from the perspective of different customer types. Fill in a Lean Canvas collaboratively as a group to build shared understanding about why you’re building your product.

Ash Maurya’s Lean Canvas model was adapted from the Business Model Canvas found in the book: “Business Model Generation”

Example Lean Canvas constructed with sticky notes on whiteboard. Example from Scott Torrance: www.startitlean.com

Components of the Lean Canvas:

I’ve shifted the order Ash suggests you discuss these, placing cost and revenue last. Remember that discussions of all these details are iterative. While you may discuss them initially in a particular order, each discussion may drive the need to learn more. Don't stop filling in the canvas if you don’t have an answer. Write what you do know, then come back with details when you have them. Iteratively improve the canvas. 1.

Target Customers: Specifically who is this product for? Top 3 Problems: What are the top 3 problems your product solves for your customers? How do they solve those problems today?

Unique Value Proposition: Single, clear, compelling message that states why your product is different and worth buying.

Solution: What are the top 3 features that make your product compelling to its target customers?

Channels: Who will market and deliver the product to your customers?

Cost: What will your solution cost to create, host, support, acquire customers… Revenue: What revenue will your solution generate? What are drivers for generating that revenue? How do increases in revenue affect increases in cost?

Key Metrics: Name 3-5 key metrics that help you measure product success.

Unfair Advantage: What unfair advantage do you have that makes it difficult for your product to be copied or bought elsewhere?

Discover: Respond with Tests

17. Use simple visualizations and collaboration for analysis and design Contextualize personas for each new opportunity You may already know who your users are. You may already have invested in creating simple personas.

Consider your users in the context of the opportunity you’re working on right now If your organization has invested in building well researched personas, use short persona sketching conversations with your team to contextualize them for the feature or opportunity you’re exploring right now. What information, activities, and needs are most important to consider? What solutions or consequences are there for those?

Sherif Monsour’s contextualized persona at Atlassian

Map your product solution Mapping a solution forces you to imagine your users’ world later, after you’ve released the solution. Imagine and map how the solution fits into their world.

Gary Levitt, founder of Mad Mimi – Gary’s first product story map

Discover: Respond with Tests

Create a simple storyboard sketch Start by using sketching templates to sketch a step-by-step flow of your product idea. For software solutions, you can sketch screens. But you could also sketch experience from a user’s perspective as a design comic. This works particularly well for service solutions.

A story map with context illustrations by Josh Seiden & Demian Repucci

A couple frames from a design comic created by Atlassian

Screen shots from the University of Pittsburgh’s “My Pitt” video prototype: https://vimeo.com/17887994

Create a solution map that combines words and pictures Use the sketches you’ve created to help identify user’s tasks when using the software. Once you’ve got the basic flow completed, play “whatabout”:

Discover: Respond with Tests

§ § § §

What other ways might the user go about reaching their goals? What happens when things go wrong? How else might we help our target user enjoy the product even more? What are behind the scenes technical things our system will need to do?

Write story names on sticky notes for each detail you add.

Team members in a classroom beginning to add stories to their storyboard sketch

Discover: Respond with Tests

18. Focus and Ideate to Consider Many Possible Solutions As a product design team you’ll need to converge on specific customers and users to focus on, and specific problems to address. Here are a few things to try that may help you converge: § § §

Discuss and choose a user type that you believe best serves your business concerns Slice the journey map by target user types to find pains, joys, and observations most relevant to specific user types Dot vote on the problems you think would be most beneficial to solve, or joys that you’d like to magnify

This still shot from the Google Ventures Design Studio video example shows how they created a simple journey map, annotated it with information and problems users encountered, then highlighted the specific problem area in the journey they chose to focus on.

Write a simple focusing statement Use a Stanford d.school “How might we” madlib

How might we help [type of customer] To [accomplish some goal or perform some activity] When [What makes it hard? What makes it rewarding?]

Ideation Your first idea is never your best, at least not usually. Ideation is a deliberate activity where you push yourself and your team to think past those first obvious ideas. You should come up with dozens of ideas, not just 2 or 3. You shouldn’t over-invest in any one idea – don’t spend too much time to create or communicate it. You’ll find the best ideas are combinations of multiple ideas from within your design team.

Use a Design Studio approach to sketch and sharing ideas Take quiet time to independently sketch your ideas. Push yourself to sketch multiple ideas. Move past your first obvious ideas – because they’re never your best. Describe your ideas with: § §

Words – tell a story Pictures – draw user interface, storyboard screens, storyboard a comic

Discover: Respond with Tests

Ideation round 1: write impossible or magical ideas

Take 2 minutes to list as many solution ideas for your target user that would require magic, or science not possible today. For example, you could use technology that reads minds, or transports users magically to a new destination. Review ideas in this round with each other. Ask, is there a way to “dial the idea back?” – to a version that would solve the problem in a similar way, but be feasible to build.

Ideation Round 2: sketch feasible ideas

Take just 5 minutes to sketch ideas you believe are possible. You could sketch: § Thumbnails of multiple ideas § Details of one or more ideas § A storyboard or comic that shows the steps of your target user using the software

Review ideas to find the best elements Go around your group, person by person.

When it’s your turn: § §

Explain your best idea in 2-3 minutes Make sure you place what you’ve drawn where people can see. Describe your idea by telling a story about the user of the product, and how they’d use it to solve a problem.

After you describe your solution, everyone discusses it for 2-3 minutes: § § § §

Give feedback from the target user’s perspective: “Claire would like this because…” or “How would that help Clair solve her problem of…” Build onto ideas in the sketch: “If we added this other idea we just talked about, this would be even better…” or “I could see going even further by…” Mark, or make notes of the ideas you want to keep and leverage in your next round of iteration, or your final solution. Make sure you record notes and comments on sticky notes as you say them, and tag the sketches with these notes.

Repeat this person-by-person pattern going around the circle several times until your group hits the end of your time-box.

Converge and Describe Your discovery team has deliberately come up with a number of potentially great ideas. It’s time to combine and refine those ideas and begin to describe the solution you’d like to create. Work together to combine your best ideas into a visualization that communicates the user experience of your product and a textual description that begins to chunk up your product into a backlog of smaller buildable product parts.

Discover: Respond with Tests

19. Declare your hypotheses Just discussing your idea may give you enough to write a hypothesis. Using something like an opportunity canvas to facilitate that first discussion will definitely give you enough details to write your hypothesis. Creating simple models like proto-personas, story maps, and solution sketches will give you even more details.

No matter how rough or refined your beliefs are, build a habit of expressing your ideas as a hypothesis. Distill your beliefs into a simple hypothesis statement The elements of a hypotheses are simple: 1.

The problem you’re solving and for who

The solution you’re imagining

The outcome and impact you expect to observe after delivering the solution

That’s it. Try using this template as a starting point:

We believe that [these customers or users] have [this problem or need], And if we build/make [this solution/feature/capability] they will [observable and ideally measurable behavior] Resulting in [measurable business benefit] My friend Jeff Gothelf has an even simpler format he likes:

We believe this [outcome] will be achieved if [these users] successfully [attain this user value] with [this feature/solution]. You may find your solution may be tough to fit into either template. Your solution may involve multiple users. Your solution may not require users to change their behavior at all. It’s OK to invent your own. Just be clear that you need to state the problem, solution, and the expected outcomes.

Discover: Respond with Tests

20. Identify & Design Tests If you believe you’ve got a customer with a problem or need you can address, and a great solution that will help them and your business move forward, then the next thing you need to do is to put on your negative thinking hat. It’s usually our confidence, or bias, that’s really our biggest risk.

You’ll need to be deliberate about exposing risks, assumptions, and questions and then identifying fast ways to learn and test them. Iteratively testing your hypotheses will also help you refine your product design.

We’re focusing on the “build” part of Lean Startup’s BuildMeasure-Learn cycle

We’ll step through the basics of these 5 steps 1.

Refine your hypothesis

Create or revisit your learning backlog

Prioritize risks and assumptions to identify the next most important thing to learn

Identify options that will allow you to learn fast

Select the option that allows you to learn with the least amount of effort, and plan your next best test

Step 1. Refine your hypothesis Your hypothesis includes: § § § §

everything you believe about your customers and users and their needs and challenges, the solution you think they’ll want and how it looks and behaves, how you believe they’ll use it to get benefit, and how their use of your product ultimately impacts your organization.

Discover: Respond with Tests

That’s a lot. You’ll usually represent it with lots of visualizations like personas, journey maps, UI wireframes, and anything else that helps you visualize and build shared understanding in your team.

Use a simple hypothesis statement to distill your beliefs, and help focus your next iteration around the validated learning cycle. Try using this template as a starting point:

We believe that [these customers or users] have [this problem or need], And if we build/make [this solution/feature/capability] they will [observable and ideally measurable behavior] Resulting in [measurable business benefit] Wrapped up in the “solution name” part are lots of conversations, sketches, prototypes, and past experience. But, your team will know what you mean when you write it.

Expect your hypothesis to evolve as you run tests. If it’s not changing then there’s a good chance you’re not learning, or you’re fooling yourself. Your hypothesis includes both problem and solution

In a traditional design process, we’d use deep research to inform our design ideas, and then validate those design ideas.

In an iterative, Lean Startup influenced process we leverage prior experience, insight, and assumptions to arrive at our solution hypothesis. Our tests usually have two sides: the first seeks to validate assumptions we’ve made about our users, the second seeks to validate assumptions we’ve made about our solution.

Discover: Respond with Tests

If you’ve been designing for a long time, this approach may seem risky. You might be concerned that if you interview or observe users when you have a solution in your mind, it’ll inject lots of bias into what you see or ask them. And, if you’re worried about that, you’d be right. That’s why when using this approach, we’re deliberate about designing our interview plans and approach to testing solutions, not to prove we’re right, but to prove we’re wrong. The mantra from people who do this well is:

Design like you’re right, test like you’re wrong. The rest of this section will help you test like you’re wrong.

Step 2: Build a learning backlog: identify assumptions, risks, and questions The learning backlog is filled with everything that stops you from being confident your solutions will be a success. It includes: § § §

Assumptions Risks Open Questions

You may have a list of these already if you’ve already been around the validated learning loop a few times. If not, you’ll start from scratch. To find assumptions ask yourself these questions:

What must be true about our customers, our users, and our solution for our idea to be successful? What must happen after our solution is released for it to be successful? Sometimes my head works better when I think of risks. A risk is the other side of an assumption. That is where an assumption might be that your users want your solution, a risk is that they don’t. Ask yourself:

Why won’t this solution work? What might go wrong after we release this solution that will make it unsuccessful? Brainstorming risks is sometimes called a “Pre-Mortem.” When conducting a pre-mortem, imagine your product did release and it went horribly wrong. Ask yourself:

“What were the bad things that happened after release that killed our solution?” Finally, look for open questions:

What open questions do we need to answer before we commit to building this solution? Sources for risks, assumptions, and questions Consider these sources for assumptions and risk – and any others you can think of:

About your customers & users: §

Problems, pains: do they have the challenges you believe they do?

Discover: Respond with Tests

§ §

Joys, rewards: Are they delighted by the things you think they are? Activities, uses: Do they engage in the activities you think they do? How often? When? Where?

About your solution: § § §

Value to your customer: Do they recognize your idea as a solution to their challenge? Can they imagine getting value from it? Usable: Will your customers and users be able to easily use the solution to solve their problems? Can they incorporate it into their work practice today? Feasible: Does your solution use technology that’s available? Affordable for you to build, and your customers to buy?

About stakeholders or regulatory compliance: § § §

Does your legal department see any challenges with your idea? Is there impact on operations? Customer service? Support? Sales? Marketing? Do business stakeholders see it as aligned with the organization’s vision and strategy?

Brainstorm assumption as a list of sticky notes. Remember: Think-write-say-place. Cluster your stickies and distill them as necessary.

Step 3: Prioritize risks and assumptions to identify the next most important thing to learn What assumptions, if proven false, will invalidate your hypothesis? Look for the big assumptions that if proven false, topple other assumptions. For example, if users don’t value your solution, usability won’t matter much. Look for assumptions that you’re not certain about – where it’s easy to imagine you could be wrong. What risks will sink your product idea? What are the biggest risks? What are the most likely? If you brainstormed assumptions and risks on sticky notes, you could try ranking them. Put those that worry you the most at the top. You could also try dot-voting where everyone in a group gets 3-5 votes to choose the risks or assumptions that worry them the most.

Try this 2x2 matrix to prioritize

Use the top-to-bottom axis for likelihood. For assumptions, the likelihood you’re wrong. For risks, the likelihood of the risk being real.

Discover: Respond with Tests

Use the left-to-right axis for severity. All the way to the right means that if this happens, it’ll kill your solution. Farther to the left means if it were to happen, you can think of ways to recover from it without pulling your product off the market, or your new feature out of the product. Like all these 2x2 matrices, it’s the quadrant in the top right you’ll need to worry most about. And, those things at the bottom left you probably shouldn’t pay much attention to. Choose the riskiest assumption – which could be assumptions or risks. Sometimes a few are clustered together because they seem related. You could consider these one big risky assumption.

Convert your biggest assumption or risk into a question. For example if your biggest risk is that your customers won’t buy the solution, reframe that as a question like: “Will customers buy this solution?”

Step 4: Identify options that will allow you to learn fast Take your riskiest assumption, or a few related assumptions and brainstorm ways you could test them – ways you could prove these are facts and not assumptions. Remember that brainstorming isn’t about finding great ideas, it’s about finding lots of ideas. Great comes later. Try brainstorming in rounds. Take a bit of silent time to brainstorm individually and then ask everyone to share-out with the group. Combine, refine, and build on your best ideas.

Build up a toolbox of test ideas It’s coming up with test ideas where your skills as a product discovery team will shine… or not. You’ve got a lot of choices for ways to test. And the best teams continuously invent new ideas and approaches. Thinking of the type of question you’re asking will help you identify different approaches to testing. Here are a few ideas, organized by question:

Do we really understand our customers and users? Their problems and needs? § § §

Interview users to learn about their challenges and goals today Observe how users solve the problems today with a competitive solution Survey users to ask them specific questions about their habits and preferences

Do customers want our solution? § § §

Tell a story about how a solution might work and get their reaction Show a simple paper prototype and get their reaction Advertise, or “pitch” the solution and check the response rate (sometimes called a landing page test)

Discover: Respond with Tests

Place a button or access to a feature in the product without actually building the feature (sometimes called a 404 test or feature-fake)

Can users easily learn to use the solution? Easily incorporate it into their lives or work? § § § § §

Have users perform a task using a simple paper prototype Raise the fidelity of your prototype to make it more realistic Raise the fidelity of your prototype to incorporate real user data Have users do their work in a more sophisticated live-data prototype Use a “Wizard of Oz” approach to fake parts of the functionality by using you and your team to do them manually behind the scenes

Can we build it predictably using the technology we have today? § § §

Build technical prototypes that explore technical constraints Gather data on possible technical approaches Explore and test your current code base to learn about its limitations

Consider other ways to find users to work with, and other ways to work with them Consider alternative ways to find users or test § § § § § § § §

Face-to-face – bring users to you or meet them in a coffee shop or conference room Face-to-face on site intercepts – go to where your users will likely use your product Remote intercepts – use tools like ethn.io to intercept customers using a live website Remote – use a conference call and screen sharing tool to show prototypes Remote asynchronous – use email to have a discussion with customers, or tools like Usertesting.com to test a prototype remotely and get data back Ask sales or customer service to connect you with your current customers and users Broadcast a request via social media – Facebook or twitter may be a good way to find people fast Friends and family, or even better, friend of friends. Try asking people at your company if they know someone who matches your target customers or users.

Co-create with your users to learn about problems and solutions § §

Use collaborative workshops like those found in Innovation Games, or Gamestorming Create a journey map with your customers to explore the way they work today

Take a bit of time to research online what others have done. Teams continue to discover novel ways to find users and test some very tough-to-test assumptions.

Step 5: Select the option that allows you to learn with the least amount of effort, and plan your next best test Now it’s time choose your next best test or two. You could just talk about it and choose one, but my favorite approach is yet another 2x2 matrix. Use the top-to-bottom access for the “quality of data.” An A/B test on your current commercial website can give you highly reliable data. A paper prototype shown to a few users will give you some data, but it won’t be as much – and the quality of data may be lower if the fidelity of your prototype is lower. Use the left-to-right axis for speed and cost where the fastest-cheapest approaches are all the way to the right. An A/B test released into a

Discover: Respond with Tests

production environment may take a little time to execute and collect data. But, a paper prototype could be super-fast. The top right quadrant of this model can be pretty lonely. We’ll get fast and cheap usually at the expense of quality of evidence. But, if you have ideas that are fast and cheap, and get you the data you need, jump on them! You’ll find that over time your experiments become a bit more time consuming because you’ll be tackling tougher problems.

Define and plan the details of your next best test To move forward you’ll need to sharpen your definition of your assumption. You’ll need to describe how you’ll test, how you’ll collect data, and exactly how you’ll determine when the test is done.

A test is done when you create it, run it, and have collected enough data to determine if your assumption is or isn’t valid. In Alex Osterwalder’s book, “Value Proposition Design,” he describes this simple template for distilling a candidate test idea:

Watch Alex’s video here: https://www.youtube.com/watch?v=cW46ySJmLD8 If you move forward you’ll need to identify the work you’ll need to do to create and run the test – work like: § § § § § § §

Create an interview plan Find users Design the UI for a prototype Create a prototype Collect metrics Interview users Distill results from interviews

These are tasks your discovery team will need to perform to actually run this test. And, these are tasks where you might ask for help from your whole team.

Rely on your core product team and your whole product team to help create and run tests.

Discover: Respond with Tests

Scale your approach to testing as your evidence and confidence increases In Giff Constable’s books Talking to Humans, and Testing with Humans you’ll find a simple chart that shows how increasing the time and money we spend to test increases the quality of evidence. It looks a little like this: So, if you want the very best evidence, then you should spend a lot. In fact, you’ll get absolutely conclusive evidence that your hypothesis was valid if you build and ship scalable software to all your customers. But, you’ll also risk the most.

Building and shipping scalable shippable software to all your customers risks both money and reputation. You as a product team, and your organization must ask yourselves “How confident are we that we’re right?” and “How much money and customer good will are we willing to risk?”

To use Constable’s Truth Curve, I like adding these additions: Consider the vertical axis confidence.

Asking “how confident are you?” isn’t always useful… some people are very confident without having much evidence at all. Let’s also ask ourselves and others to read the hypothesis statement, and ask yourself: “What would you be willing to bet that you’re right?” The choices here are things like: § § § § § § §

Lunch A day’s pay A weeklong vacation Your car Your house Your job Your right arm

And finally, let’s give ourselves a little wiggle room and widen Constable’s curve to give us a larger safe zone. That’ll make it easier to hit.

Discover: Respond with Tests

Now Constable’s Curve looks something like this:

Now here’s how you use the curve. Evaluate what you’d bet on the vertical axis, then follow that to the right until you hit Constable’s curve. That’s about how much money and time you should be spending to test your idea. If you’re currently building scalable shippable software, but you’d be hesitant to bet a day’s pay that your hypothesis would work, than that puts you well below the curve. Let’s label this area the “stupid zone” – because it’s stupid to risk lots of time and money on something you’re not confident in. I think we’ve all worked on teams and on projects where if someone asked you if this was a good idea you thought to yourself “no way.” Let’s stop doing that. Let’s expose our risk and uncertainty and try to stay in the “safe zone.”

Don’t build production software when you’re not confident you’ll get the outcome you expect. Don’t overspend to learn.

Discover: Respond with Tests

Right-Fi Prototypes A test is often, but not always, a prototype. When talking about prototypes, Bill Buxton, author of “Sketching the User Experience”, said:

“The difference between a high fidelity and low fidelity prototype is stupid; there’s only right fidelity, and wrong fidelity.” -- Bill Buxton, author of Sketching the User Experience Creating tests is an exercise in finding right-fi. You’ll recognize this as an application of the concept in Constable’s curve. The best product teams know how to do the least possible to learn the most possible. Inexperienced teams make the assumption they must build fully functional prototypes, or worse, move directly to shipping software.

Tests scale over time You’ll iteratively create and run tests tackling one or a few risky assumptions each time. Each test you conduct will likely change your solution hypothesis. Stop testing when you believe the risks are low enough that building a commercial grade product is a good bet. §

In very early discovery, your riskiest assumptions may be that users truly have the challenge you think they do. An interview and observation plan could be the best first MVP Test.

During active discovery you’ll likely be using a combination of interviewing and gathering feedback on prototypes that range from simple paper to higher fidelity electronic prototypes.

Later, when you’re confident you know who users are and what their challenges are, and they’ve seen and like prototypes you’ve shown them, then your next best MVP test might be a working version of your product that Customer Development Partners can put to use. From this you’ll learn if the decisions you’ve made about that product are accurate, and whether users can really put the product into use.

You’ll find the ratio of time spent on validating the problem to time spent validating the solution changes over time, too. This is a natural side effect of your biggest risks shifting from getting the problem right to getting the solution right.

Discover: Respond with Tests

You don’t need to test every hypothesis Before being deliberate about testing in discovery, many organizations didn’t expose or test their hypotheses. That sucked. Organizations that have embraced testing can swing a little too far the other direction too. It’s common to see people create prototypes and test everything, even when the risks of failure are low. Even worse, if their users are in real pain, they’ll have to stay in pain while the product team tests absolutely everything. That sucks too. Try this simple 2x2 matrix to decide if you should be testing your ideas, and how thoroughly.

Perceived value: How beneficial is this likely to be to your users? To you organization? Risk: How likely are you to be wrong? How much time and money are you putting at risk? And, very importantly, will it hurt your users or your organization if you’re wrong?

Test high value risky things I guess that’s obvious. But test until you can move hypotheses out of that quadrant.

Ship and measure the less risky things If being wrong doesn’t come with big consequences, it’s OK to build it, ship it, and measure the outcomes. You’ll likely need to iterate a bit before you nail it. Or you may have been dead wrong. Don’t feel bad if you need to pull back what you shipped. If it’s hard to pull back, then the risks may have been greater than you thought.

Discover: Respond with Tests

21. Interview and Test to Gain Empathy and Insight Talking to customers with or without a prototype or example is on of the fastest ways to test your ideas.

Use customer and user interviews to understand your users’ joys and rewards that motivate them, and the pains and frustrations that hold them back. Your goal is to look for insights that lead you to new problems you could solve, or new ways you could delight potential customers.

It’s a conversation, not an interrogation Your interview should feel like chatting with a friend. The best interview questions don’t actually sound like questions. Rather, they’re requests for your interviewee to tell you about the last time they did something, or a time when it went well, or went poorly.

Plan your interview To plan your interview, start with a list of what you want to learn: § § §

What do you believe is true that you’d like to validate? What questions would you like answered? What do you need to learn more about to better understand the people that might use your product?

Given what you need to learn, what stories or experiences can you ask your interviewees? It’s through listening to these stories that you’ll really get the answers to your questions.

Directly asking your users what you want to know often results in a leading question. Asking directly for the information you want often results in a leading question that doesn’t really get you the information you want. For example, if you believe it’s challenging for people to use your current product, and you want to know why, you may be tempted to ask: “What makes our current product challenging to use?” While that seems sensible, your interviewee will do their best to oblige and work hard to think of challenging things. But, in fact they may not believe it’s all that challenging. And, the parts that really are challenging they may have come to accept as necessary complexity. Better questions might be: “Tell me about the last time you used our product.”

Discover: Respond with Tests

“Tell me about a time the product really helped you.” “Tell me about when the product really got in the way.” The recent, best, and worst stories are easier to recall for your interviewee. And, out of them you’ll learn what really happened and not just what was challenging, but why. Confirmation bias is unavoidable. But knowing that helps you deliberately acknowledge it in your testing strategy.

Be deliberate about trying to disprove your assumptions. What questions could you ask to prove your solution won’t work, or to prove users don’t have the challenges you think they do?

Plan for a 2-part interview In an iterative, Lean Startup influenced process we leverage prior experience, insight, and assumptions to arrive at our solution hypothesis. In interactions with our customers we interview and observe to validate customer and user hypotheses, and then elicit feedback on our solution ideas to validate solution hypotheses.

Use the first part of your interview to confirm your beliefs about users and their behavior Use the second part to get feedback on your solution ideas Create prototypes or examples Design a prototype or example you could get feedback on that would initially help you validate your value proposition. Focus on the key areas that will help your users imagine the value they’ll get. Hint: It won't be a log in screen. Prototype your solution: Construct a simple paper prototype, or use a simple prototyping tool to create a prototype. Proto.io: Use Proto.io for simple, fast tap-able iOS and Android prototypes inVision: Use inVision to create simple clickable web and mobile apps: http://www.invisionapp.com/ Describe your solution: Create a simple storyboard or design comic that helps you more tangibly describe your solution. Or, create a landing page or promotional material that pitches your solution. These will help you test the value proposition. Instapage: Use Instapage to design a simple, measurable landing page: http://www.instapage.com/

Plan to ask for data you can use more objectively: § § § §

On a scale of 1-10, how likely are you to try this product? Prepare a list of 20 or so good and bad adjectives. Ask your customer to choose 3 that describe their impressions of the solution. Can we take your name and email address to contact you when our beta program begins? Can we take your credit card information to sign you up now?

Discover: Respond with Tests

Build your plan collaboratively My favorite approach to planning interviews is to pair with someone else and together work through these 2 things: § §

What do I want to learn? What questions or other approaches do I have for learning these things?

Put ideas in 2 columns. Prioritize what you want to learn. Consider multiple approaches to learning in the interview including: § § §

Asking for stories: recents, bests, & worsts Asking them to show you in their current solution Asking them to show you examples of their output

During interviews Record the facts and details. Record emotions using your users’ own words. These quotes are referred to as verbatims. Interview in pairs when possible, one to lead discussion, the other to take notes. Trade roles during the interview.

Tips for better interviews: o Use open-ended questions to steer. o Use closed questions to confirm, or to change the course of the interview. o Ask for stories: “Tell me a story about the last time you…”

o Ask for an example: “Give me an example of a time that this happened…”

o Watch and listen for emotion – that’s a signal that there’s potential value to find.

o Look for a chance to observe: “Can you show me how you do that?” o Ask for highs and lows: “Tell me about your worst experience…” “Tell be about your best experience…”

o When they ask for a feature, ask them the magic question – “what would you do if you had that?” o Take notes on paper – especially verbatim quotes.

Discover: Respond with Tests

Interview and test face-to-face Early in discovery the fastest way to build empathy and test your ideas is using face-to-face interviews. You can use traditional recruiting approaches to find people to interview. Or, if you’re building a consumer product, go to where you’re likely to find consumers with the right interests, and “intercept” them.

Photos courtesy of Kodak

Even remote interviews can feel “face-to-face” when you use cameras and screen sharing tools.

Photos courtesy of Carmax

This team interviews a customer hundreds of miles away, but uses a screen sharing tool to observe how their user works today, and to have them use and give feedback on a prototype for the solution they’re working on.

Discover: Respond with Tests

Simple interview and solution feedback flow Introduce yourself & your team Introduce your product Ask questions to understand how your users think and do things today

Hi, I’m …….. and these are my partners ……, and ……. We’re doing some research on [the general topic of the interview] to help us create a product that’ll help people [do something better]. We’re really grateful that you agreed to talk to us today. What we learn from you will really help us create a better product. Build rapport first by asking for simple examples or stories Lean in when they speak Make eye contact – don’t focus on your notes, and never record on a computer if you’re the interviewer Parrot to build trust, paraphrase to confirm understanding Don’t be afraid of the “awkward silence.” Be quiet, and the person you’re speaking with will fill in the space with their thoughts Be alert for goals, pains, and unmet needs you didn’t anticipate!

Bridge from learning to testing

“Thanks, learning about your experience has been really helpful.”

Test your solution

Help your user imagine themselves in front of the product: “Imagine you’re putting together a shopping list so you can pick up groceries on your way home from work…”

“We’ve been working on some ideas that address some of the problems you’ve described. We’d like to get your feedback on some of those ideas…”

For early conceptual testing: tell your product or feature’s story from a user’s perspective. Make the person you’re talking to the main character in the story. For later usability testing: after placing your user in front of the product, and giving them a goal, ask them to try using the product to reach their goal. Get excited to hear things you didn’t want to hear! These are the insights that lead to you finding and solving the real problem.

Wrap up

“Thank you! This has been really helpful for us!” Invite observers to ask any clarifying questions. If your partners have been patiently listening and taking notes, they may have questions to ask. Ask about staying in touch: “As we go back through our notes, we often find we have other questions. Would you mind if we got back in touch with you later with those?” Give the user a small gift: an Amazon, Starbucks, or Visa gift card works great. Ask for a referral: “Do you know anyone else that you think would be a good candidate for us to speak to?”

Discover: Respond with Tests

22. Keep Learning from Each Test Visible You’ve conducted your test. Now, it’s time to pull together what you’ve learned, rethink your assumptions about your customers, and users, and reconsider or redesign your solution.

1. After the interview, make sense of what you’ve learned Dump and Sort what you’ve learned

After each interview or round of interviews, your team will need to build shared understanding of what they heard and saw, and what it means to your product. This simple dump-and-sort process is a good place to start.

Think-write-say-place

Make sure you externalize your observations and ideas. Write it before or as you say it. Avoid “think-say” or just “say” without thinking. Think about these things: § § § §

Observations – they said this, they do this, they use this… Inferences – I think this means…. I think they feel…. Ideas: a good solution would be – I think they need this – They said they want this Insights – dependencies, correlations, surprising information, counter-intuitive observations

Comb through your notes, and write a sticky note for everything that seems important to you. Say what you’ve learned out loud as you place them on a wall or on a tabletop. Tell stories, and give more context as you place them.

Cluster and distill

As you and your team members begin to place your stickies, you’ll see common themes emerge. Cluster them. For each cluster write a distilling statement: a statement that you could read in place of all the other notes. This statement usually synthesizes the ideas in the cluster of notes.

Discover: Respond with Tests

Create an empathy map to organize what you’ve learned

An empathy map is a simple way to organize what you’ve learned from a user’s perspective. Start with a simple model like the one in the figures below. Think about and add in sticky notes saying what potential users are: § § § § § §

Thinking & feeling about their worries or aspirations? Hearing while using our product, from their friends or boss? Seeing while using our product in their environment? Saying & doing while using our product in public or in private? Experiencing as a pain point or fear when using our product? Experiencing as a positive or gain when using our product?

Look for key insights that’ll help you identify a better solution Insight: provocative statements about human behavior expressed as universal truths -- definition via John Kolka author of Well-Designed: How to Use Empathy to Create Products People Love

2. Distill what you’ve learned across tests to find changes to make to your hypothesis Summarize results in using a Delta-Next 2x2 matrix Think about what you knew and believed before the interview and test:

Δ- What did you believe that you no longer believe?

Δ+ What did you learn that you didn’t know before? ? What questions do you now have that you should take up in your next customer test? What solution ideas do you have that you’d like to explore in your next customer test?

Discover: Respond with Tests

3. Rethink your assumptions Your personas and journey maps contain your starting assumptions about your users and the way they reach their goals today. Look back at them now. I promise you that there’s information in them that you’ll want to change.

Your starting assumptions about users and the way they work never survive your first test Adjust your personas and journey map. Or, throw them away if they’re irrelevant. Keeping bad information displayed will only slow you down. Look back at your opportunity canvas and adjust your initial assumptions. Expect the problems you’re solving and your target customers and users to change at least a little. Other things will change along with them.

4. Refocus Look back at your hypothesis statement. Is it still correct? It’s likely it could use some refinement if this is your first iteration.

5. Rethink your solution How much does what you learned change your solution? You may need to make just a few changes and refinements. Or, you may want to go back and run a Design Studio session to sketch a new batch of ideas to work with. Sketch new ideas, describe your new solution, then design your next prototype or example to test.

That’s a whole validated learning cycle Congratulations! You’ve just completed a cycle. As you continue to iterate, your prototypes will progress from testing for value to testing for usability, too. As you become certain you’re on the right track, you should consider building prototypes to test for feasibility. After a few iterations, you’ll need to scale up your prototypes to using code and live data. When you’re pretty confident you’ve got a winner, build a backlog and begin building a production ready solution.

Pivot or persevere? Remember the “should we test this?” 2x2 from earlier? Based on what you just learned, reposition your hypothesis. Use its new position to decide to whether it’s time to kill this idea, or ship and measure. If too many assumptions are invalid, you may find you need to choose a completely different solution, a different customer, or a different problem to solve. That’s a pivot.

Discover: Respond with Tests

23. Identify A Release Strategy At some point you’ll decide that you’re confident enough to release something to users. Your organization is about to invest more time and money than it has so far. Think through your release strategy:

Strive for a series of small successful releases Remember that Robinson’s original definition of MVP was that smallest successful release – the one that would minimize investment and maximize return. The goal is to take out as much as you can and still be wildly successful. What Frank Robinson couldn’t easily do in the 1990’s and early 2000’s is to release many times in a short period of time to keep improving your product.

Your release strategy describes how you’ll release your product, feature, or capability to users and the outcomes you’ll expect to get from each release. Slice out your smallest successful release A story map is a useful tool for visualizing a whole feature or capability. Use the map to pull out everything you don’t need to be successful. Use the map to identify a series of releases where each release is successful.

MVP Target market & outcome Outcomecentric roadmap Recall Martin’s advice from “The Big Lie of Strategic Planning” – for each release ask:

1. Where will you play?

What customers and users does this release focus on? The smaller the subset of customers, the smaller the release is likely to be.

2. How will you win?

What solutions will you offer these customers that are better than other options they have today?

Discover: Respond with Tests

Build your release strategy around target outcomes For each release in your roadmap give the release: o o o o o o o

A simple name for the release Your release’s intent or purpose A target audience A high-level description of functionality Metrics you’ll use to evaluate after release The size or target date of your release Your plan for measuring AND talking with customers and users after release to evaluate product outcomes

It’s that last bit that’s important. If you’ve been in software development for any length of time, you know that:

What you deliver on your last release always changes what’s in your next Evaluate the outcomes of your last release to improve the next.

Decide to continue discovery or start delivery How confident are you that you’ll get your outcome if you proceed directly to development? If you’re very confident, proceed to creating a development plan. If you believe there’s significant risk that customers will value your product, that you can design something usable, or that your ideas are technically feasible, then invest time into validating your product hypothesis.

Release to learn before you release to earn For many organizations building and deploying software at scale is a risky, expensive endeavor. In that situation, you’ll need to be really confident before shipping anything at scale. But you’ve got another option.

Release to a small subset of customers and users to test your last best assumptions. Nail it before you scale it. Last-best tests are software we build to learn Ship to partner customers Sometimes the only way to be confident your solution is fit for your customers is to see them using it. But, we don’t want to ship less-thanviable solutions to all our customers and cross our fingers. We’ll use a small closed group of Customer Development Partners that fit an “early adopter” profile. These customers

Discover: Respond with Tests

will do more than try out our product. They’ll put it to use and give us feedback. We’ll use that feedback to “iterate until awesome.” Then we’ll ship it to our whole customer base.

Choose customer development partners that match an early adopter profile. Cultivate a pool of customer development partners. Good partners are customers that fit an early adopter profile. They’ll be willing to use a less than perfect product and to give you frequent feedback. Early partner customers must: 1.

Have the problem you’re solving

Be motivated to solve it – motivated enough to try less than perfect solutions

Find minimum and viable by shipping less than viable It may seem counter intuitive to release something that you know isn’t ideal to some of your most valuable customers, but it’s one of the fastest ways to learn what really is minimum and viable.

*"Artwork"and"concept"described"by"Henrik"Kniberg

MVP? somewhere around here

Eric from Liquidnet describes his strategy for finding minimum and viable.

When shipping a release to customer development partners, target outcomes are focused on learning and not adoption or growth

Discover: Respond with Tests

Holdbacks When you’re releasing to learn, there are lots of things you can pull out of your release: Functionality: Because what you’re shipping may be just enough to be valuable and useful to your friendliest customers, there are likely some things you can defer. Your friendliest of customers may use something less than perfect to solve their problem today. But, you won’t want to release it to everyone until it really is perfect. Scale: Since you’re releasing to a very small subset of customers, you may be able to defer some of the engineering necessary to scale to all your customers. Companies like Spotify routinely ship to a few percent of all their users. The can target specific geographies – so this allows them to defer localization efforts. And while a few percentage of Spotify users may be thousands, all of them is millions – so they can defer some of the work it would take to really run the solution reliably at scale. Operation: If you’ve recruited a small group of customers to use these early releases, you can defer some of the operational things you’ll need to onboard and support all of your customers.

When releasing to learn identify all the work you’re holding back. Ideally your releases to learn will be wildly successful. And when that happens you’ll want to scale it to everyone. Make sure you and your organization are aware of what that means.

Discover: Respond with Tests

24. Use a Lean Canvas to Distill Hypotheses and Identify Your Next Test Jeff Gothelf’s Lean Canvas Jeff Gothelf’s Lean Canvas asks you to start with the business problem you’re focusing on, and then shepherds you through considering multiple solutions and then finding your next best test. This canvas codifies the process Jeff Gothelf and Josh Seiden first introduced in Lean UX. Use this process to help your team frame your work as a business problem to solve (rather than a solution to implement) and then dissect that business problem into its core assumptions. Then weave those assumptions into hypotheses. Finally, design experiments to test your riskiest hypotheses. Download it at: : www.jeffgothelf.com/blog/leanuxcanvas Like all canvases, there’s a suggested order to working through it. But, you should feel free to fill it out in any order that makes sense, or change it to suit your needs.

1. Business Problem

What business have you identified that needs help?

2. Business Outcomes (Changes in customer behavior)

What changes in customer behavior will indicate you have solved a real problem in a way that adds value to your customers?

3. Users & Customers

What types of users and customers should you focus on first?

4. User Benefits

What are the goals your users are trying to achieve? What is motivating them to seek out your solution? (e.g., do better at my job OR get a promotion)

5. Solution ideas

List product, feature, or enhancement ideas that help your target audience achieve the benefits they’re seeking.

6. Hypotheses

Combine the assumptions from 2, 3, 4 & 5 into the following template hypothesis statement: “We believe that [business outcome] will be achieved if [user] attains [benefit] with [feature].” Each hypothesis should focus on one feature.

7. What’s the most important thing we need to learn first? For each hypothesis, identify the riskiest assumption. This is the assumption that will cause the entire idea to fail if it’s wrong.

8. What’s the least amount of work we need to do to learn the next most important thing?

Brainstorm the types of experiments you can run to learn whether your riskiest assumption is true or false.

Discover: Respond with Tests

Deliver (Respond at Scale) 25. Create a Development Strategy to Minimize Development Risks Once you’ve decided what should go in a product release, it’s time to break that down into smaller parts that can be delivered iteratively and incrementally. Use development strategies that help you deliver on time and at the quality you’ll need to be successful.

Use an iterative and incremental development approach Incremental-only thinking builds software the way a bricklayer builds a wall: Incrementing calls for a fully formed idea.

A more iterative allows you to move from vague idea to realization making course corrections as you go.

And, doing it on time requires dead accurate estimation.

Iterative and incremental thinking builds enough of the whole to see the big picture then incrementally adds more, while iteratively improving as you learn.

Create a development strategy that maximizes technical learning Given confidence that you’ve got a viable release, you’ll need to break work down into smaller stories that drive development while maximizing learning and minimizing risk.

Build your product up in layers, like a painter, to maximize learning and minimize risk.

Deliver: Respond at Scale

26. Plan and Workshop Stories Ahead of Development (AKA backlog refinement) Product team planning Ahead of every sprint, your product team will need to meet frequently to get ready. I’d recommend placing at least a weekly meeting on your calendars. Product teams that sit close together usually don’t need to schedule a meeting, they can just talk together throughout the day as needed. Use product team meetings to: § § § §

Review the progress of the release so far Discuss and add new stories you’ve discovered that should go into the current release, or be tossed back into the opportunity backlog Select stories for the next 1-3 sprints Identify all the work that needs to be done to get those stories really ready

Product team task board Keep the stories you’re working on visible in a product team task board. Identify and post the tasks you’ll need to complete to get those stories ready. opportunities & backlog backlog items to do doing done items

opportunity

split & refined backlog items

backlog item to get ready discovery team tasks

A product team task board often combines the stories we’re getting ready and the stories we’re doing discovery work for.

Workshop in small balanced groups 3-5 people is a good-sized group for workshopping stories. It’s difficult for more than that to work together productively. If more people are interested in participating, schedule time later to review and get feedback on the results, and make adjustments. Include: § § §

Someone who understands the software from a user’s perspective: Often it’s someone from the PO team such as a UX designer, business analyst, or the product owner. Someone who understands the code: Usually a developer on the team who has knowledge of the code and how to implement the feature you’re discussing. Someone who can test the product: Ideally a tester on the team that can ask tougher questions, help identify acceptance criteria, and get enough information to help them think about a good test plan.

Deliver: Respond at Scale

In the Scrum community, this group of people is sometimes referred to as “the three amigos.” Notice this group of three isn’t like the core product ownership team. During story workshops, QA plays a critical role.

Testers play a critical role in refining stories before every sprint It’s OK if the whole team doesn’t participate so long as those that weren’t there can learn from those that were later during the sprint.

9 Rules of thumb to improve your backlog refinement workshops: 1. Do it more often – try twice a week Plan to workshop stories or do backlog refinement multiple times a week. It’ll make the sessions quicker. And, if questions come up that the group can’t answer, you can do some research and bring the story back later in the week.

2. Make attendance non-mandatory When people are forced to attend a workshop they’re often unengaged. If they’re not engaged, you won’t have a good discussion, and leave with the shared understanding you need.

Ironically, including everyone with the hope that they all leave with shared understanding can result in no one leaving with shared understanding. As long as you have a small balanced group that includes someone who understands the functionality, someone who can build it, and someone who can test it, you’ll have a good discussion. Let groups know ahead of time what you’ll be talking about, and allow them to opt in, or leave if they’re not interested or engaged. If someone who wasn’t there needs details later, they need only talk with a team member who was there.

3. Keep the working group small Groups of 2-5 can have an effective conversation. If you more want to participate, try a fish-bowl facilitation approach.

Fish Bowl Collaboration Pattern

Use this approach to have productive, unstructured conversations when a large group wants to participate.

Deliver: Respond at Scale

§ §

3-5 work together in front of whiteboard or flipchart paper – they’re the fish in the bowl. Others may observe, but not speak. They’re outside the bowl. If someone from outside the bowl wants to participate, they can “jump in.” But, when one jumps in, another must jump out.

This way the conversation stays small and productive and others stay informed and involved. It's also a great way for learners to get up to speed without slowing down work.

4. Don’t project your backlog tool on the wall – use the whiteboard Everyone can engage sketch their ideas on the whiteboard. Everyone can add their own sticky notes with ideas. Use tools that allow everyone to discuss, visualize ideas, and engage. Even when working remotely, try to use tools, like google docs, that allow participants on all sides to make changes to a virtual document.

Talk & Doc Don’t let your words vaporize, especially during a story workshop. Use whiteboards, flipchart paper, index cards, sticky notes, napkins, or whatever you can get your hands on to visualize your thinking.

Draw pictures that describe the user experience you’re talking about. Record story tests on flipchart paper or whiteboard where everyone can see them.

Speak in examples

Remember if you’re keeping outcomes in mind, you’ll need to talk about who does what in your software. Don’t just describe what the software does; give specific examples of users and what they’d do in your product. Talk about: • Obvious examples • Typical examples • Complicated examples • Terrible, awful, no good, very bad day examples • Terrific, ideal, happy day examples

Deliver: Respond at Scale

5. Don’t start with acceptance criteria, take time to discuss and visualize how the functionality might look and work first It’s just hard to arrive at good acceptance criteria if everyone doesn’t have the same understanding of how the software should work. Take time to make sure you’re in agreement about how it works first.

6. Use acceptance criteria to confirm you have shared understanding After you’re reasonably confident the team has the same idea in mind about what they’re building, discuss how you’ll confirm you’ve built the right thing. It’s OK if this discussion results in a bit of back-tracking. That’s why you’re having it.

Acceptance Criteria

Acceptance criteria, or the “confirmation” part of the story, is our agreement on what it means to be done with the story. I like using these questions to drive out acceptance criteria:

1. What will we check to confirm this story is done? 2. How will we demonstrate this story at sprint review? For extra credit ask:

3. How will we measure success when this feature or capability is released? Answer these questions as a team with simple bullet points. You may go deeper with acceptance criteria by using approaches like Behavior Driven Development. Acceptance criteria formatted as BDD looks like this:

Given [some preconditions] When [a user does these steps] Then [we’ll observe these specific results in the product] A best book for learning to work together to create great acceptance criteria is Adzic’s Specification by Example.

7. Do talk about technical details It’s OK for developers to discuss how they’d implement it and consider options. Because, if it’s expensive to build, we may want to consider alternative designs. Or, not build it at all.

8. Do estimate Discussing how complex it would be to build will help confirm you have shared understanding about how it works. It might force discussions of technical trade-offs. And it may change what you choose to build.

Deliver: Respond at Scale

9. Do split stories into the smallest testable parts possible Don’t expect stories to come into the workshop “right-sized” for development. This is what the workshop is for. Use the deeper understanding you’ve built during the workshop to break the story down into the smallest buildable and testable parts you can.

Remember, the value from each of these small stories likely doesn’t come from users putting them to use until many of them are built and released. But, as a team, you can learn from everything you build. So, make them small! Split and thin stories during the workshop As you discuss what the software could do, write those things down on sticky notes, one thing per sticky note. You might find that they become acceptance criteria, or smaller stories you could split out and build independently.

Play good-better-best

Describe a “barely-sufficient” version of the functionality, then ask what would make it better? And then, what would make it fabulous.

Meszaros’ simple splitting heuristic

Gerard Meszaros describes for simple buckets that almost every story can be broken up into.

Bare Necessity

Capability & Flexibility

Example: A form with only necessary fields and no validation

Example: a form with optional fields, date lookup tools, input translation on dates

Safety

Usability, Performance, Sex Appeal

For the feature to be minimally demonstrable – but not releasable, what is the minimal functionality?

What would make this feature safer to use? For both the user, and for the business paying for the software? Example: input validation, enforcement of business rules such as credit card validation

What would add the ability to perform the user task in different ways? Adding in sub tasks that are optionally performed?

What would make this feature easier to use? More desirable to use? Faster to use?

Example: auto-completion, sexy visual design, speed keys

Deliver: Respond at Scale

27. Support Predictable High-Quality Development Work with the team every day Product owners and product team members need to check in with the team every day or things can get off track quickly. During the sprint your day-to-day activities include: § § §

Listen in on standups Check in with individual developers on ongoing stories to give feedback and guidance Review finished stories

Keep development progress visible Burn charts can be used at both the sprint level, and whole release level.

Burn Up Chart

Burn Down Chart

Stories added 20

Stories added

Stories removed

10 10

5 5

Stories removed 1

Burndown chart

A burndown chart shows work remaining, but is sometimes difficult to visualize new work added.

Burnup chart

A burn up chart separates the work completed from the total work to complete. It’s easy to see when we’ve added or removed work.

Cumulative flow diagram

A cumulative flow diagram shows the specific state of all the work and makes it a bit easier to see bottlenecks.

Source: http://www.agilesherpa.org/agile_coach/metrics/cumulative_flow/

Deliver: Respond at Scale

Development task board

A team-level development task board makes it easy to see specifically what’s in progress and how close to “done” it is. backlog items

to do

doing

done

done backlog items

delivery team tasks

Tagged Story Map

A tagged story map allows us to see how much is done in a whole release and how much is left to go.

Evaluate Your Product’s Release Readiness Don’t release when all the scope you’ve defined is completed, release when you have enough.

Enough is a subjective evaluation the product owner will need to make with the help of the product team For stakeholders: Enough software may be the addition of a feature critical or capability that improves the business in an observable way. For commercial products, enough may be the addition of new capabilities or features that can help acquire new customers. For customers: Enough software may be the addition of a feature that will represent real value for them when they or their organization begin to use the new software. For users: Enough software may be the addition of software that allows them to reach one of their goals using your product.

100

Deliver: Respond at Scale

Evaluate release readiness

Evaluate the working product with Users and Customers While you may have validated portions of your product using prototypes in discovery, it’s critical to re-validate working software with users and customers before you ship, especially where value and usability are critical.

Deliver: Respond at Scale

101

102

Deliver: Respond at Scale

Balance Continuous Discovery and Development 28. Continuous Discovery and Delivery in Parallel Tracks There are [at least] two kinds of work in software development, and there’s no way around it.

Development work 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 Discovery work 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 overinvesting 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:

Balance Continuous Discovery & Development

103

It starts by describing what we believe is the problem we’re solving and for who, the solution It starts by describing: o o o

What we believe is the problem we’re solving and for whom The solution we’d build to solve it How we’d measure success

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 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:

104

Balance Continuous Discovery & Development

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.

OK, it’s really 3 kinds of work… 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’s happening all at once 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.

Balance Continuous Discovery & Development

105

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 Two tracks, not two teams 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 Dual-Trak Myths 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. 106

Balance Continuous Discovery & Development

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 productionquality 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.

Involve the team in discovery work I’ll come right out and say it: it’s foolish to leave developers, testers, and other team members out of discovery work. While discovery work may not be their primary expertise, there’s a great deal of discovery work they can do well. And, what’s more, involving them: § § §

Adds diverse thinking and ideas you wouldn’t normally get Helps build user empathy, alignment, and ownership to product outcomes in the team Smooths and speeds up the transition of work from discovery to development

There are several ways you can include other team members in discovery. Here are a few: § § § § § §

Include developers and testers when sketching proto-personas or making journey maps Include a developer or tester in user interviews and prototype testing Synthesize interview notes and other research data together Use collaborative design sketching approaches like design studio or sketchboarding to involve the whole team in ideation Scale up the fidelity of prototypes to include working code to help get better data in discovery Include developers in discussions about measuring outcomes – they’ll bring ideas in that help automate measuring

Balance Continuous Discovery & Development

107

Visibility and the discovery track Visibility and transparency are important characteristics of and Agile process. If it’s discovery and design you’re responsible for, you’re not helping your team if you keep it hidden.

Keep discovery tasks visible in a discovery task board

Discovery task board at Carmax

Keep your current hypotheses, design, and test results visible in an evidence board

“Work wall” from a product team at Carmax

Visualize Learning Velocity

Try approaches like the “Delta-Next” described earlier in this handout. Whatever you do distill what you’ve learned and how it’s changed your hypothesis after every learning cycle.

Key learnings in a “Delta-Next” 2x2 at Carmax

108

Balance Continuous Discovery & Development

Rethinking Scrum Ceremonies Sprint planning starts by talking about discovery work

Adjust your typical sprint planning meeting so that your first conversation is about the discovery work you’re planning on. Remember that discovery work can’t be planned like in detail like development work can. Hopefully you can complete a cycle of discovery in a few hours to a few days. And, what you learn from that discovery cycle will help you decide what you'd like to learn on the next cycle and exactly how you might go about it. But you won’t be able to predict what you’ll do in the next cycle until after you’ve learned.

If you can plan two weeks of discovery work in detail, you’re probably doing it wrong. Since you can’t plan the details of discovery, instead: § § § §

Discuss the opportunities you’re working on Discuss the risks, assumptions and questions you’re likely to tackle in that opportunity Discuss the types of work that the team could likely help with Agree on a time-box to budget team time for discovery work

Once you’ve agreed on a time-box to allocate for discovery, the team will better be able to predict how much development they can tackle.

In daily standups review delivery then discovery

Usually more team members are engaged in development work, talk about that work first. Then, switch to talking about discovery work. It’s OK for team members that don’t have any discovery work responsibility this sprint to leave if they want.

Try not to mix discovery and delivery conversations. They’re different kinds of work and it tends to confuse people. Start sprint reviews by talking about discovery

In a sprint review or sprint demo it’s time to show what we’ve done and assess the quality. Normally you might start by showing what was built. But, from now on, start by discussing discovery.

Discuss what you’ve learned and not just what you did You may have worked hard building lots of prototypes or interviewing lots of users. But, it’s not time to impress people with your hard work. Focus discussion on what you’ve learned. § § § §

What assumptions did you validate or invalidate? What important questions did you get answered? What are the next important things to learn? Will items in discovery move forward to delivery? Continue in discovery? Or, have we learned they’re bad ideas and we can kill them?

If you include business stakeholders in your reviews I’ve learned that they really love hearing this stuff. They usually really care about product outcomes and the work you’re doing to validate that you’ll get them is important. I’ve also learned that the last time I want critical stakeholder feedback is after we’ve spent lots of time and money building production quality software.

Balance Continuous Discovery & Development

109

Ebb & flow In most organizations all focus and almost all the pressure is on building more stuff faster. When your organization begins to give discovery and delivery equal visibility, you’ll find the organization will begin to value it more. When that organization sees discovery as equally valuable, people worry less when development velocity dips so more of the team can focus on learning velocity.

110

Balance Continuous Discovery & Development

29. Plan Discovery AND Delivery Use a sprint planning meeting to review the work you’d like to accomplish in the sprint, and create the plan to accomplish it. Agile processes like Extreme Programming and Scrum use time-boxed development where each development cycle starts with a planning session, and ends with review. In many companies, they’re some of the most loathed of meetings. They can be long and painful, and by the time team members leave the meeting, they’re often ready to agree to anything just to get out of the room. It doesn’t take a rocket scientist to guess that the quality of the plans they make aren’t so good. But, it doesn’t need to be that way. Here’s a simple recipe that should help you avoid the worst problems.

Development cycle planning recipe 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.

Prepare 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.

1. Choose delivery stories a cycle or two ahead

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.

2. Workshop stories ahead of time

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.

3. Review discovery opportunities a day or so before 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.

4. Invite the whole team

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.

Balance Continuous Discovery & Development

111

Plan 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.

1. Start by discussing the big goals

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?

2. Review the discovery opportunities you’ll be engaged in and agree on the amount of team time needed

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.

3. Review the stories you’ll be turning into deliverable software

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.

4. Set a time-box for the delivery team to plan on their own 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.

5. In small groups, create a plan for each story

Work in small groups that include developers, testers, and anyone else that has work to do to turn the story into working software. •

Discuss your approach to building each bit of software. Write out development tasks that describe your plan. But remember that you likely can’t anticipate everything. Be open to identifying new tasks as the development cycle progresses.

•

Discuss how long each bit of software is likely to take.

•

As a development team, decide how many of these stories can be successfully completed in the delivery cycle. Don’t forget to consider holidays and days off.

6. Together, agree on the plan

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.

112

Balance Continuous Discovery & Development

7. Celebrate

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.

Balance Continuous Discovery & Development

113

30. Standup to review and plan every day 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.

1. Discuss any team news or general announcements everyone needs to know The standup meeting may be the one time in the day that the whole team is together.

2. Discuss development work

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: • • •

What progress was made the previous work day What challenges might be slowing things down or blocking progress What can do together today to move things forward

While discussing development work it’s helpful to look at simple visualizations: • •

A task board showing the work to do, in progress and done Mock ups or visualizations of the software you’re building – this makes it easy to explain exactly what you’re working on

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.

This team at Atlassian holds their standup in front of a flow for the feature they’re working on.

114

Balance Continuous Discovery & Development

3. Discuss work to prepare for next cycle

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.

4. Discuss discovery work

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: • •

What are next tests, customer interviews, or work you’ll be doing to refine and advance your hypotheses. How can other team members participate?

A discovery task board at Carmax As with discussing development work, it’s useful to have visualizations to support the discussion: • •

Use a discovery task board that shows your current hypotheses, next most important question, and discovery tasks Keep an evidence board that shows personas, journey and story maps, user experience sketches, and any other information that supports your current hypothesis

An evidence board at Carmax 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

Balance Continuous Discovery & Development

115

31. Review Sprints with the product team Understand how to evaluate your work, your plan, and your process together as a team 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.

Team Product Review and Reflection Recipe 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.

1. Evaluate your current product’s health

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: § What 2-4 metrics are you currently paying attention to about your product or product area? § What are their current values? § How do they compare to what you expected? To the last cycle? To last month? To last year? Discuss any subjective data on your product: § Quotes from customers that came from discovery work, customer surveys, or customer support

2. Evaluate discovery work

Reviewing discovery is critical. Show what you’ve learned from your customers and users. o Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it, and the outcomes you expect if it’s successful. o Discuss how your hypotheses changed during this cycle:

116

What parts of your hypotheses were wrong?

What new facts did you learn that changed your hypotheses?

Balance Continuous Discovery & Development

What parts of your hypotheses were strengthened as a result of your discovery work?

o Discuss and show the work you’ve done to understand the problem and the solution. This may include things like proto-personas, story maps, or UI design. o Discuss and show prototypes and experiments you’ve run. Discuss what your customers and users are saying about your solution. If you have experiments that you deployed to a limited set of users, discuss any data you were able to get from measuring their use. o Discuss your learning velocity: the amount you’ve learned relative to the amount of effort you put into discovery.

3. Evaluate development work

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. o Discuss the quality of user experience. Not just how the UI looks, but how it feels to use. Is it as good as you expected? Grade yourselves on a scale of 1-5, with 5 being best. o Discuss the functional quality. Did testing go smoothly, or were there lots of bugs? Do testers expect to find more bugs as more software is added, or as they get more time to test? Grade yourselves on a scale of 1-5, with 5 being best. o Discuss the code quality. Did you just write code that will be easy to maintain and grow? Or, did you add to the technical debt you’ll need to clean up later? Grade yourselves on a scale of 1-5, with 5 being best. Write stories to correct quality issues you see in the product.

4. Evaluate your original plan

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? o Decide which stories are and aren’t done. This may be harder than you think. Having this discussion helps your team build a common definition of what they consider to be done. Does “done” mean there are automated tests? Does it mean that all manual testing is done? Does it mean that product owners or UI designers have reviewed it? o Total the number of stories you agree are done. You can total the stories, or the original estimates of your stories. This is your development velocity. o Total the stories started and not completed. If it’s a lot, it’ll signal you need to work on your planning. I call this amount the overhang. Someone I used to work with called it hangover, because it makes your head ache. o Discuss the amount of time budgeted on discovery work. Since discovery work was time-boxed, you need only evaluate whether you used the time you planned. Ask yourselves if you used more time than you budgeted? Using too little will hurt you later when you don’t have things ready to build that you feel confident in. Using too much may hurt your chances for delivering what you’ve committed on time.

5. Review and improve your process

o Discuss the way you worked over the last development cycle. Could you make changes to the way you work to: • •

Improve the quality of what you learn doing discovery? Improve the whole-team participation in discovery?

Balance Continuous Discovery & Development

117

• • •

Improve development quality? Improve your ability to predictably plan? To make it more fun to be at work every day? Because if you’re having fun, I promise you’ll be able to go faster.

Review any changes you made last development cycle. For each change should you: • Keep the change in place? • Take the change out? • Adjust it and try it again?

o Together agree on the specific changes you’d like to make during the next cycle. It’s best to make just a few changes. One to three is good. 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.

118

Balance Continuous Discovery & Development

32. Review product team progress with the organization and stakeholders Routinely review what you’ve learned and your progress with stakeholders outside your team. 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.

Stakeholder Product Review Recipe Purpose: Keep your product’s health, your discovery work, and your development 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.

1. Review your current product’s health

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: § § § §

What 2-4 metrics are you currently paying attention to about your product or product area and what are their values? How do those metrics connect to those that impact the business such as revenue, cost savings, or retention? How do they compare to what you expected? To the last cycle? To last month? To last year? What should you celebrate? What should you be watching out for?

Balance Continuous Discovery & Development

119

Discuss any subjective data on your product: §

Quotes from customers about your current product that came from discovery work, customer surveys, or customer support

2. Review discovery work

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. o Discuss each opportunity you’ve taken up briefly: whom it’s for, why we’re building it, and the outcomes you expect if it’s successful. Make sure you tie that opportunity back to the value proposition for your organization. o Discuss your hypothesis at the beginning of the cycle and how it changed during the cycle: o

What were you wrong about? And, what tests lead you to believe you were?

What were surprising new facts that changed your hypotheses?

What parts of your hypotheses were strengthened?

o Discuss and show the work you’ve done to understand the problem and the solution. This may include things like proto-personas, story maps, or UI design. o Discuss and show prototypes and experiments you’ve run. Discuss what your customers and users are saying about your solution. If you have experiments that you deployed to a limited set of users, discuss any data you were able to get from measuring their use. 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.

3. Review delivery work

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: o Review the solution’s target customers, users, and outcomes. It’s good to remember why we’re building this and what success means. o Discuss and show the results of stories built for each solution. Stakeholders will offer feedback. Hopefully if they had a chance to give feedback when you were doing discovery work, the feedback at this point will be “Yup, that still looks good.” o Discuss the stories holistically. If you’re using a development strategy like the Mona Lisa strategy explained in User Story Mapping Chapter 4, you’ll need to explain to them why the software looks incomplete at this point. Remember that they may want to see a square inch of a complete portrait, and not the software equivalent of a sketch of the whole canvas.

120

Balance Continuous Discovery & Development

o Share with them your progress toward getting this solution releasable. How much work is left? What have you learned while building the solution that will affect its successful delivery? 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.

Balance Continuous Discovery & Development

121

Appendices & Quick References Reading List Product Management, Discovery, and Design o Inspired: How To Create Products Customers Love, Marty Cagan o Sense and Respond: How Successful Organizations Listen to Customers and Create New Products Continuously, Jeff Gothelf & Josh Seiden o Escaping the Build Trap: How Effective Product Management Creates Real Value, Melissa Perri o The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, Eric Ries o Running Lean: Iterate from Plan A to a Plan That Works, Ash Maurya o The Startup Owner's Manual: The Step-By-Step Guide for Building a Great Company, Steve Blank o Lean UX: Applying Lean Principles to Improve User Experience, Jeff Gothelf o Talking To Humans: Success Starts With Understanding Your Customers, Giff Constable o Testing with Humans: How to use experiments to drive faster, more informed decision making, Giff Constable o UX for Lean Startups: Faster, Smarter User Experience Research and Design, Laura Klein o Lean Analytics: Use Data to Build a Better Startup Faster, Alistair Croll o Value Proposition Design: How to Create Products and Services Customers Want, Osterwalder et al o Change by Design: How Design Thinking Transforms Organizations and Inspires Innovation, Tim Brown o User Story Mapping: Discover the Whole Story, Build the Right Product, Jeff Patton o Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, Dave Gray, Sunni Brown, James Macanufo o Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days, Jake Knapp, John Zeratsky, & Braden Kowitz

Agile Development and Scrum Agile Software Development: The Cooperative Game, Alistair Cockburn The Art of Agile Development, James Shore and Shane Warden Essential Scrum, Ken Rubin Specification by Example, Gojko Adzic The Scrum Guide, Schwaber & Sutherland: http://www.scrumguides.org/ Core Scrum, The Scrum Alliance: https://www.scrumalliance.org/whyscrum/core-scrum-values-roles o Version One’s Agile Checklist: http://www.versionone.com/pdf/AgileCheckList.pdf o o o o o o

Websites and Newsletters o Pivot Product Hits: https://pivotservices.curated.co/ o Marty Cagan’s Newsletter: http://svpg.com/ o Mind the Product: http://www.mindtheproduct.com/

122

Agile, Scrum, & What You Need to Know About Process

Agile Development & Scrum Principles and process guide Agile Development is nothing new The origins of agile thinking are as old as software development. What we call “Agile Development” today is a contemporary word applied to a process style that’s been emerging since the 1970s.

Waterfall considered risky

More like a team sport, less like an assembly line

Scrum

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right (below in this case), we value the items on the left more (bold and above in this case). You can find the manifesto & principles at: http://agilemanifesto.org/

n’t to goal is er, the process, but b m e Rem an agile r highfollow istently delive our y s n to co lity software love. qua users ers and custom

Extreme Programming

Lean Software Development it’s gets this m u om Scr e fr nam paper!

The agile manifesto describes the values and principles that guide process decisions.

Values & Principles Guide Process

The principles of Agile Software Development, written the same time as the manifesto, give principles that help guide choices in how we choose to work.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

“Agile” identifies specific values and principles

Scrum was one of those agile processes. Today Scrum has grown in popularity. While teams may identify their process as “Scrum.” the way they work borrows practices from most other agile processes.

The principles of Agile development

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

FDD (Feature Driven Development)

In 2001 17 software professionals gathered to discuss what they had in common. They were concerned about the continued growth of formalized waterfall style process. These professionals disagreed on specific process, but agreed strongly on the values and principles that drive process creation.

“Under the rugby approach, the product development process emerges from the constant interaction of a hand-picked, multidisciplinary team whose members work together from start to finish.” – Takeuchi & Nonaka

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Adaptive Software Development

(Dynamic Systems Development Methodology)

In the 1986 Harvard Business Review paper “The New New Product Development Game,” Takeuchi and Nonaka studied a variety of product design teams and found that the most successful had derived a process that looked chaotic on the outside, but was ultimately faster and more effective at creating great products. They compared these teams workpractice to the sport Rugby.

The Agile Manifesto:

Crystal

DSDM

In his 1970s paper Winston Royce is credited with drawing the model we commonly think of as the “waterfall model.” But he drew the diagram in a progression on his way to more sophisticated models. He pointed out that you’ll need feedback loops between every phase, and feedback all the way from test back to requirements. Royce was trying to describe an iterative development cycle, NOT a sequential process.

“I believe in this concept, but the implementation described above is risky and invites failure.” --Royce

agile

Agile is a style of process and an umbrella term for lots of specific processes

7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Values & Principles

Values describe what s important to individuals, and collectively to an organization. Principles are the rules of thumb we create and use to make day-to-day process decisions.

Your Context

The process you follow needs to take into account your context. • Haw many people are involved? • How risky is the project? • How time-sensitive is delivery? • How difficult is the problem you re solving? • What does quality mean in your context?

New Knowledge

We continue to discover new concepts and leverage them to create new and better practice and tools. For example: • A system s throughput is only as fast as its slowest step so we use Kanban style boards to visualize the flow of work and find bottlenecks faster. • Product ideas are hypothetical until proven out after delivery so we use MVP Tests to validate product ideas before delivery.

Process & Practices

Practices like test-driven development support values like being able to respond quickly to change, and principles like technical excellence. Processes combine practices that support each other and are used by different roles.

Processes help many people coordinate their activities to accomplish a common goal.

Roles

Agile processes and Scrum use three super roles that satisfy the concerns of building the right product, the product right, and tuning the process so people can perform at their best. Traditional software development roles are often mapped to one or more of these super roles.

Scrum Master or Coach

Product Ownership

The scrum master focuses on process success

Product owners focus on product success

The Scrum Master focuses on making sure the process is working, that everyone understands and fills their role, that collaboration is effective, that visibility is kept high, and that the team keeps focus on the goals of the current sprint or iteration and product release.

A single person may have the title “product owner,” but the ideal product owners is a great leader. Since a successful product must be valuable, usable, and feasible, a product owner usually leads a small product ownership team that includes the skills and roles needed to be successful: • Product manager or business representative • UX practitioner • Engineer, architect, & tester

Remember these roles represent concerns we all share and not individual people. In healthy agile teams people will change hats from one role to another.

Product Ownership

Scrum Master

Build the right product

Help everyone keep the process working effectively

Process

The Delivery Team Team

Build the product right

This starting process builds from the essential Scrum Framework to add practices that wrap the sprint for product discovery, getting to ready, and getting to release.

Remember that process isn’t skill. Success or failure is up to the whole team. The right process gives just enough structure for teams to effectively collaborate.

Opportunity Backlog

Ideas to explore, and problems to solve.

View your organization’s roadmap not as fixed items to deliver, but as ideas to explore and validate.

Product Discovery

Using collaboration, design thinking, and validated learning answer the questions: 1. What problems are we solving and for who? 2. What will customers and users value? 3. What can users use to reach their goals? 4. What’s feasible to build given the tools and time we have? The speed of discovery is measured by cycle time of learning. Try to experiment and learn several times per week.

Product Backlog

Deliverable pieces of a product or experiment we’d like the team to build

Build

Learn

Artifacts

Measure

While discovering, use backlog items for high-fidelity prototypes or live-data prototypes that requires development time to create

If no one uses the artifacts, remove them because they’re likely not working.

Product Discovery

Pull from a backlog of opportunities use discovery work to identify the product you should build. • Understand the business motivation for building the product • Understand the customers and users that will use your product and the problems your product solves for them • Ideate: consider multiple solutions to solve your customer’s problems • Iteratively build and test prototypes with your customers and users • Use backlog items to develop higher fidelity and livedata prototypes where you’ll need development work • Describe your validated solution using stories in a product backlog you can use to manage the delivery of your software.

Work together to explore details and describe the software you want to build in the next time-box.

Product Development The product delivery team strives for predictable, high quality, delivery.

Product Team Planning

Story Workshop

Product team members meet with delivery team member regularly to work through story details and agree on acceptance criteria

opportunities & backlog backlog items to do doing done items

& observe

Artifacts, or things we see and touch. They help make information, ideas, and status visible to the whole team. Basic artifacts include backlogs, burndown charts, and task boards.

The team is composed of all the roles and skills necessary to build, test, and document software of sufficient quality that it could be released. This includes: • engineers • architects • testers • business analysts • UI designers • technical writers

The product team meets routinely to discuss release progress, select stories for upcoming sprints, and plan the work needed to get stories ready for the delivery team.

experiments

if your solution is viable

The team focuses on constructing a high quality product

opportunity

Sprint split & refined backlog items

backlog item to get ready discovery team tasks

Release Burndown

Makes release progress visible. How much is left to build before we can release?

Product Team Task Board Use to routinely plan and re-plan discovery work and work to get items ready to deliver.

Getting to Ready

To help the team move quickly and predictable, your product team lead by a product owner must better understand and describe the details of what to build. • The product team plans by identifying user stories 1-3 iterations in advance. They identify the work they’ll need to do to design and describe the software to build and makes the work visible in a task board. • Collaborating with the team using a story workshop approach to build shared understanding about what to build. Members of the product team and delivery team work together to answer these three questions: What exactly will be build? How will we know when we’re done? How will we demonstrate this new software to others?

Work together to explore details and describe the software you want to build in the next time-box.

The de turn bac wo

Dual-Track Development

Discovery work happens continuously alongside development work.!

Opportunities drive discovery

Scrum Master !

Discovery Track

Discovery cycles vary in length. They start with ideas, and end with learning. You may complete several cycles of discovery in a single week.

ct d

Discovery creates backlog items for experiments or software to deliver

Development Track

When you use Scrum for development, you’ll see the predictable delivery of working software every 1-4 weeks

Delivery results in working experiments or deliverable software

d ent be

Discovery Team

A product owner leads the discovery team that includes individuals that have the knowledge and skills to identify a valuable, usable, and feasible product.

Day

Individuals like lead engineers may be part of both discovery and delivery teams

ers am work nd e

Sprint

Sprint Planning

Sprint Review & Retrospective

A fixed time-box for delivering software usually 1-4 weeks

The product owner shows up “ready” with details for high priority backlog items. The team builds their plan and commits.

Delivery Team Task Board

backlog items

to do

doing

done

Demonstrate and critique the working Product

done backlog items

Discuss the Progress relative to the plan Reflect on the way you’ve been working (your Process) and change it as necessary

Use to routinely plan and re-plan delivery work

Sprint Backlog

delivery team tasks

The delivery tasks that turn backlog items into working software

Sprint Burndown

Reflect on what was done the prior day Plan what to do today Raise issues stopping progress

The smallest cycle of work – you can’t extend this one if you don’t finish what you planned

Daily Scrum

Potentially Shippable Software Increment It may take more software to be valuable to users, but it had better not require more testing and bug fixing

Customer & User Product Testing

Routinely validate the working software with genuine users and customers

Stakeholder Product Review Keep progress visible to stakeholders outside the team

Viable Product Release

Built iteratively and incrementally each sprint, this is the product that’ll get you the outcomes you want from the users you’ve targeted.

Makes progress visible during this sprint. Are we making progress?

Sprint

(Iteration or Development Time-box) Iterations (Sprints in Scrum) are short fixed time-boxes, usually 1-4 weeks. At the end of each iteration demonstrate finished, tested, high quality software. • The team plans the sprint by working through the details of what they’ll need to build • Keep visibility high during the iteration using a task wall or burn chart • Keep collaboration high between the product team and delivery team • At the end of the iteration use a product review to evaluate the product and discuss the pace of delivery, or velocity • Use a heartbeat retrospective to adjust your process.

Use Sprints to build software, measure, and learn. Use what you learn to improve your product, and the way you work.

Getting to Release The team may be confident in what they’ve built, but we’ll need to validate it with customers, users and stakeholders. • Take working software out to customers and users to test it. Is it valuable? Is it usable? • Keep progress and user feedback visible to stakeholders.

Continue validating the software you’ve built with customers, users, and stakeholders to avoid surprises at release time.

Learn after Release After the release monitor metrics and scorecards, and observe people using your product. Remember, your project may be over, but the life of your product has just begun.

The most valuable improvements to your product come from observing people using it today.

Monitor Released Software

Almost every day take a look at metrics , bug reports, and customer feedback for software you’ve already released

Product Backlogs Using User Stories User stories describe pieces of software to deliver in the language of someone who will use the software. A short story title is written on a card, sticky, or in a list as a token for conversation. Stories split into smaller stories and gain more detail over time and through many conversations with contributors in every role.

Capabilities or Features

Stories for upcoming iterations

• Name • Target customer or user • Value

Working tested software

• Priority • UI Design • Business rules • Acceptance tests

• Meets the team s definition of done

Minimal Releasable Software

At minimum a story needs: • Concise title • Description • Acceptance criteria

• Generates value from its use

This popular template helps to think through stories from a user and benefits perspective: as a [type of user] I want to [perform some action] so that I can [reach some goal]

Use this template as a thinking tool, not a writing format. Stories without concise titles become hard to organize, discuss, and prioritize. Think about who uses the software, what they ll do, and why.

Release-sized stories

Organize user stories as a map Organize large capabilities roughly in the order users use them. Decompose them top to bottom. This makes the backlog easy to understand and easy to prioritize.

A burn chart makes progress over time visible. A burn down chart shows work remaining, while a burn up chart shows work complete. Watching the slope of the curve on the chart lets us detect early if we re on track to finish all the scheduled work on time.

Iteration Story Points Story Points Story Points In Scope Completed Remaining Day 1 21 1 20 2 21 3 18 3 21 6 15 4 24 8 16 5 24 9 15 6 24 11 13 7 19 11 8 8 18 13 5 A spreadsheet houses 9 18 15 3 the daily totals 10 18 17 1

• Vetted with stakeholders, customers, and users • Evaluated for release readiness

• Detailed acceptance tests • Small enough to complete in a single iterations

Visible Progress Burn Charts

Validated product part

Small iterationsized stories

• Target release • Relative size • UI Sketches • Rough acceptance tests

Burn Down Chart

Burn Up Chart 25

Stories added 20

Stories added 15

Daily Standup or Daily Scrum

Daily, usually at the start of the day, the team meets for a short planning meeting. Keep the meeting less than 15 minutes. Focus the discussion on what it will take to meet iteration goals.

Stories removed

Stories removed 1

Each person think about: 1.What you worked on yesterday 2.What you plan to work on today 3.What issues you have blocking them from getting work done

Task Wall A task wall is used to visualize work in progress during the development cycle. Moving stickies across the wall helps the team coordinate, and signal progress to each other and people outside the team.

Stories In Queue

Story Tasks

Tasks In Progress

Tasks Complete

Stories Ready For Review

Stories Done

Agile Story Essentials Use cards as the tokens for the conversations you’ll use to plan, design, describe, construct, and validate your product

Stories are a diﬀerent way to work

In the late 1990’s Kent Beck had a simple idea to solve one of the biggest challenges in software development: communicating the details of what to build. By simply getting together and “telling our stories” we could build shared understanding in the minds of everyone involved. In the conversation we’d focus not only on what to build, but who would use the software and why. Our goal is to identify the most valuable thing we could most economically build.

Shared Understanding

Stories get their name from how they’re used and not how they’re written

When we all read the same document or hear the same discussed, we often imagine different things. It’s describing our understanding with words and pictures, and then combining and refining our ideas that leads to shared understanding.

!! ?!

Shared documents are not shared understanding

!! !!

Kent Beck, author of Extreme Programming Explained

Card

What I was thinking of was the way users sometimes tell stories about the cool new things the software they use does:

Conversation

Write your product ideas on cards, one per card.

“I type in the zip code and it automatically fills in the city and state without me having to touch a button!” I think that was the example that triggered the idea. If you can tell stories about what the software does and generate energy and interest and a vision in your listener's mind, then why not tell stories before the software does it?

Confirmation

Discuss your ideas with others. Let them ask lots of questions. Work together to come up with ideal solutions. The goal is to build shared understanding.

!! ?!

Bring models, personas, UI drawings or whatever you like into the conversation. Identify ideal solutions and draw new models. Work towards agreement on what to build. Record that agreement as a set of confirmation tests.

!! ?!

A story is a token for a conversation

Vacation Photos

The information, drawings, and models you record during conversations are mementos that help you remember many more details than you can capture. People that weren’t there won’t remember – just like they wouldn’t recall anything when seeing your vacation photos.

Consequences For every story in your backlog, put in three cards. The first is what you want, the second one is there to remind you to fix the first one. The third is to remind you to fix it again. You’ve got to iterate or you’re not doing it right.

Now we’ve got working software to learn from. Those who originally asked for it and the builders evaluate. But, the software was likely for other users. You’ll need to test the working software with them to see if it meets their needs. The goal is learning. And your ideas for improvement start the cycle again.

Construction

Developers, testers, and others equipped with information from conversations and the shared understanding that comes with it build and test the software.

What’s on the card

“Talk & Doc”

On a typical card you’ll find:

Bring models like workflow models, use cases, UI designs, or anything else that helps you explain the story. But, be prepared to modify it during the conversation.

Use story cards, or items in backlogs they way you might cards in a library card catalog. Write just enough information on them to help you find the rest of the details when you need to. Use the card or list item to organize stories, prioritize, and plan.

Short title!

One that’s easy to read in backlogs and easy say in standup meetings If you catch yourself referring to the story by it’s number, stop it

Description!

If the title isn’t enough, write a description. Try to include who, what, and why. The template could be handy here.

MetaInformation!

• Estimated development time • Estimated value • Dependencies • Status

You’ll have many discussions around stories with team members in a variety of roles. Draw pictures and record details as you do.

Draw on whiteboards, model with post-it notes, or record on flipchart paper during your discussions. Keep models from your discussions as mementos to help you remember the details discussed.

Before you build, agree on what you’re building Before the team makes a commitment to build software described by a story, agree on acceptance criteria for the software. Record the answers to these questions:

• What will we test to confirm that this story is done? • How will we demonstrate this software at a product review?

When writing story tests, use examples. See Gojko Adzic’s Specification by Example for valuable tips. Story cards arranged as a map with UI sketches added in.

Story discussions supported by flip chart paper & drawings

Acceptance criteria recorded on flipchart paper

Stories: Concept to Delivery Progressively split and refine stories as you move them from vague idea through to working software

Opportunities

Create an opportunity backlog from product ideas, and customer, user, and stakeholder requests.

Discovery

Use discovery to elaborate, design, and validate product ideas. Your goal is to identify the smallest viable product you can. Discovery work results in a product backlog.!

Delivery

During delivery you’ll focus on designing, decomposing, and describing backlog items.

Validation

Release

Enough to test with users

Enough to release

Stories you complete in a single sprint might appear insignificant to users. Gather enough finished tested product parts to validate users can reach a meaningful goal before testing.

Gather enough validate product parts that they sum up to a valuable product release.

Review finished software with the team and stakeholders. Validate product parts with customers and users.

After your software is released, continue to measure the product’s performance relative to its target outcomes. The most valuable opportunities come after seeing the product in use.

Slice your possible product backlog into what you’ll need for multiple viable product or feature releases.

Product Team Planning

Before spending time going into details on any idea, discuss who the product, feature, or improvement is for, what benefit it will bring by building it, and how much it could cost if it’s similar to other solutions we’ve built. Use the results of this conversation to prioritize opportunities, and to make go/no-go decisions.

Product discovery is the work we do to determine what we should build. Use discovery to answer questions: 1. What problems are we solving, and for who? 2. What solutions will customers and users value? 3. What are usable solutions? 4. What’s feasible to build given the time and tools we have?

When splitting stories, think cake

Use each story to describe an piece of software you can “taste.” That is, once you’ve built it, you should be able to learn something from having done so. Whole features may have value to customers and users. But, it often takes a few stories to add up to a whole feature. The steps for making software are development tasks. Demonstrable, testable software is the result of those tasks. If the software doesn’t have user interface, you’ll need to find another way to show that it works.

Stories

Delivery Tasks

Stories describe something you can delivery and evaluate

Delivery tasks give the “recipe” – describe the work someone needs to do to create the story

Decompose

The product team meets routinely to discuss release progress, select stories for upcoming sprints/iterations, and plan the work needed to get stories ready for the delivery team.

Story Workshop

Product team members meet with delivery team member regularly to work through story details and agree on acceptance criteria

Smaller stories often have similar recipes, just less of any one ingredient. For example all stories will have some testing, smaller stories should take less time than larger stories.

Target outcome Outcomecentric roadmap

Release Strategy During Discovery, try using a story map to slice a while product or feature into a series of viable releases.

Work like da Vinci to finish on time

When managing a release budget, split larger stories into “opening game,” “mid game” and “ending game” stories. Try to get the “big picture” as soon as possible. Early versions that are fully formed but immature allow early functional and performance testing. They allow earlier validation that your concept is right.

time Opening Game

Decompose stories into smaller deliverable stories

MVP

Some call these workshops backlog refinement or backlog grooming meetings. But they're really the story conversations we need to have

acquired product knowledge

Opportunity Assessment

Product Discovery

Early stories emphasize iteration and learning. We need to be sure we’re building the right product

Mid Game

End Game

Once we’re confident we have the “shape” of the product right, we begin to pile in value

Over time the value of stories begin to diminish signaling it’s time for release

Development Strategy Try using a story map to slice a feature into opening, mid, and end-game parts.

Story Map Concepts Use simple maps to visualize the stories you tell about your software

Users

A map tells a story about a type of person doing something to reach a goal. Make sure to include them in your map along with a little information about them. Try using lightweight persona sketches to describe your users.

User Tasks

User’s tasks are short verb phrases that are the basic building block of a map. If I ask you what you did earlier today when using email, you’ll likely respond with tasks like: • Read an email message • Respond to a message • Mark a message as spam

Activities

Goal-Level

Activities organize tasks done by similar people at similar times to reach a goal. For your email software activities might include • Going through my inbox • Configuring my email client • Organizing messages into folders

The actions that users take in order to reach their larger goals have a goal level themselves that’s tied to user behavior. Summary: lots of tasks done in support of a bigger goal. Functional: I’d expect to complete this task before taking a break. Sub-Functional: smaller things done in support of a bigger tasks.

Backbone

Activities and tasks at a higher goal level give the story map it’s structure. The backbone is arranged in a narrative flow. Smaller sub-tasks, details and variations hang down to form the ribs connected to the backbone.

As you read across tasks in the backbone, check to make sure that tasks are of a similar goal level.

Narrative Flow

The left to right axis in a story map is organized in the order you’d tell the story about your user to someone else. Of course any specific user might choose to do different things in a different order. Use conversation to explain the details and variations. If you’re looking for the precision of a workflow model, flow chart, or UML model, then a story map isn’t your best choice. A story map will take lots of conversation to use effectively. But then that’s the purpose of stories.

Release Slice

Use a tape line to identify slices of tasks that users might use your software for to reach their goals. The smallest number of tasks that allow your specific target users to reach their goal compose a viable product release. Use release slices to identify small experiments, minimal viable product releases, or a “walking skeleton” version of your product. Identify the target outcomes of your slice in a sticky note or card to the left of the slice.

Map Now & Later

Use a map to describe the world as it is today. Inject pains, joys and rewards, details and observations, and solution ideas. Evolve the map using design and discovery to describe the behavior you expect users to have in the future. Story maps are for understanding now, and imagining later.

Use r grea Tasks t sto mak Wr Use ite short r y them verb t stor phra later itles e y nice templa as you ses on ! r ly rig c t ht a e to writ story tit ards or fter les. stick e de “I If s ie righ want to cription you us s. t aft er “s ,” the ac s, the ta e the o th s t iv k fits at… ity fits ” nice ly

Details, Details... Break down high goal level tasks into: • Sub-tasks • Alternative tasks • Exceptions • Details

Down in the details of the map, it’s OK to include details about what UI might look like or what the system might do in the background.

Map the Whole System Map a whole process as it crosses through a number of types of users Story maps are for looking at the big picture

Story Map Process The story map evolves with your understanding of your users and your product solution

Frame

Before mapping, create a short product or feature brief to frame and constrain what you map. Think of this as the big story. What names the product, feature to add to a product, or problem you’d like to solve. Who names the different types of users who will use the product, and the “chooser” or customers who will buy it. For each user and chooser state the benefit they get from using the product.

Why describes the benefit your organization gets by building the product or feature. Say what users do and how their use leads to increased revenue or reduced costs.

Map the Big Picture

Focus on getting the whole story. Think “milewide, inch deep” The activities and high-level user tasks that tell the whole story form the backbone of your story map.

Identify user activities – groups of tasks that work together to support a common goal. Activities often emerge after you see more of the story. !

Start with the user type most critical to your product’s success. Imagine a typical day in your user’s life with your new product. Map the steps they take as user tasks left to right.

Add in additional users. As you follow the typical use of your product, you may find other types of users enter your story. Continue modeling their story left to right.

Explore

Fill the body of your story map by breaking • Play “wouldn’t it be cool if...” to help think of down larger user tasks into smaller subtasks and great product ideas. user interface details. During this phase you’ll add • Look for variations: What else might users of cards, split one card into two, rewrite cards, and the system have done? reorganize them. • Look for exceptions: What could go wrong, and what would the user have to do to recover? Use this phase to think “blue sky” about all the • Consider other users: What might other types great possibilities. Use this time to think of of users do to reach their goals? everything that could go wrong. Don’t worry if • Add in other product details like: Description your ideas are “in or out of scope.” You’ll of proposed UI; Business rules; Data elements deliberately move things out of scope later.

Slice Out Viable Releases

Slice your map into holistic product releases that span the users and use of the product. These slices form an incremental product release roadmap where each release is a minimal viable product release.

Involve others. Tell your product’s story to others that understand users and use. They’ll find holes in your story and help build it up. Tell your product’s story to software developers. They’ll point out risky or expensive areas, and add in great technology solutions.

For each release name the target outcomes and Impact. Outcomes and impact says how this release contributes to the overall goal in the “big why” that motivates building the product, and how users will behave in a way that helps us reach the goal.

For each release, identify product success metrics. Answer the question: “what would we measure to determine if this product was successful?” Ideally you’ll find specific changes in user’s behavior as they use the product the way your story map imagines.

Slice Out a Development Strategy

Slice the first release of your map into three or • Opening Game builds a “functional walking more delivery phases that allow you and your skeleton” – the simplest possible functional team to learn fast and avoid risk. Think of the version of the product. As you finish "Opening opening, mid, and end-game phases of a chess game" vet the product with users and other game. stakeholders. Begin validating performance and scalability. This development strategy will help you release the best product possible in the time constraints • Mid Game complete all major functionality you have. and makes existing functionality richer and more complete. Continue user testing and leverage feedback to adjust the product. Continue testing performance and scalability. • End Game refines the product in preparation for release. Continuously assess release readiness based on your release level product goals. Count on unforeseen work to emerge during this last stretch of development.

Plan the work necessary to refine stories.! Workshop stories with developers and testers to work through details and agree on acceptance criteria.! Plan development and testing.! Build and verify parts of working software.