To build the best solution for a problem, a product manager first needs to understand the 5 Why’s of the problem. The 5 Why’s are part of Toyota’s kaizen — “continuous improvement” — philosophy and they can be used to identify the root of the problem you are trying to solve.

Asking the 5 Why’s is helpful for all problems you’re trying to tackle, not only those related directly to product development. When I onboard new customers to Wizeline’s software, I often come across development-focused PMs who want to simply create a gantt chart roadmap of their 2-week sprints in Wizeline.

But for whom is this kind of roadmap useful? It only benefits those closest to the Product and Engineering teams, both of whom already know what’s on the roadmap and where they are in the development process — thanks to the project management and development tools they already use.

So I take the 5 Why’s approach with customers who came to Wizeline looking to create a roadmap:

“To let everyone know the progress of projects on the roadmap and when they are going to be delivered.”

3. Why do you need to let everyone know the progress and delivery date of projects on the roadmap?“So all our cross-functional teams know when a project is in general availability to our users.”

4. Why do your cross-functional teams need to know when a project is in general availability?“Because today when our team says Feature A and Feature B were completed during Sprint 27, it doesn’t mean they have been launched for general availability. It just means they are development complete. This causes a lot of confusion and sometimes gets miscommunicated to our end-users as well.”

5. Why does it cause confusion and miscommunication?“We are communicating sprint-level development progress from JIRA instead of a non-technical, business stakeholder-friendly view of our roadmap projects.”

Once we’ve gotten to the root of the problem — that JIRA progress tracking may be great for developers but is inscrutable to business stakeholders — the product manager and I can go about solving that problem with Wizeline.

I often challenge these PMs to think of the product roadmap beyond their development-focused day-to-day job and consider what value a business stakeholder would need to see on a roadmap. Having empathy for your internal, non-technical stakeholders is key to building trust and consensus around your plan. These types of conversations typically change their view of the world and makes Wizeline infinitely more useful to their business stakeholders.