This post originated from an RSS feed registered with Agile Buzz by Robby Russell. Original Post: Information Anxiety and Solutions Feed Title: Robby Russell gets agile Feed URL: http://www.robbyonrails.com/xml/rss20/tag/agile/feed.xml Feed Description: Robby on Rails gets agile with Dialogue-Driven Development Latest Agile Buzz Posts Latest Agile Buzz Posts by Robby Russell Latest Posts From Robby Russell gets agile

Last week, Allison brought me in a copy of a book that she owns by Richard Saul Wurman. In 1976, Wurman coined the phrase, information architect. (read more)

In his book, Information Anxiety 2, Wurman discusses how we’re overwhelmed by too much information… amongst other related topics.

Allison bookmarked a page for me that discusses the problem with developing solutions without a good understanding of the problem.

“Before any solutions to any undertaking can be developed, a movement must begin to discover its beginning. Understanding the vein of the problem is the course to solving it. The best way to accomplish any endeavor is to determine its essential purpose, its most basic mission. What is the endeavor supposed to accomplish? What is the reason for embarking upon it? This is where the solution lies.”

- Richard Saul Wurman, Information Anxiety 2

Wurman then goes on to suggest, ”There are two parts to solving any problem: What you want to accomplish, and how you want to do it. Even the most creative people attach issues by leaping over what they want to do and going on to how they will do it. There are many how’s but only one what.”

There are many how’s but only one what

”You must always ask the question, “What is?” before you ask the question “How to?””

When Brian and I began rethinking how we were extracting information from our clients, it was important to understand why we felt it was necessary. We’re convinced that the more we can enhance our patterns of dialogue with our clients, the more confidence we’ll have in our approach to building solutions that provide them with that they need, not just what they think they need (want).

Next time a client brings you a list of features for their product, please be sure to ask yourself and your client, ”why” the product needs them. What are these hows providing their business and user goals?