Once you understand this pattern, you'll start noticing opportunities everywhere. How often do you view status checks alongside historical status checks? Does your team automatically "punt" work into the next sprint without putting those things through a prioritization filter? Do you do backlog grooming here and there, or do you export, delete, and selectively pull things into a new version? Are your estimates any better than throwing darts? Does your "cone of uncertainty" narrow over time, or do new things keep getting in the way?
My main issue with all of these product tools is that they're built as monolithic platforms. You usually implement these to solve a SINGLE PROBLEM, but the only way to do something about it is to buy into the whole tool's ethos/framework/methodology.
3 enterprise clients later, this platform tool's onboarding and framework is now all over the place. Nothing makes sense for you, smaller product team, who just wanted a roadmap. You're not ready to get to insights until a year later, earliest. These tooling implementation are then only half-baked, so then the org hates it for a few years before you switch to a new one.
YES! I completely resonate with your thoughts on the challenges of using monolithic product tools. I've been saying this for years—modular/flexible tooling is the only way to adapt to ever-changing needs and ways of working in product organizations. In fact, all of airfocus is built around a modular architecture that allows a) each team to have its own way of working and b) to aggregate all of the teams' work to multi-product/team roadmaps and portfolios (you can read more here: [https://airfocus.com/the-airfocus-way](https://airfocus.com/the-airfocus-way/)).
Great people + principles/ways of working + tools = success 🔥
The graphic under "Information Asymmetries" felt like the kind of workplace dysfunction that the Dilbert comic series portrayed, during its golden years anyway.
My main issue with all of these product tools is that they're built as monolithic platforms. You usually implement these to solve a SINGLE PROBLEM, but the only way to do something about it is to buy into the whole tool's ethos/framework/methodology.
3 enterprise clients later, this platform tool's onboarding and framework is now all over the place. Nothing makes sense for you, smaller product team, who just wanted a roadmap. You're not ready to get to insights until a year later, earliest. These tooling implementation are then only half-baked, so then the org hates it for a few years before you switch to a new one.
Why aren't these tools modular?!?!?!
YES! I completely resonate with your thoughts on the challenges of using monolithic product tools. I've been saying this for years—modular/flexible tooling is the only way to adapt to ever-changing needs and ways of working in product organizations. In fact, all of airfocus is built around a modular architecture that allows a) each team to have its own way of working and b) to aggregate all of the teams' work to multi-product/team roadmaps and portfolios (you can read more here: [https://airfocus.com/the-airfocus-way](https://airfocus.com/the-airfocus-way/)).
Great people + principles/ways of working + tools = success 🔥
My preference is the wall.
The graphic under "Information Asymmetries" felt like the kind of workplace dysfunction that the Dilbert comic series portrayed, during its golden years anyway.
This was really interesting, John, thank you. I'm going to try some of this bullet journaling stuff 😉