Monthly Archives: June 2006

Now Easier Than Ever to Subscribe!


It just got easier to subscribe to Tyner Blain – by email!

We’ve added a page explaining subscription options, and updated our sidebar with the option to subscribe by email, thanks to our service provider, Feedblitz.

If you aren’t already subscribing, you should because

  • It saves you time.
  • You won’t miss anything.

If you’re already subscribing by email or RSS – thank you!

This is a holiday weekend in the US – enjoy it!

Extra Features Cause $245,000 Loss

Internet Explorer dependency graph(complex IE dependency graph)

Robin Lowry has posted a story of a demo gone horribly wrong at The Product Management View. In the story, users end up confused by the myriad of features of the software – resulting in a $5,000 sale instead of a $250,000 sale.

The Quote

In ten minutes, the SE showed all of the specific capabilities the customer had identified. The SE then looked at his watch and noted that he fifty minutes left in the meeting.

He said, “Since we have some additional time, why don’t I show you some of the other capabilities our software offers?”

The Impact

“The users said the software looked too complex – they couldn’t visualize using the tool themselves,” responded the customer champion. “They got confused by all of the various functions and capabilities that were shown during the demo…”


Showing too much in this demo reduced the value of the sale from $250,000 annually to $5,000 annually – a negative conversion of $245,000 per year!

Their Conclusion

The SE (sales engineer) knew what the customer needed, and should have demoed only those features. The other features never should have been demoed. The additional demo contributed to what they call perceived complexity, causing the loss of significant sales.

Our Conclusion

While we agree completely about the demo, we suspect the features should never have been there in the first place.

Having too many features can create a barrier for new users (or potential customers) as this story shows. It also makes the software harder to use, causing reduced satisfaction and user adoption.

From our article, Goldilocks and The Three Products

suck threshold

… we see that too many features leads to unhappy users and reduced value. When the customer gets less value, we get less revenue.

The Use Case For Creating Goal-Driven Use Cases


There are 8 reasons we write use cases. Most of the benefits of documenting use cases come from communication, but all of the benefits depend upon the initial creation of the use case. The first step to determining the best way to create a formal use case is to understand the use case of creating use cases.

Why Write a Use Case for Use Case Creation?

By writing a formal use case for the use case creation process we are doing two good things and one bad thing.

The first good thing that we are doing is providing a real example of a formal use case.
The second good thing we are doing (we hope) is being memorable. With a Meta-Use Case (Thanks, B. Zaniello for that one), we are providing both a guide to writing use cases and a concrete example of the benefits of using a formal use case format.

The bad thing we are doing is requiring people to know how to read a formal use case to benefit from this article.

The Bigger Picture

Our goal is to gain an understanding of all 8 goals for use cases, and the scenarios in which they are used. With this understanding, we can improve our ability to apply use cases to achieve software product success.

The Use Case for Creating Goal-Driven Use Cases

Title: Business Analyst Creates Goal-Driven Use Cases

Description: The process a business analyst uses to define the use cases that support a single market requirement (goal). A single goal may be achieved with one or more supporting use cases. This document covers both possibilities.
Goals: This use case supports all 8 goals identified for creating use cases.
Primary Actor: Business Analyst (BA).

Secondary Actor: Stakeholder.

Trigger: The MRD has been completed and the creation of functional requirements has been requested.

Precondition: A Market requirement has been defined and documented.

Post-condition: The use case(s) needed to achieve the requirement have been defined.

Normal Course:

  1. The BA interviews stakeholders and reviews existing documents to identify the business processes that support the market requirement.
  2. The BA documents the trigger, preconditions and post-conditions for the processes.
  3. The BA identifies any alternate processes that achieve the same goal.
  4. The BA identifies the actors (or personas) that are involved in the particular processes.
  5. The BA determines if one or more use cases are required to meet the market requirement. The following steps are repeated for each use case.
  6. The BA documents a reference to the single requirement being supported.
  7. The BA documents the steps in the process, where each step has a single actor and a single action.
  8. The BA identifies the frequency of occurrence of the process.
  9. The BA defines a priority for the use case.
  10. The BA documents the frequency and notes the source of data.
  11. The BA documents the priority of the use case and records assumptions and calculations used to prioritize.
  12. The BA confirms that there are no re-useable use cases in the current use case.
  13. The BA documents any assumptions made during the use case definition

Frequency of Occurance:

During the initial phase of a project, a business analyst may spend 100% of her time in creating use cases. During the middle or end of a project, very little time is spent on writing use cases.

Alternate Courses:

A1: Migration projects
A1.1 For a process-migration project, the BA starts by documenting the existing processes, then identifies the new business processes that allow the requirement to be achieved.

A2: Multiple requirement support
A2.6.a The BA identifies any other requirements that are also supported by the current use case.
A2.6.b The BA documents references to all supported requirements.

A3: Frequency variation within process
A3.7.a. The BA identifies that steps within the process have varying frequency of occurrence (an iterative step within a process, or a looping process).
A3.7.b. The BA either makes a note of the variation in frequency for the individual steps in either absolute or relative terms.

A4: Reuse of existing use cases
A4.8.a. The BA has identified that some of the steps of this use case are duplicates of an already documented use case.
A4.8.b. The BA replaces the duplicated steps with a reference to the use case that is being reused.
A4.8.c. The BA updates the included use case with a reference to the current use case.

A5: Anticipated Reuse of portion of this use case
A5.8.a. The BA has decided that some of the steps in the current use case should be managed as a separate, reusable use case.
A5.8.b. The BA creates the new use case representing the reusable steps.
A5.8.c. (Same as A4.8.b – A4.8.c)

A6: Duplication of several (but not all) steps of another use case
A6.8.a. The BA identifies that several steps in the current use case are repeated in another use case.
A6.8.b. The BA creates a new use case that includes the duplicated steps. (Same as A5.8.a – A5.8.b)
A6.8.c. The BA updates the current use case. (Same as A5.8.c)
A6.8.d. The BA updates the other overlapping use case (Same as A5.8.c)

Exception Courses:

E1: Data Not Available
The BA identifies any missing information as “TBD” (To be determined).
Note: The BA should make concrete plans to identify each TBD item, possibly assigning it as an action item or scheduling a date for when it will be updated.


There are no included use cases for this use case

SummaryThis use case represents the process that a BA follows when creating a use case.Please comment with any feedback on how to improve this use case.

Know Thy Customers’ Markets

Profiler logo

Michael on Product Management and Marketing has posted the first in his series of product management commandmentsKnow Thy Customer. He provides five tips on how to know your customer better. We extend his idea to include understanding our customers’ markets, and provide more tips. By analogy, this is the difference between a detective who studies a criminal and a profiler who seeks to understand a class of criminals.

Why Must We Know Our Customers?

As Michael points out, the key trait of an effective product manager is one who knows her customers. As product managers, we have to understand our customers’ problems and convert them into requirements. From those requirements we define solutions, represented as products. Without a good understanding of our customer, we can’t identify the most important problems, and therefore can’t create the most valuable solutions.

Michael suggests five ways to know our customers better:

  1. Listen to customers.
  2. Usability tests.
  3. Follow-me-home.
  4. Walk-a-mile.
  5. Customer surveys and focus groups.

Michael’s article

Know Thy Customer’s Market

One of many points that Pragmatic Marketing makes in their training is that product managers need to focus on multiple customers, not individual customers. They replace the “become a customer expert” goal with “become a market expert.” This helps drive their point home. We think we need to know our customer’s market, and not just our customer.

Understanding the market our customer requires us to know not only our customer, but our customer’s competition. Knowing our customer helps us understand the important and valuable problems. Knowing her competition’s problems helps us know which problems have value for multiple customers. One-customer problems require custom solutions. We want to maximize the time we spend on creating reusable valuable product features.

Michael definitely uses the plural when talking about understanding customers. We are taking this one step further, to include understanding of potential customers.

Things to Know About Our Customer’s Markets

  1. The competitive landscape. Are there few or many companies in the space? Is it an oligopoly, monopoly, or free market?
  2. How does our customer compete? What are the factors that our customer believes make them (or will make them) competitive? Do they compete on price or features? Do they rely on existing customers or new customers for their growth?
  3. Is the market growing, shrinking or stagnating? Is our customer fighting for a larger slice of a shrinking pie?
  4. What might disrupt this market? Our customer’s market is at risk of being obviated or obliterated at any time. Our customer may or may not accept this reality. At a minimum, we will understand our customers better by understanding their risks.

In addition to learning about potential customers, we also get a deeper understanding of our current customers by studying their markets.

More Sources of Customer Information

In addition to Michael’s five tips, we would suggest the following for each major player in the market:

  1. Read the annual report. In addition to market data, we will find out what the CEO believes to be the most important objectives of our customer. This will help with prioritization of requirements.
  2. Understand the users. Creating personas to characterize the users of our software at our customer helps us make better design decisions.
  3. Diagram the political power in the organization. Politicians hold the trump cards for all software projects. By understanding who the real decision makers and influencers are, we can markedly improve our prospects for successful software sales. [Note: This applies to enterprise software more so than shrink-wrapped software.]


It is neccessary, but not sufficient to understand a customer. It is far better to understand the market of customers.

Foundation Series: How To Read a Formal Use Case

Use case classroom

Use cases represent the activities that people do when interacting with a system to achieve their goals. Use cases are a very effective tool for communicating and documenting what a system is intended to accomplish. Formal use cases are use cases with a specific structure to represent the information. Knowing how to read a formal use case is important.

Formal Use Case

We wrote previously about formal use cases, covering the pros and cons with a brief overview, as part of our use case series. In this article, we focus on the elements of a formal use case, and how to interpret them.

When using a structured requirements approach to creating software, use cases represent the activities of classes of users, as they relate to the software being developed. Each goal, or market requirement, will have one or more use cases that support it. The easy way to think about it is that for a company to achieve a goal, someone has to do something (Make the Sale, Answer the Support Call, Update Account Information, etc). The use cases capture those somethings.
Here are the elements of a formal use case, with explanations:

Meta data

This is the information that identifies when the use case was first written and by whom. It may also include revision information, who made the changes, what was changed, and when and why it was changed. Revision history is a common meta data element in most business documents – we just normally don’t call it “meta data.” That’s an example of software jargon.


The title of a use case is more than just a heading like “My Summer Vacation.” The title is intended to provide enough information to identify what the use case represents without reading the use case. This can be useful when getting an overview of a planned project, validating requirements, or when scanning use cases as part of reviewing materials. The title should provide enough information for someone conversant in the domain, while being short. The ideal length is between 4 and 8 words and is a sentance fragment. Anything longer than a sentance is a horrible title. The format is subject verb object. Someone does something to or with something else.
Some examples:

  • Pilot performs pre-flight safety check.
  • Author adjusts plot element timelines.
  • Accountant reconciles accounts-receivable ledger.


A brief description of the activity represented in the use case. One to five sentances – no more than a single paragraph – describing the activity or process represented by the use case. The description does not include the full details, but does provide the “next level of insight” into understanding what the use case covers. Someone who is not experienced in the domain can get a base understanding of the contents of the use case from reading a description.
Some examples:

  • A pilot peforms an FAA mandated list of equipment and operational inspections prior to every flight. All inspections must pass before the flight is allowed to take off per corporate policy.
  • An author will review the timelines, or sequences of events for each plot and subplot within their novel. The author is assuring that the sequence of intended events is internally consistent, and achieves the desired pacing effects for the book. Any needed changes to the timeline are made.
  • Accountants regularly validate that the entries in the accounts-receivable ledger are consistent with the recent sales and current payments. This validation is required for all GAAP public reporting on a quarterly basis, and may be required more frequently for internal management accounting purposes.

Primary Actor

The primary actor is the person who is the subject of the use case, performing the verb of the use case on the object. A use case may have multiple actors but has one most important person. The term actor represents the person who takes action – not someone playing a role. Other actors may be involved, either as participants, or as infrequent or secondary performers of the use case.
Some examples:

  • Primary Actor: Pilot. Secondary Actors:Flight Crew, Sr. Maintenance Technician
  • Primary Actor: Author.
  • Primary Actor: Financial Accountant. Secondary Actor: Financial Accounting Manager


A trigger is the outside event that triggers the beginning of a use case. This is an event that initiates a use case. Many use cases do not have an obvious trigger – and the trigger will be documented as “User decides to do X.” This invisible decision represents the trigger.

Some examples:

  • Pilot receives flight plan.
  • Author initiates review of the novel.
  • It is the first day of the last month of the quarter.


Preconditions are the set of things that must be true for the use case to occur. These represent a contract of sorts – the use case will not happen unless all of the preconditions are met. If a situation is optional, it is not a precondition.

Some examples:

  • Flight plan has been approved.
  • None. (In our example, the author can review timelines before during or after completing a draft of the novel.)
  • Accounts receivable entries have been made in the ledger.


Post-conditions represent the other side of the contract. If the normal course (see below) of the use case has been completed, then these things must be true.

Some examples:

  • The plane has been confirmed to be safe and ready for the approved flight plan.
  • The timeline is updated to reflect the author’s desired result.
  • All accounting entries have been reconciled or identified as being incorrect.

Normal Course

The preferred, desired, or most common sequence of events that represent the use case. This sequence of events must be followable in the solution. If no alternate courses are defined, then this sequence of events must be followed (with no alternatives) in the solution. The normal course is documented as a series of single actor, single action sentences, each with a number.

An example:

  1. Accountant accesses current quarter accounts-receivable ledger information.
  2. Each of the following steps is repeated for every entry in the ledger.
  3. Accountant confirms transaction record matches appropriate other ledger (sales, billing, etc).
  4. Accountant updates ledger to indicate that the entry was confirmed.

Alternate Courses

Alternate course are supported alternatives to the normal course. Each variation is identified as an alternative, and each step that varies from the normal course will be explicitly defined within the alternative course. Each variant step is identified with a number, and all unidentified steps are explicitly defined to be the same as they are in the normal course.

An example:

A1: Incorrect ledger entry identified.

A1.3. Accountant confirms that the ledger record does not match the appropriate other ledger.

A1.4. Accountant updates ledger to reflect inconsistency.

A1.5. Accountant identifies proper value to reflect in the ledger.

A1.6. Accountant updates the ledger with the proper value.

A common naming convention is to begin the numbering with the letter “A” to represent that it is an alternate course, followed by a number indicating which alternative it is. In the example above, we have a single alternate course, “A1: Incorrect ledger entry identified”. In this example, steps 1 and 2 of the normal course are identical, steps 3 and 4 are replaced with new steps, and steps 5 and 6 have been added.

If another alternate course were defined, it would be numbered “A2”, and if it provided an alternate for step 3 in the normal course, that step would be numbered “A2.3.”


Another situation that happens with alternate courses is that a single step in the normal course can be replaced with multiple steps in an alternate course. To represent this, we add a letter, denoting that the steps are all combined to replace a single step. In the example above, we replaced step 4 and added steps 5 and 6. An alternate course may also be documented as follows:

Another example:

A1: Incorrect ledger entry identified.

A1.3. Accountant confirms that the ledger record does not match the appropriate other ledger.

A1.4.a. Accountant updates ledger to reflect inconsistency.

A1.4.b. Accountant identifies proper value to reflect in the ledger.

A1.4.c. Accountant updates the ledger with the proper value.

Exception Courses

An exception course identifies how the system should behave when something goes wrong in the normal course (or an alternate course). If there are multiple exception behaviors, they will be called out as separate exception courses.

An example:

E1: Unable to access accounts receivable ledger

E1.1. Accountant fails to access accounts receivable ledger information.

E1.2. System presents error message to accountant explaining access failure and reported cause of failure.

An exception course is identified with the letter “E”, and otherwise follows the same numbering conventions as the alternate courses.


Sometimes use cases are broken down into smaller, reusable use cases (such as login steps, using a search window to find an account, etc). A reference to another use case from the includes section indicates that the referenced use case is a subset of this use case.

An example:

The use case of “Accountant Prepares Quarterly Report” could include the use case of “Accountant reconciles accounts-receivable ledger”.


Each use case is written to support one or more market requirements (goals). The specific goals that are being supported will be identified as references, or traces.

Each use case is also supported by one or more functional requirements. References or traces to each of these requirements will be identified in this section. These references allow product / program managers to understand the impacts of changes and delays in implementation on the overall product delivery schedule.


All assumptions that are implicit in the rest of the use case will be explicitly documented here.


  • Pilot is certified to run a safety-check.
  • Airport allows pilot to run her own safety-check.


Any text that helps the author or potentially helps the reader is documented as notes. These are not requirements documented in the use case, any more than notes in the margin of a book are part of the book.


With this understanding, reading any formal use case will be a breeze.

– – –

Check out the index of the Foundation series posts for other introductory articles.

The 8 Goals of Use Cases

Climber with goal

Why do we write use cases?

We write use cases for the same reasons that people use our software – to achieve goals. In our case, we want to assure that we are creating the right software. By looking at this high level goal in more detail, we can make decisions that drive the best possible use case creation. Let’s apply our product management skills to writing better use cases by writing an MRD for use cases.

This article can be used as a guide to develop a process for defining, documenting and gathering use cases. It can be used to define a template for use cases, and it can be used to define specifications for a use case management system. We will start with a market analysis and a vision statement, and then create our market requirements.

Market Analysis

Bad requirements are further detailed as the following:

  • Requirements that are overlooked cause us to fail to meet expectations and fail to deliver value.
  • Requirements that are incorrect cause us to incorrectly address problems and fail to deliver value.
  • Requirements that are poorly communicated cause us to implement incorrectly, failing to address problems and deliver value.
  • Requirements that are low-value cause us to spend time and money on problems that don’t maximize value.

Through the course of any long term project, requirements will change. This happens more when we use iteration and prototyping to accelerate stakeholder feedback cycles. But that’s a good thing, because the changes result in better requirements. Agile development methodologies like feature driven development supercharge this phenomenon.

Vision Statement

We will improve our ability to write and manage use cases so that we may maximize their impact on

  • Writing and maintaining great requirements
  • to improve our ability to deliver the right functionality
  • and ultimately achieve software product success

Market Requirements

With an understanding of the market problems and a guiding vision, we will document the market requirements for writing better use cases. The market requirements have an explicit scope – they specify which and how much of the market problems we intend to address.

When we use the phrase ‘our use cases‘, we are really saying ‘our use cases and our approach to managing the use cases.’ We’re using shorthand to improve the readability.

Prioritization of the requirements is denoted with (H) (M) or (L) prepending the requirement, representing high, medium and low priority requirements, respectively.

Requirements that are overlooked

Requirements that are incorrect

Requirements that are poorly communicated

Requirements that are low-value


These goals define why we write use cases as part of software development. We do it to improve our ability to write the right software to solve our customer’s problems. We also write use cases to help us manage requirements changes and set delivery expectations with our stakeholders.

Companies Will Waste $1B This Year on Software Tools


We are collectively flushing the money down the drain.

Gartner reported that companies spent $3.7 Billion USD on application development tools in 2004, with a 5% annual growth rate. The Standish Group has shown that 40% to 60% of project failures are due to requirements failures. At least 1/3 of the money spent on getting more efficient at coding is being wasted – it should be spent on writing the right software.


Joe Marasco, CEO of Ravenflow, has written an article where he posits that we’re making bad investment decisions when it comes to improving our ability to create successful software. He’s provided data to support is argument.

The Standish Group, in their CHAOS reports has shown dismal software project success rates for the past decade. Digging into the details reveals 40% to 60% of the problems are caused by bad requirements.

Even when we know the problem is with our requirements, we also know that requirements management software will not solve the problem.

Problem Validation

Joe has the brilliant insight to recognize that with three CHAOS reports, we can produce a graph that shows a (possible) linear trend in improvement of a little over 1.5% per year in software project failure rates.

linear failure rate change

With roughly $250 Billion being spent on software projects per year, we are collectively seeing just over $4B in savings per year. Not a very good ROI for our projected $4B investment.

What if the linear assumption is wrong? We know half of the problems come from bad requirements, so there should be a limit to what improved coding efficiency can do. The graph may look more like this.

asymptotic curve approaching 50%

In that case, we’re about to have a negative ROI. Investment keeps going up, and results keep getting smaller.

Lies and Damn Lies

Joe asks “why so little improvement per year?” and raises an interesting point. Perhaps we are solving harder problems and achieving more value with fewer resources as we get more efficient at software. There is no way to reach an empirical conclusion on this, but we think he’s right – we are doing that. But we also think the law of diminishing returns makes the asymptotic curve more likely than the linear.

Engineers and Artisans

One reason that we are not improving faster is that software engineering is not engineering. [I say this as a former registered professional engineer]. Software engineering is requirements + code + test. Only coding and testing have elements of engineering in them. Requirements managers are artisans.
Software developers are making progress in abstraction and re-use. We don’t write in assembler any more. We have code libraries available to minimize reinvention, even in higher level languages. Software developers are becoming more like engineers every day as their behavior becomes more an element of applying existing code than writing new code.

Requirements writers bear no resemblance to engineers. Like carpenters hand-crafting furniture, we have little or no reuse in our process. We are artisans. Since we are addressing a “new” problem with each project, we may always have to approach things as artisans.

Becoming Better at Requirements

We’ve shown before that having better tools for managing requirements won’t improve the quality of the requirements any more than a better saw improves the quality of a custom cabinet. Faster and easier, yes. But not better. Artisans improve with training and experience. This approach makes sense as the best one for improving at writing requirements.

Over the last month, we’ve written a series of 10 articles targeted at writing better requirements. The focus of this series is specifically on improving MRDs, and the linked article contains the summary of all ten, as well as links to the individual articles. Topics like removing ambiguity, validating the content with stakeholders, confirming feasibility with development – all key to preventing errors.


We should be investing more of our time improving our ability to write requirements, and write the right requirements. Maybe we spend so much on becoming more efficient at writing code because we know how to do that.

A plant manager can easily rationalize spending money to make his assembly line run faster. He understands the problem, and can measure the results.

$4 Billion dollars are being spent trying to solve half the problem. Imagine what would happen if we took just 25% of that, and spent it trying to solve the other half of the problem?

In fairness, our industry isn’t ready to absorb that kind of investment yet, so we shouldn’t make such a dramatic shift.  How about 2%?

What is Product Management?

gum on a fork

For organizations that don’t already appreciate the value of product management, just trying to explain the role can be very challenging. Usually the “strategic product management” responsibilities are distributed throughout the org. Convincing them that a single person should be a product manager (and not also a marketer, project manager, or designer) is like convincing them to eat gum off a fork.

DotNet Guru has posted a simple explanation, from a development perspective of what makes a great product manager.

He lists three things (and goes into detail on each):

  1. Drive a product’s strategic roadmap.
  2. Cut features from release scope.
  3. Understand the customer’s business.

We can build on this to create an elevator pitch for what product managers do. The elevator pitch is the short soundbite you would use if you had an opportunity to “sell” an idea to a venture capitalist who is trapped on an elevator with you for a few brief seconds.

The goal of an elevator pitch is to convey enough information that the audience wants to know more.

We apply this simple approach to create an elevator pitch explaining product management.

The Elevator Pitch

A product manager works with customers to understand the problems they need to solve, and how their businesses really work. She also understands how software is made and how it can be used to change business. She identifies, values and prioritizes customer problems to be solved and validates them with the customer. She drives the vision for what the engineering team will create to solve the customer problems. She iterates to solve the inevitable conflicts between goals and engineering/project realities. She supports the marketing and sales teams in selling the product, helping for all customers, not single customers.


Someone said once that it takes longer to write short than to write long. I agree. Please comment on this post with any suggestions to improve this pitch. The criteria for changes:

  • You can not increase the word count
  • You can not use lists or diagrams – this is a (quickly) spoken pitch

Mozilla Director of Product Management Blog


The director of product management at Mozilla (makers of firefox) has started a blog, Sherman’s Blog, about how Mozilla approaches product management. From the first post on the Role of Product Management by Sherman (Dickman), I think this blog is likely to be one to watch.

Mozilla’s approach seems to focus mostly on inbound product management activities (determining what to build) based on the activities they identify. They have a plan to create an MRD for firefox 3.

A Couple Quotes On Requirements Gathering

If you ask a panel of home cooks questions about how to build a better oven, they’ll tell you. But if you ask them about the challenges of feeding a family each night, you might receive a completely different set of answers — answers that might suggest a new product opportunity (such as the microwave oven).

For example, Nike golf shirts now have SPF 30 protection. What types of questions did they ask consumers to come up with that idea?

One of the big challenges in writing valuable requirements is in identifying the value. We presented tips on interviewing to uncover requirements in January. Sherman provides a specific set of three questions that help maintain the focus on what is valuable and why. Check out their elicitation formula and see if you like this new entrant as much as I do.

Brainstorming Stirs the Pot


The Wall Street Journal apparently wrote a critique of brainstorming that questions its value. Bob Sutton (professor, author, etc) responds with an entertaining read. Prof. Sutton critiques the data analysis, the experiment execution, and the people involved. Seems the WSJ messed up on everything except the topic.

Brainstorming Matters

Brainstorming matters for product management, business analysis, and software design. Actually, I’m not sure what it doesn’t help.

We include brainstorming in our Top Five Requirements Gathering Tips, as a great way to unearth requirements that otherwise would be overlooked. One of the goals in requirements gathering is to innovate, and brainstorming frees people of the shackles that prevent innovation.

Prof. Sutton’s Critique

In his response to the WSJ, Professor Sutton points out three main critiques.

1. The measurement (# of ideas per session per person) is irrelevant, as it loses sight of the reason we brainstorm in groups – ideas feed ideas. Concept maps can be great tools for showing how ideas flow in group brainstorming. They also help to stimulate individual brainstorming by kicking our brains into spatial-association-mode. The WSJ doesn’t measure this in their studies. This does highlight the danger of measuring something just because its easier to measure. [We wrote about measuring product manager performance and the evils of easy-to-measure.]

2. The people were all unexperienced students, and there Prof. Sutton implies that the facilitator was not trained. This article shows the key steps for effective brainstorming facilitation, as well as ways to leverage the results specifically for requirements gathering.

3. The organizations that use brainstorming as part of their process were not the subject of the study.

To put it another way, if these were studies of sexual performance, it would be like drawing inferences about what happens with experienced couples on the basis of research done only with virgins during the first time they had sex.

Bob Sutton

Can’t top that.


Professor Sutton points out that even where brainstorming is part of the culture, like at IDEO, no one spends more than 5 to 10% of their time doing formal (group) brainstorming. He also points out that everyone there also does individual brainstorming. So the fact that the WSJ is comparing them in the first place is ill conceived. Each is only one component of any creative process.