Focus on demand-side
I've been getting a lot of inspiration from the work of Bob Moesta, a pioneer and co-architect of "Jobs-To-Be-Done" as theory and practice. "Learning To Build" is a particularly good reference for working with products, in my opinion.
But across his work there's a common element that I believe has an overarching and large application, as a principle:
The difference between taking a supply-side vs a demand-side perspective (on innovation, and potentially beyond).
I think intuitively I already grasped a lot of the underlying implications, but I kind of like when I can put a conceptual frame around how I think about and attempt to operate in practice. The more I think about it, the more I can connect dots and get an intuition of so much in organizations that can wrong and could be associated to that difference of taking a supply-side vs a demand-side perspective on things.
Before we get to explore some examples, let's first level-set what's the difference:
To take a supply-side perspective is fundamentally about focusing on what you are capable of doing, so it's a kind of push mechanism.
As opposed to taking a demand-side perspective which is about considering the progress your customer are trying to make, so acting more like a pull.
Simple example: every time that we (as an organization) obsess about finishing a set of features we thought we should do in a period, that's taking a supply-side perspective; when we invert the logic and become obsessed about solving the struggles our customers have, regardless caring so much, at least upfront, about which features we will need to deliver (i.e., treat that rather as an emerging property), that's taking a demand-side approach.
The above is just one simple yet somewhat comprehensive, but there's much more I could easily think of:
The whole TPS (Toyota Production System) and all its further branching is fundamentally a reframing of demand-side (as opposed to supply-side) in how to produce.
We rather have some slack in the system, instead of operating under the myth of full capacity allocation, precisely to be able to adapt and react to demand-side emerging properties.
I don't believe I can possibly talk more about all things related to preventing work to age in delivery systems (and have faster flow, so to learn faster whether we are wrong and by how much), but here's yet another angle: we only like aging to our wines because we want to take an empathetic perspective towards our customers (and they don't care so much whether we deliver everything we thought we could, they even cannot know that if we don't tell them; they do care though whether they can start using and see if it helps them to make progress where they intend to make progress).
We care about low WIP because we care about having a cadence to keep regularly engaging with customers in a way that fosters learning (i.e., when stuff are in customers hands) and caters for the emergence of uncovering needs so to tackle them. We also want priority to matter and not to risk delivery sequence to be at mercy of other factors.
We want to keep the demand-side perspective because we don't want to assume competition to be based on the apparent inherent similarities of what we do, but rather take the perspective of what is the "job to be done" and what are the options / alternatives to that as well.
We prefer to work backwards from desired outcomes, and then figure out what we could possibly built because that allow us to keep all that demand-side in perspective, and ground decisions based on that, instead of what we could possibly do (for being capable of).
And I guess you can guess I could go on and on, but I think you get the spirit… There's probably even much more that willl become uncovered for now, just to not let this becoming too exhaustive, and because the point was not to make it an exhaustive list to begin with…
But in case you need something more, perhaps a little story can help to land the key difference.
A short tale of overdoing…
Imagine you are the owner of some data & analytics products, and you learn about a group of users which are regularly dumping some data from datasets you own and doing some offline adhoc stuff with it. A very natural thing would be for you to go after and talk with those users, attempt to understand what they use the data for, and eventually come up with what you think is a solution for their needs. So you build a highly tailer-made full-blown set of dashboards with also plenty ofl filtering possibilities.
You essentially showed off quite nicely what you are capable of, while showing some level of empathy for the users perspective – after all, you did talk to them, you didn't operate only on assumptions, and all of that. But that's still fundamentally operating with a supply-side perspective, I'm afraid.
Eventually the consequences of reality hits you (as they always will, even if you can try to ignore seeing reality for what it is, you can't run away from its consequences, never..). And next you learn that the users are still dumping the data (after all, they can…), they didn't replace it for the dashboards you provided. Well, maybe it was a bit of both, they use the dashboards to some stuff, but they still value more the ability to slice and dice independently as they see fit, in their tool of choice as well (goo'old Excel).
You finally get a better sense of what they are still struggling with, and perhaps now you are better equipped to take their perspective (i.e., demand-side) and go with it, and try to figure out what are possible adjacent futures that work as better alternatives to what they have today. Maybe a data cube (which by the way would have been much easier to implement) will serve them better, at least it would remove the burden of having to dump the data themselves. Maybe there are other clever options, but at least now you know better from their standpoint.
That's how demand-side looks like… And on the surface it may look like just a nuance, but it's a fundamental shift. It can also be the difference from doing something about what customers care about and overdoing it while leaving them still struggling.
Now it's over to you…
So, here's the insight for you: what this all make you think and potentially have reframed? Are you sufficiently taking that demand-side perspective? What can you learn and DO differently now that you have a good theory to put in practice?
The latter, by the way, has a lot to do with what the late Clay Christensen, one of the mentors of Bob Moesta, had taught us and left as a legacy (i.e., sound theory that guides practice in innovative ways). So that you know (in case you never read the very first post), it's also part of the reason why this is called the Conceptual Leader .
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.