[Next in series]
This is the first of nine articles in a series investigating this matrix (first introduced here):
This post takes on delivery and discovery At their intersection, Agendashift places the single word “needs”. This can refer to team needs and organisation needs, but these are well represented elsewhere in our framework, so this should be taken to refer mainly to customer needs and user needs.
Customer needs and user needs can (and should) overlap significantly, but they are two distinct concepts, because customers and users aren’t always the same people! Customers pay for (or otherwise sponsor) stuff; users are the people that interact day-to-day with the results.
Agendashift is an “opinionated framework”. As such, we make a stand on behalf of the oft-neglected user here and state that discovering user needs should be a first class activity of the delivery process.
This is a more radical departure from the norm than it might sound. Do not confuse user needs with requirements, or discovery with analysis. The focus of user needs discovery is different (on the user, and further removed from solution design) and may require some new skills (user research, user experience, etc).
Promoted to “first class status”, the discovery of user needs even has the power to transform a problem of bounded scope (the product backlog or a project) into an ongoing process. We’re recognising that user needs do not stand still, and (excitingly) that by engaging with them we may help them and our relationship with them evolve in ways we can’t always predict.
Of course the deepest of user needs are relatively stable over time – good news if we’re seeking lasting engagement. Some writers refer to these as customer values. These aren’t the values that first spring to my mind when I think of “values-based delivery” but nevertheless it is important that there is some alignment. We’ll look at that next.