It's not your product, it's your users

Recently I was involved in a user story mapping workshop with one team. They had done it in advance and asked me for advise to see if the work items they had identified were right or not. I am not an expert in their domain. However, as they were explaining their epics to me, I realized they had a very technical view of what they had to built. Their value stream was not the users', but the needed steps to create the infrastructure that would support several features they had identified as very important for the users.

In my experience, this is a common situation when preparing product backlogs, specially if technical people are involved in the process. The focus is not on what to build, but on how to build it. So, the question we need to bring immediately is: who are your users? In this case, the answer was a very concrete profile. Next question: can we bring them to the workshop? Fortunately, this was possible. And this is what we did.

The following day we asked the user to tell us one day in her life in relation to the process that the product under discussion was supposed to enhance. This was the starting point for a conversation with both business and technology that allowed to identify the actual needs of the user. Based on this, we started to build a new story mapping which, in this case, was a real user story mapping. Once finished, we already had a very valuable outome: the team became more conscious of what they were expected to build based on the fact that they are not supposed to create features, but to deliver value.

© dmason for openphoto.net

The main conclusion that I have from that session is the importance of opening your doors to those people that have the first hand information about the problem or need you want to address. It is very tempting, and I have done it plenty of times, to suppose everything about the user and start working according to those suppositions without validating them. Why don't we realize we should be humble enough to go and validate these assumptions? Are our users very simple beings that can be modelled easily? I don't know if the origins of these behaviors are in the waterfall model, where everyone is supposed to get inputs from the previous stage and generate outputs for the following state with no more help than extensive documentation. No matter the reason, it is time to stop doing this kind of niche work based on what we know. We need to do work based on we don't know. And this means involving those who have this information in order to start a joint journey whose end will be for sure the delivery of real value.