Designing from ignorance.
The amount of design thinking frameworks (and LinkedIn content to accompany them) that have emerged since the early 00s is startling.
Understandably, each professional services organization might have their spin on things, but there should have always been a fundamental agreement that they are different coats on the same mannequin, not entirely different mannequins.
'Jobs-to-be-done' seems to be emerging as the framework of choice, and I agree. It is in my view the most accessible, least fluffy and widely usable form of getting in customers' boots (empathy in classic service design speak). The reason it works is that it makes it easy to succumb to a necessarily ignorant, i.e. an "I know only that I know nothing" approach to looking at customer or colleague challenges (or opportunities) and listening first without putting forward pre-cooked opinions on solutions that inevitably spring up.
People don't need "QR code instant payments" they need to "pay that guy for that thing" without flapping around with an IBAN code that has 9 zeros in it.
People don't need "fast charge scooters stations" they need to "go over there on time".
Things get particularly tricky in the B2B space because user groups are more complex and there's inherently less user choice. These users, like all of us, NEED to do their jobs so they can feed their families and go home on time, so often the experience of how they achieve that is brushed aside because they will do it anyway. Conversely, there's an inherent assumption that if a given workflow gets enhanced it will be a huge bonus for them, which is often not the case because the underlying jobs are simply not impacted enough and changing habits for something new is not worth it.
Most importantly, even if the user group is a "senior VP cohort for Mid-Western Europe that specialises in quality maintenance of turbocharged widget computing systems", in reality, they probably still just need to "pay that thing", "send that stuff" or "go over there". It is our job as designers to uncover that by boiling jobs down to a minimum without going pixel-crazy or overthinking the framework.
