It’s been nearly four decades since Microsoft developed their Project application as an internal management tool to organize their various software development projects. In 1984, they released it to the public (on floppy disk…CDs didn’t really become a software download mechanism until the mid-90s), and within a few years it became the dominant project-management software for the PC universe.
Microsoft Project incorporated a Gantt chart to visualize chains of events, providing a tidy picture of what and when to facilitate a practical, linear view of project management. Indeed the Gantt chart is still the most common visualization of project management.
The tools have gotten a lot flashier since then — Asana and Trello are two of our favorite project/task management tools — but in terms of what questions are asked, not much has changed.
What was missing — and is largely still absent — is the Why.
Gantt charts are great for visually planning out a cascading series of tasks, as long as the justification and prioritization don’t fluidly factor into the series. In other words, as long as your team is decidedly not agile.
So it should come as no surprise that as product (as opposed to project) management and engineering teams have used Gantt charts to visualize their product roadmaps, the crucial Why is still missing. Perhaps this is part of the reason why even though most product and engineering teams say they’re agile, only a small percentage actually operate in a truly agile fashion.
Product roadmapping with a linear Gantt chart can result in a feature-factory mentality, where we push a laundry list of features out the door with little consideration for why we’re doing it or how all the features fit together. It also doesn’t account for feedback loops bringing in-market intelligence and data back to inform the roadmap.
Why do we need the Why?
We need the Why because the market for software products is more crowded than ever. Consumers and businesses have more options and switching from one solution provider to another is getting easier and easier. All of this means that solution providers have to build products people can’t live without to be relevant.
Product management in 2019 and beyond is far too sophisticated and dynamic to be left to a Gantt-style roadmap. We are increasingly agile and customer-centric, and therefore utilize a far more iteratively circular process of product management. As the customer needs evolve, our continuous discovery surfaces that and our continuous delivery should reflect that new understanding.
Collaboration and cross-functionality between teams is crucial to understanding our customers and meeting their needs. But too often, the engineering team feels like new products and features are simply “thrown over the wall” by the product team. They feel like they haven’t been brought into the product discovery process early enough, so they don’t understand why the roadmap looks the way it does.
This is why the entire team needs to be connected to the customer throughout the product discovery process. Gantt charts are great for project-management specifics, but long-term product success requires the whole team to be wired into the customer need, and by extension, the product strategy.
So, how do we get everyone connected to the Why? A few thoughts…
- Many industry-leading, product-led companies make sure all teams cycle through customer success so they can get a visceral feel for how customers use their product, as well as their likes and dislikes. This keeps the Why top-of-mind for everyone on the team.
- Make sure your customer-success dialogues are connected to the roadmap so an engineer, marketer, or salesperson can click through conversations the support team had to justify the Why of that new feature. We’ve made this a priority in our own software by integrating GLIDR with both Intercom and Jira.
- Involve a representative from product, design, and engineering in early product discovery efforts — someone from engineering should be invited to the upstream product discovery activities. If your company is hesitant to involve engineering in the early stages, they can still keep them informed through tight integration between the discovery and delivery tools.
- Bring your teams closer through the modern miracle of data science! Data science and business intelligence are not just esoteric domains — the product team should make sure that data is interpreted and socialized broadly throughout the various teams. This promotes healthy institutional learning, which becomes the core of competitive advantage.
It’s hard to shake old habits, especially ones that work most of the time. But the linear, cascading approach to project management has its limits in the circular environment of a product roadmap, where iteration and customer discovery no longer follow a straight line. If you want your roadmap to guide you further than the next exit, your team needs to know more than just where they’re going — they need to know why they’re making the journey in the first place.