I keep harping on the bad practice so prevalent in software development of focusing on functional requirements rather than how the system will prove value and make the customer happy (the “satisfaction of desires”). The first conversations we should have with our customers (or about our customers if we’re working with proxies) should start at the hypothetical point after the software has been used to bring about a result (what I call a “mechanism of fulfillment”).

In addition to better understanding of what is going to make the customer happy, this technique also reveals the subtle complexities of different roles within the customer, leading to a map of the different “value constituents”.

I introduced this technique in a work group meeting a few weeks back. It was a mix of product managers and developers and the focus was on a high-level integration of two products.  Before hand, one of the product managers had attempted on their own to define some roles and tasks.  Here’s what he had come up with (specific technologies scrubbed into alpha letters):

Target Users and Tasks

  • End user
    • Use client-of-choice using appropriate Z-based user interface for complex O-ing
    • User interface built by our company or in house
    • Build and deploy custom Z
  • Developer
    • Graphically create and configure a new X
    • Create customized A components and deploy to other X users
    • Create Z-based search applications and services
      • Incorporate feature B
      • Incorporate technology Q

Below is the result of the group after about 40 minutes. It only took a few minutes to introduce the technique and was immediately struck by the high-level of participation. There was a 5-10 minute period in the middle when people got stuck on describing technical functionality. Whenever someone would say something like “the user won’t get U unless we make sure that we provide the right feature K,” I would respond with “well, how will the user know they got U?”

It is a bit overly broad and not specific enough, I think this was the first time people had explored and appreciated the complexity of an enterprise customer. Much of the language is still awkwardly moving from describing features to outcomes, but clearly this is a different conversation than what we see in the original information provided by the product manager. These are also roles or persona’s, so a person may play more than one role, but usually only one at a time:

How will they know they got value?

  • End User
    • Execute Y Scenarios
    • Share Outcomes
      • Examples: A’s, B’s, C’s, D’s
  • Application User
    • Execute From My Applications I Already Use
    • Outcomes are integrated into My Application (no cut and paste!)
  • Ad-hoc User
    • Don’t have to get app installed
    • Don’t want to learn any more than I have to
  • Data Consumer
    • Make Decision for Next Step
    • Knowledge of Current State of Things
  • Super User (Servant Role)
    • Make User Role more productive
    • Help Colleagues
    • Within My Skill Technology Skill Set
      • GUI, Don’t need to know X code
    • Improve Other User’s Work
  • Developer (Servant Role)
    • Fix problems Super User cannot or does know how to address
    • Don’t need to help Super User or User very often
  • IT Professional (Servant Role)
    • Address customization and extensibility needs that arise in the organization
    • Don’t need to help Developer, Super User, User very often
    • Maintain IT Data Standards
    • Respond in a time frame that pleases my users
    • Minimal Effort to maintain application
  • Executive
    • Product provides clear metrics that can be used to justify purchasing decision

If you only use the above techniques to drive better conversation, I think your requirements or user stories will improve. However, there is a much bigger opportunity here and that is to structure the order of priorities so that we build the thing that shows the value was realized before we build the mechanism to deliver that value.