Hi John, you touched a nerve here. I can probably add my two cents from the EventStorming perspective.
Especially in Big Picture, the tension between the linear left to right storytelling is real. While I ask participants to *try* placing all the events on a timeline, I also know that assuming left to right is a naive illusion. ...But *trying* to put all the events on a timeline is a fantastic conversation booster: the shortcoming of the linear journey mode become evident to everybody, and we invariably start rearranging the layout to accommodate for feedback loops. We still forbid arrows that tend to calcify the model, but we make returning customers, strategy adjustments and so on progressively more visible.
The underlying problem is more related to geometry than to the methodology: EventStorming goes a lot more in detail, in terms of granularity, but then we'd need a very oddly shaped room to have loops from the beginning. User Story Mapping is even more rigid because it's fixed horizontally and vertically.
I usually tend to start from EventStorming because it provides a stable detailed ground for further explorations, Wardely Maps, Ecosystem Maps, Causal Loop diagrams. One perspective can support, not replace the others.
And 🙌 on "ephemeral": some formats are designed to provide the insight, no to be long lasting blueprints.
The challenge in working with all three models is that more collaboration and coordination is needed. More meetings, more documents, more communication… more of the stuff that seems like a waste of time but is essential to moving forward. Ashby’s law at play.
Most PMs just want ship software.
The two ideas are not mutually exclusive, I am reflecting on the necessity of all this processes that you can’t rush just so you can successfully “ship software.” Sigh…
A nice thing about these types of models is that they are relatively persistent. They stick around for a while. So while companies institutes all kinds of things that happen week, bi weekly, quarterly, etc. you don't really need to re-invent the models you use.
Teams or functions are over-rated and are an outdated org design method for the modern product challenges. The foundation is on the intersection of different functions and not within the functions—but we try to find the intersections in Slack, Linear, or Miro workshopping.
The intersection is in designing the squads for goals and not for skills—whether for onboarding, retention, advocacy, coaching, reducing churn, or whatever it is.
I love this one, John - thank you for spelling it out so clearly!
I'm about to engage in an exercise of tri-functional modeling to see if my understanding is complete (and when I find out it isn't, I just might learn where to look to fix that).
Hi John, you touched a nerve here. I can probably add my two cents from the EventStorming perspective.
Especially in Big Picture, the tension between the linear left to right storytelling is real. While I ask participants to *try* placing all the events on a timeline, I also know that assuming left to right is a naive illusion. ...But *trying* to put all the events on a timeline is a fantastic conversation booster: the shortcoming of the linear journey mode become evident to everybody, and we invariably start rearranging the layout to accommodate for feedback loops. We still forbid arrows that tend to calcify the model, but we make returning customers, strategy adjustments and so on progressively more visible.
The underlying problem is more related to geometry than to the methodology: EventStorming goes a lot more in detail, in terms of granularity, but then we'd need a very oddly shaped room to have loops from the beginning. User Story Mapping is even more rigid because it's fixed horizontally and vertically.
I usually tend to start from EventStorming because it provides a stable detailed ground for further explorations, Wardely Maps, Ecosystem Maps, Causal Loop diagrams. One perspective can support, not replace the others.
And 🙌 on "ephemeral": some formats are designed to provide the insight, no to be long lasting blueprints.
The challenge in working with all three models is that more collaboration and coordination is needed. More meetings, more documents, more communication… more of the stuff that seems like a waste of time but is essential to moving forward. Ashby’s law at play.
Most PMs just want ship software.
The two ideas are not mutually exclusive, I am reflecting on the necessity of all this processes that you can’t rush just so you can successfully “ship software.” Sigh…
A nice thing about these types of models is that they are relatively persistent. They stick around for a while. So while companies institutes all kinds of things that happen week, bi weekly, quarterly, etc. you don't really need to re-invent the models you use.
Teams or functions are over-rated and are an outdated org design method for the modern product challenges. The foundation is on the intersection of different functions and not within the functions—but we try to find the intersections in Slack, Linear, or Miro workshopping.
The intersection is in designing the squads for goals and not for skills—whether for onboarding, retention, advocacy, coaching, reducing churn, or whatever it is.
"product manager was well-versed in the flywheel hypothesis but hadn't considered the product's actual customer journey and experience."
That doesn't sound like a diagram-choice problem.....
I love this one, John - thank you for spelling it out so clearly!
I'm about to engage in an exercise of tri-functional modeling to see if my understanding is complete (and when I find out it isn't, I just might learn where to look to fix that).