Putting Behavior Change on the Roadmap

After reading the HBR blog post, “IDEO’s Tim Brown on Using Design to Change Behavior,” here are a few of my thoughts on the matter.

Applications change the behavior of its users. Behavior change happens. My behavior changes, as I discussed in “What does a product change? Part I” It’s inherent.

Maybe it shouldn’t be inherent, but our requirements elicitation practices, prioritization practices, and integration apps mean that instead of serving a particular functional unit culture, we create an artificial amalgamation, the average user. The real user operates at a distance from the application, because they are not the average user. The user interface is not necessarily the problem. The model is the problem. The model is where meaning is encoded. The view just exposes some portion of the model.

The more functional unit cultures involved, the more meaningless is encoded. Each functional unit has its own distance from the application, so each functional unit has its own efforts to make their work meaningful, which they pay for in time and effort out of their own budgets. IT doesn’t pay for this time and effort. The costs are embedded in the operational budgets of the functional units.

IT practices become software vendor practices. We all went to the same schools and learned the same techniques. We define requirements elicitation similarly. Vendors adopt Agile, because it worked well enough in IT shops. So vendors average their customer bases just like IT shops and deliver averaged functionality even with personals and voice of the customer. Technical architectures can solve these issues, the key point here is that customer and user behaviors change.

Customer and user behavior change is both an entry barrier and an exit barrier. Behavior change has economic consequence. For a software vendor, anything that has economic bearing on their technologies, products, and services should be on the roadmap.

Getting these behavior changes on your roadmap involves the following questions:

  1. What is your conceptual geography? Developers typically embed conceptual models in UML, but this gunks up the conceptual model and expresses it in a form closer to code than desired. Look at OWL and SemanticWeb formulations of ontologies and conceptualizations instead. Conceptualizations tie into terminology management, which spans the words that appear on the UI; the words used in the documentation, marcom, and all other communications activities, and the words used in translated, localized content.
  2. What is your user’s inherent conceptual model, the one from which you capturing raw, unprioritized requirements?
  3. What conceptual model does the user create as they are exposed to the conceptual model embedded in your application?
  4. In what order are concepts discovered by the user?
  5. Where are the differences between these two conceptual models?

If you layout your roadmap in terms of minimal marketable functionality (MMFs), you will see how each MMF involves a certain subset of the overall conceptual network. This subset expands over time. The first MMF delivered to the market anchors the conceptual model the user develops of the application, and it provides the first increment of behavior change. Think of the functionality as enabling the programmed instruction of the associated behavior. This means that you have a process or succession of state changes occurring, which, much like a hike in the hills, implies a geography, a spatio-temporal geography.

This spatio-temporal geography is a shapeable thing, a designed outcome, typically left to the venacular, the accidental. With permission marketing and prototyping, you can move learning, so it occurs before the install, so that your time to return (TTR) happens sooner. Prototyping hints at the idea that development practices allocate learning. The more the developer learns, the less the user has to learn, but again average functionality hurts here.

Once you have a conceptual geography and you’ve allocated the learning, you can determine your time to behavior (TTB).

Going further, you can exploit external content and trends. You might try to figure out how soon your keywords will become buzzwords. And, beyond meaning fitness and its supporting technical architectures, which will require vendors to change their development practices, maybe, and only with deliberate intention, you might want to change the customer’s/user’s/industry’s behavior. If so, put it on your roadmap!

Tim Brown discusses business offer elements, not just in application functionality. Early market applications expose business offer elements thinly, but moving into the late market, expansion of business offer elements and their being online is a key reality. You can change behavior across your entire offer, not just with the application’s functionality.

Comments, anyone?


2 Responses to “Putting Behavior Change on the Roadmap”

  1. John Says:

    Tortuous? Purposely?

    • davidwlocke Says:


      I’m not talking about the dings, the pains, the omissions, the negative use costs invoked by the use of your application. In a B2B situation, the buyer pays to change the way they work, which in turn changes their behavior in economically positive ways, in ways that move them beyond their current productivity frontier, so they gain some competitive advantage even if only for a short time.

      Applications or standards of any kind become codecs. The world inside them is different from the world outside them. ISO 9000 had the effect of creating trading blocks, because you had to buy goods and services from other ISO 9000 certified vendors. Email is similar, because you can only communicate using email with someone who uses email. Codecs encapsulate populations/markets. Codecs create niche markets. These markets will be served by complementors who build their application on top of yours, so they are leveraging the behavior change I’m talking about.

      Consider an application to be a gateway to a world, a world that now needs more goods and services, many of which were never needed before. Pencils gave rise to pencil sharpeners. The text box gave rise to the need for spell checking.

      And, yes, if your goal is to torture, you’ll do that and discover better ways to do that, so a pathway to additional profits are built into everything, and if you are a product manager, you can leave them for others to foster third-party communities, and you can consume some of them yourself.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: