Very interesting. We've fallen into the psychological rut of using the term "scope" to mean functionality rather than the other things you include in the concept of thoroughness. As you pointed out, it's all about making acceptable trade-offs, but somehow the key things being traded off against each other are often elusive. Thinking out loud: what if we contextualise the "what's the problem to solve?" (typically what we think about when we think "scope") with "what part of the company's strategy is doing this achieving?". The latter question forces us to think about what it is that's important to _our_ survival as a company. Speed to market? Then acceptable is low thoroughness. Stable infrastructure with good uptime? Then acceptable is high thoroughness.
It rains truth to talk about how the processes and ideals of the 2010s start-up, "family," agile, many-hats, now-obsolete mindset. The scope, budget, timeline trifecta is now something of a relic and we have improved our stacks and flows beyond the description and diagnostic purposes of scope, budget, timeline. Thoroughness in tech, especially fintech, where I sit, is a much better consideration for product managers to collaborate with engineers and then internal, vertical stakeholders .Love this wrap. Thanks for sharing, James 🙏
This is an excellent way of reframing the discussion on scope! What I have found is that the discussion on non-functional requirements is usually lacking or overlooked, leading to the feeling that products and features should be developed faster than they are currently.
I will definitely use this method, both for managing expectations to the stakeholders, and as a point of discussion for my engineering team, so that we are always aware of the level of thoroughness necessary for the project to be on time and within budget.
Very interesting. We've fallen into the psychological rut of using the term "scope" to mean functionality rather than the other things you include in the concept of thoroughness. As you pointed out, it's all about making acceptable trade-offs, but somehow the key things being traded off against each other are often elusive. Thinking out loud: what if we contextualise the "what's the problem to solve?" (typically what we think about when we think "scope") with "what part of the company's strategy is doing this achieving?". The latter question forces us to think about what it is that's important to _our_ survival as a company. Speed to market? Then acceptable is low thoroughness. Stable infrastructure with good uptime? Then acceptable is high thoroughness.
It rains truth to talk about how the processes and ideals of the 2010s start-up, "family," agile, many-hats, now-obsolete mindset. The scope, budget, timeline trifecta is now something of a relic and we have improved our stacks and flows beyond the description and diagnostic purposes of scope, budget, timeline. Thoroughness in tech, especially fintech, where I sit, is a much better consideration for product managers to collaborate with engineers and then internal, vertical stakeholders .Love this wrap. Thanks for sharing, James 🙏
I'm pleased you liked it! Thank you.
This is an excellent way of reframing the discussion on scope! What I have found is that the discussion on non-functional requirements is usually lacking or overlooked, leading to the feeling that products and features should be developed faster than they are currently.
I will definitely use this method, both for managing expectations to the stakeholders, and as a point of discussion for my engineering team, so that we are always aware of the level of thoroughness necessary for the project to be on time and within budget.
Thanks for the comment Milan — I'm happy you found it useful.