A fantastic post. In my own head I can see almost direct connection between what you propose and the Thinking Process developed by Eli Goldratt. At the first glance it feels like Goldratt's Thinking Process offers mechanics of how to get your proposal implemented.
Goldratt's TPs... Look for the Current Reality Tree, with feedback loops included, to model as-is, Future Reality Tree to model as-should-be. You'll need Clouds and Negative Branch(es), too.
I really feel this frustration with cascading goals. The phrase that comes to my mind that corresponds to your "persistent models" is "theory of change". Without such a theory of change, it's so easy to devolve in siloed goals (given that we're good at X, our strategic goal is to do more X). The other thing that cascading goals don't do is allow for teams lower down the heirarchy to sense for / identify unexpected levers of change.
Excellent, John. I agree that when we look at business/product goals as intentions to have an impact on the interconnected factors/variables linked to the business/product, it becomes very important to have a model of how these factors are connected.
The main problem I see with linear/cascading Product Management tools like the Opportunity Solution Tree, for example, is that they reinforce the view that an outcome is linked to multiple opportunities, linked to multiple possible solutions, linked to multiple possible assumptions tests (in short: one-to-many, unidirectional links in the graph), while in reality it's more likely that all these elements are interconnected (many-to-many, bidirectional links in the graph). The latter is harder to work with, of course, for most.
This got me thinking, which probably means it's a good article :)
I was wondering how it relates to e.g. OGSM, which is commonly used in my org. Everyone creates their own OGSM based on the OGSM set at the top, so that tracks with your article. If I want to turn it around I'd have to start with what we have.
It looks like the model you create would translate to something like OSMG or SOMG. Strategy first, define what measures you want to influence, then set goals?
This reminds me a lot of a process that Vaughn Tan (ex-Googler then management professor) wrote called the Boris process--“conventional goal-setting is usually self-defeating, and how organizations can free themselves to act more autonomously and effectively by focusing on tradeoffs instead.” https://vaughntan.org/unpacking-boris
Needs based over formula based will always be a better bet. Some will argue that you can embed the needs in the formula, but I will argue along side you that it is a waste of energy and in lean, waste is seen as a thing to remove since as you put it, it does not improve the customer experience at all. Similarly I would argue that for all formulas that replace mental focus on the important stuff like some of the software lifecycle formulas of the last decade. Good post!
It reminds me of Continuous Integration as the mindset not just code merge.
When the vision, goals and objects are clear and strategies are pragmatically set it helps the process flow.
The main role of leadership is to remove any constraints and barriers of the channels while adjusting the right channel for the right information to flow and allow a stable pattern to emerge naturally, not forcefully, may be being an influence to others to improve themselves and find ways and share feedback, and feel the change from this collaborative approach.
Thanks for this great post, John. You've got me thinking a lot about rigidity versus fluidity in setting goals. And a bit about other tree-like systems that influence this process.
Really like this post - most of all, the idea of "grounding [goal setting] in a universally accepted model."
I also think you can't really “do” strategy (in the Rumelt sense of facing up to a high stakes challenge with a coherent set of analyses, policies and actions, as you refer to in https://cutlefish.substack.com/p/tbm-852-the-data-informed-product) – without an accepted common model. The rationale in your strategy – ie. what justifies the policies & actions as the *right* responses to the challenge – implies an understanding of what makes your org tick, and how it might tick better in context. If there isn’t near universal buy-in to that model, there won’t be consensus on the policies and actions either, and the strategy likely won’t cohere or stick.
But the data-informed-product post itself is very pluralistic - lots of models - and tantalizingly observes that the "models you use and socialize are probably AS important as your strategy",
I read this one as clarifying that a little: you can use lots of models in various places, but having a single accepted "spanning" model you can pin all your goals to is a very powerful enabler for all your strategic thinking. Be sure to socialize that!
John,
A fantastic post. In my own head I can see almost direct connection between what you propose and the Thinking Process developed by Eli Goldratt. At the first glance it feels like Goldratt's Thinking Process offers mechanics of how to get your proposal implemented.
Thanks for the inspiration.
Exactly. This is the way of doing things you learn when you study System Dynamics (https://systemdynamics.org/what-is-system-dynamics/).
Goldratt's TPs... Look for the Current Reality Tree, with feedback loops included, to model as-is, Future Reality Tree to model as-should-be. You'll need Clouds and Negative Branch(es), too.
I really feel this frustration with cascading goals. The phrase that comes to my mind that corresponds to your "persistent models" is "theory of change". Without such a theory of change, it's so easy to devolve in siloed goals (given that we're good at X, our strategic goal is to do more X). The other thing that cascading goals don't do is allow for teams lower down the heirarchy to sense for / identify unexpected levers of change.
Excellent, John. I agree that when we look at business/product goals as intentions to have an impact on the interconnected factors/variables linked to the business/product, it becomes very important to have a model of how these factors are connected.
The main problem I see with linear/cascading Product Management tools like the Opportunity Solution Tree, for example, is that they reinforce the view that an outcome is linked to multiple opportunities, linked to multiple possible solutions, linked to multiple possible assumptions tests (in short: one-to-many, unidirectional links in the graph), while in reality it's more likely that all these elements are interconnected (many-to-many, bidirectional links in the graph). The latter is harder to work with, of course, for most.
This got me thinking, which probably means it's a good article :)
I was wondering how it relates to e.g. OGSM, which is commonly used in my org. Everyone creates their own OGSM based on the OGSM set at the top, so that tracks with your article. If I want to turn it around I'd have to start with what we have.
It looks like the model you create would translate to something like OSMG or SOMG. Strategy first, define what measures you want to influence, then set goals?
How do you look at this?
This reminds me a lot of a process that Vaughn Tan (ex-Googler then management professor) wrote called the Boris process--“conventional goal-setting is usually self-defeating, and how organizations can free themselves to act more autonomously and effectively by focusing on tradeoffs instead.” https://vaughntan.org/unpacking-boris
Yes John,
Needs based over formula based will always be a better bet. Some will argue that you can embed the needs in the formula, but I will argue along side you that it is a waste of energy and in lean, waste is seen as a thing to remove since as you put it, it does not improve the customer experience at all. Similarly I would argue that for all formulas that replace mental focus on the important stuff like some of the software lifecycle formulas of the last decade. Good post!
It reminds me of Continuous Integration as the mindset not just code merge.
When the vision, goals and objects are clear and strategies are pragmatically set it helps the process flow.
The main role of leadership is to remove any constraints and barriers of the channels while adjusting the right channel for the right information to flow and allow a stable pattern to emerge naturally, not forcefully, may be being an influence to others to improve themselves and find ways and share feedback, and feel the change from this collaborative approach.
Insightful good read. Thanks.
Thanks for this great post, John. You've got me thinking a lot about rigidity versus fluidity in setting goals. And a bit about other tree-like systems that influence this process.
Really like this post - most of all, the idea of "grounding [goal setting] in a universally accepted model."
I also think you can't really “do” strategy (in the Rumelt sense of facing up to a high stakes challenge with a coherent set of analyses, policies and actions, as you refer to in https://cutlefish.substack.com/p/tbm-852-the-data-informed-product) – without an accepted common model. The rationale in your strategy – ie. what justifies the policies & actions as the *right* responses to the challenge – implies an understanding of what makes your org tick, and how it might tick better in context. If there isn’t near universal buy-in to that model, there won’t be consensus on the policies and actions either, and the strategy likely won’t cohere or stick.
But the data-informed-product post itself is very pluralistic - lots of models - and tantalizingly observes that the "models you use and socialize are probably AS important as your strategy",
I read this one as clarifying that a little: you can use lots of models in various places, but having a single accepted "spanning" model you can pin all your goals to is a very powerful enabler for all your strategic thinking. Be sure to socialize that!