By taking the time to regularly checkin with our users we minimize waste (expensive engineering on the wrong things) and we maximize value (small feedback loops to validate assumptions with real users). This can be a challenge in small companies and even more of a challenge in larger organizations with a history of requirement documents and segregated business units. It’s easy for an agile team in a traditional organization to be handed a Requirement Spec from product management and jump straight into the technical implications of ‘how’ to implement a user story without really understanding the ‘why’.

At least three things happen when a product team has the opportunity to talk directly with their users: the team gets straight to the source, removes unwanted finality, and focuses success on solving problems.

Gets straight to the source

Telephone Game Giving the team access to the user breaks down any one persons contextual filters/understandings and levels the playing field for a more accurate picture of the users pain points, motivations, and goals. Anytime there is a single person that is responsible for translating a user story it is introducing a single point of failure into the system. The problem is all the more compounded when a single person translates requirements to another person who then translates it the product team.

Removes Unwanted Finality

When something is written on paper there seems to be implicit finality to it (especially when it is in a file named “PRD-v1.0-FINAL.docx”). An eye-opening exercise is to take a spec and walk through the requirements with the document author and take note of all the uncertainty, leeway, negotiations to be made and lack of understanding of the users pain points. By picking up the uncertainty through gentle inquiry and nonverbal cues with the document author a natural next step is to introduce the user into the conversation to validate the assumptions that were once considered FINAL.

Focuses Success on Solving Problems

It’s rather easy to go through the list of requirements, check box each item as it is finished, and celebrate when it is done. Is this reason to celebrate? How do we know the features are effective? Are they being used? Is it causing any extra confusion for the user? Does it delight the user? By having a conversation with users before, during, and after shipping it becomes clear if the feature is solving problems in order to celebrate success or learn from the failure.

“Your job isn’t to build more software faster: it’s to maximize the outcome and impact you get from what you choose to build.”

― Jeff Patton, User Story Mapping: Discover the Whole Story, Build the Right Product

Conclusion

Taking time to invest in conversations with real users allows teams to get to the ‘Why’ of what they are building rather than get stuck in the ‘What’ that is emphasized in requirement specs. If you find yourself in a traditional organization how do you go about understanding your users when requirement docs are the norm? How do you transform team and organizational thinking to get access to users in order to maximize value?