Getting (product) work defined and done: a common pattern and options
Unless you have been on Mars or something, I think you will agree with me that we don't have a shortage of frameworks or, in general, any kind of technique/tool that intends to help us get (product) work done. Nearly all techniques/tools, as long as coming from practical experience, have their merit, they typically don't come out of nowhere, and should work if both the context and the intention to make it work are right.
As the name implies, a framework is like a lens that we use to look at something and hopefully get something useful out of it. Which also somewhat suggests that it's likely that different frameworks might just be nothing else than slightly different, nuanced ways of looking at something while largely being coherent around some overarching, more general common pattern.
I am convinced that is the case for the many techniques out there that are useful to help us drive results via the work we do (in our products), which attempt to both give context and break things down into more manageable chunks we can get done. I can name 3 of them that I am more familiar with:
Opportunity Solution Trees by Teresa Torres;
The use of Impact Mapping for Product Discovery by Tim Herbig;
GIST (Goal - Idea - Steps - Tasks) framework by Itamar Gilad
Obviously, they have their nuances and specificities, and how they are structured differs, but ultimately, I do believe even the three product guru's would agree with me in stating there's a common general pattern going on. Where there will always be (at least) 3 levels that are relevant:
What matters in the end: what are you trying to achieve as a result?
How you believe you can get there: what hypotheses you have and what could you focus on?
What you can build to (hopefully) get it done: what output could you get to (hopefully) unlock the desired value?
Now, that general common pattern might surface with different levels of granularity. I think of it as yet another example of something that has a fractal (same pattern that repeats at different zoom levels) aspect to it. For instance, one way to frame it is from a general organization level, where you have first how you capture value from the market (represented, for instance, as a business result, so typically a lagging indicator), then what kind of outcome (measurable change in behavior) you hypothesize as being a product leading indicator (in other words, how you measure capturing value from the market as well) that can drive the top-level business result. And lastly, some designed output, like features or experiments, you can use to get that operationally done.
The key point here is that driving product value with that context and understanding the connections back and forth is how true empowerment can happen. It's how you can keep in perspective what truly matters, how you think you can get there, and how that is linked to what you are doing (now).
But you could take a zoomed-in version of it that only looks at, strictly speaking, the product (or the capturing of value side of an organization), and then the pattern can be manifested in a slightly different way (while being quite consistent with the generalized common pattern).
I think in most cases, the 3 examples of frameworks I've mentioned before would tend to take this second, more granular frame. Although I don't think they are necessarily fully bound as such, it just happens to be their more organic or natural context. It's a matter of nuance…
And speaking about nuance, there's obviously some to each of those examples I gave, it's not by chance that they are positioned on their own merits, and no one claims anyone else to be copycatting. For example, if I had to articulate what nuance I personally like most about each of the examples, it should look something like this:
What I like most about the Opportunity Solution Tree is the understanding that the opportunity space might be multi-layered (a bigger opportunity can be broken down into smaller ones, and that may even repeat a couple of times). I find that powerful from a problem-solving point of view, and visualizing that makes it more so.
I find it quite insightful, and in fact, I have seen Tim Herbig himself calling that out, the "who" layer in his Impact Mapping take for product discovery. Reflecting on that might open different avenues by which you can make things better or by which you could get what you want to achieve through different routes (focusing on different actors).
I like the simplicity of GIST a lot! The language used is also a bit more generic, thus probably being more easily adopted in different contexts.
But now, you may be thinking, "Fair enough, this mostly makes sense, there's a common general pattern underlying, and then there are examples of more specific frameworks that might be helpful to go about it on a practical level. What should I do next?"
Answering that question is ultimately up to you, obviously. But here's the punchline:
It really does NOT matter. Because it's not the tool, it's what you make out of it, and the habit and the thinking that are nurtured because of that discipline of applying some useful way of framing.
You also always have the option to develop your own thing now that you've perhaps learned that there's a common pattern. Or better still, you can start with any of those, just pick one, apply it, and evolve as your experience and context lead you… I would personally always go for this latter option.
by Rodrigo Sperb, feel free to connect (I only refuse invites from people clearly with an agenda to ‘coldly’ sell something to me), happy to engage and interact.