Why requirements don’t work – the riddle of experience vs memory
According to Daniel Kahneman, one of the founders of behavioral economics, we have two selves.
- Experiencing self – who lives in the present and knows the present
- Remembering self – a storyteller that keeps score and maintains the story of our life
The remembering self uses story to make sense of the world. As soon as we experience something, we fit it into the story in our heads. What we keep from our experiences is a story.
Therefore, when we recount a memory, we’re sharing the experience of the story we created, not the actual experience.
And when we make a decision, we choose between memories of the experience of the story. The experiencing self has no voice in the choice.
And what defines stories? Most of the individual moments of an experience are lost and don’t make it into the story we remember, except for changes, significant moments, and endings.
Take, for example, endings. Kohneman uses colonoscopies to illustrate the importance of endings on memory. In studies that measured how much patients actually suffered (as measured by their experience at the time) versus how much did they think they suffered (based on their memories of how bad the experience was), patients that experienced more pain remembered it as less painful if the operation ended on a less painful note. They were able to give patients a better story of their experience by prolonging the operation.
Implications for requirements
- If you ask someone what they want, they project into the future what they think they want based on their reflections (memory of) experiences in the past. But these reflections don’t match actual experiences. So their projections aren’t accurate at predicting what their future experiences will be. Instead ask people about how they work. And ideally, get them to show you because the story they recount is only an interpretation.
- Probe for the stories. The stories reveal significant moments, surfacing pain points and goals. The stories reveal the frame they wrap around their experiences.
- Get really good at asking questions (and become an expert listener). Few people ask really good questions. And fewer still know how to listen beyond the surface of what’s said. Have NO expectations about their responses (don’t try and fit it into a story you’ve already formed.) It’s not about how YOU see the world, it’s about understanding how THEY see the world.
- Since people are terrible at predicting how they will feel in the future, use prototypes. Prototypes allows people to provide feedback based on their experiencing self.
No related posts.
3 Responses to “Why requirements don’t work – the riddle of experience vs memory”
Comments
Read below or add a comment...
This sounds so true. As a consultant our role is not to ask for requirements, its to use our experience as well to complement and describe the stories and experiences.
And yes, a prototyping approach does show what a lot of words in a requirements document will never be able to…this could be your experience in your processes. This provides a great early link to establishing the training approach.
Thank you so much. This addresses major reasons why a large majority of (software) development projects fail. People cannot easily specify what they need. They they can more easily review, critique, or co-create a model. This is why work products matter more than procedures, as Naturalspi once wrote (linked above).
The concept is interesting, however, I am not sure if experience vs. memory is the reason. Requirements are difficult because people can usually only describe what they are doing now and cannot visualize what can be done. Prototypes are important because it they allow actual visualization – a spring board from which other ideas can come.