5 Whys Template
Clearly analyze and understand the root of a problem or issue.
About the 5 Whys template
What are the 5 Whys?
The 5 Whys is a technique for getting at the root of a problem. Fundamentally, the approach is simple: you ask why a given problem happened, and then you ask four more times. But it is also much more than that. Toyota pioneered the 5 Whys technique as a critical component of its problem-solving training. By repeating the question five times, it becomes easier to get at the heart of the problem and discover a solution.
Why use the 5 Whys approach?
The 5 Whys framework allows you to have a focused discussion so you don’t get distracted by other topics. You simply start with a problem statement, examine why that problem exists, then continue moving through each problem until you identify a core issue that you can act upon. Keep in mind that it might not always take five rounds—just go through the activity until you arrive at a satisfactory conclusion.
How do you use the Miro 5 Whys template?
You can involve team members by asking them questions in chat or @mentioning them in comments. Use sticky notes to call out issues that are particularly important or require follow-up. You may also want to color-code the sticky notes depending on the urgency or severity of the problem or whose role it will be to take the next step.
5 Whys Example
Let’s say you’re trying to ship an app that your team has been working on. You were prepared to ship on time, but you were two days late. Here’s how you might use the 5 Whys to uncover the reason that happened and how you can avoid delays in the future.
Step 1: Start with the broadest possible question, then try to answer it. Why was the app late? It was late because there was a production delay.
Step 2: Based on this answer, you can narrow the question slightly. Why was there a production delay? There was a production delay because the engineering team had to deploy a last-minute patch, which the product team did not know about until launch day.
Step 3: Narrow the question even further, and then answer it. Why didn’t the product team know about the patch? The product team didn’t know about the patch because engineering didn’t communicate it to them.
Step 4: Keep narrowing and answering the question. Why didn’t the engineering team communicate to the product team? The engineering team didn’t communicate to the product team because they did not know how to communicate that information.
Step 5: Ask the question one last time to zero in on your solution. Why didn’t the engineering team know how to communicate to the product team? The engineering team didn’t know how to communicate to the product team because the product team has no clear point of contact or processes for communication.
To update your product in valuable ways—to recognize problem areas, add features, and make needed improvements—you have to walk in your users’ shoes. Example mapping (or user story mapping) can give you that perspective by helping cross-functional teams identify how users behave in different situations. These user stories are ideal for helping organizations form a development plan for Sprint planning or define the minimum amount of features needed to be valuable to customers.
Managing stakeholders is integral to completing a project on time and meeting expectations, so here’s how to use a stakeholder analysis to help. A stakeholder analysis empowers you to meet expectations and complete projects on time by identifying individuals, groups, and organizations with a vested interest in a program or process. In a typical stakeholder analysis, you’ll prioritize stakeholders based on their influence on a project and seek to understand how best to interface with them throughout the course of the project.
Many organizations use the Agile model, but even companies that don’t rigorously adhere to all Agile standards have adopted Agile tools and methods like Program Increment (PI) Planning. Even if you’re not participating in a formal PI session, a program board can be a great way to establish communication across teams and stakeholders, align development objectives with business goals, clarify dependencies, and foster cross-functional collaboration. The board provides much-needed structure to planning sessions, yet is adaptable enough to accommodate brainstorming and alignment meetings.
A website flowchart, also known as a sitemap, maps out the structure and complexity of any current or future website. The flowchart can also help your team identify knowledge gaps for future content. When you’re building a website, you want to ensure that each piece of content gives users accurate research results based on keywords associated with your web content. Product, UX, and content teams can use flowcharts or sitemaps to understand everything contained in a website, and plan to add or restructure content to improve a website’s user experience.
Pros and Cons List
A pros and cons list is a simple but powerful decision-making tool used to help understand both sides of an argument. Pros are listed as arguments in favor of making a particular decision or action. Cons are listed arguments against it. By creating a list that details both sides of the argument, it becomes easier to visualize the potential impact of your decision. To make your pros and cons list even more objective, it can help to weight each pro and con against the others. You can then present your decision with confidence, making a strong argument for why it’s the right one.
Design Sprint Kit
With the right focused and strategic approach, five days is all it takes to address your biggest product challenges. That’s the thinking behind Design Sprint methodology. Created by Tanya Junell of Blue Label Labs, this Design Sprint Kit provides a set of lightweight templates that support the Design Sprint’s collaborative activities and voting—and maintains the energy, team spirit, and momentum that was sparked in the session. Virtual sprint supplies and prepared whiteboards make this kit especially useful for remote Design Sprint Facilitators.