The just-published overview of the requirements tool market is, at bottom, a story of unrecognized success. The requirements tool market has grown rapidly along several measures, including the number of vendors, the scale of adoption, and (the primary focus of the overview) the number of business problems that these tools are designed to address. From a small niche in the software market, requirements tools have grown and evolved, sometimes merging with other applications, to the point where it's hard to talk about them as "requirements tools" in the strictest sense of the term.
When colleague Mary Gerush and I dove into the primary research, we were immediately struck by the number of vendors that have crowded into a space that, to be honest, was not too long ago treated as a bit obscure and unexciting. The longer we looked at the market, the more little vendors appeared in the landscape. We'd heard of long-standing specialty vendors like Ryma, Blueprint, and iRise, but names like TraceCloud and AcuNote were new to us. The big vendors, too, have seen opportunities in this space, sometimes buying (for example, IBM's acquisition of Telelogic), sometimes building (such as Microsoft's Sketchflow tool).
Something was happening in this market, and at least a piece of the explanation was clear from the moment we started talking to vendors and users. Very few of these applications were exactly like the first generation of requirements tools, such as MKS Integrity and Borland (now Micro Focus) Caliber, and most of the newer tools bore little resemblance to each other. Although they share the title "requirements tool," they don't deal with the same aspects of requirements.
As readers of this blog know, I see a lot of benefits in using serious gaming to make better product and development decisions. Consulting firms like Enthiosys and Booz Allen Hamilton use different serious gaming approaches, but they ultimately have the same aim: Avoid the traps that we mere humans frequently make, even when confronted with a wealth of facts and reasonable arguments. The bigger the decision – for example, What will make us more competitive in the next five years? How do we make sense of all these enhancement requests? Should we pursue a new market? – the greater the need to guard against groupthink, the loudest voice in the room, information overload, and other common decision-making pitfalls.
While I could (and have) provided examples from business, an equally compelling example comes from politics. One of the offshoots of Enthiosys' work with businesses is Games For Democracy, a charitable foundation that, as the name implies, applies serious gaming techniques to political decision-making. A good example is healthcare, the topic of a Games For Democracy exercise using the "Buy A Feature" game. Each participant had a limited amount of faux money to invest in different healthcare options, such as the public option, a mandate for personal health insurance, and cost containment measures. No one had enough money to buy any option outright, so horse-trading among participants was mandatory.
Outside the technology industry, engineers sometimes build multiple prototypes before selecting one particular design. Rather than finding the defects of one proposed design, discarding it, and moving on to the next idea, engineering teams that apply this approach, set-basedconcurrent design, save themselves a lot of time and headaches by running through as many options as possible simultaneously. As you might have guessed, this technique isn't cheap. You need to staff multiple design teams, and prototyping in many industries, such as automotive manufacturing, is always expensive. Nonetheless, by delaying the design decision for as long as possible, until the team has found the best among multiple ideas, development can take less time, with a greater probability of building a good product, than with sequential design.
So why don't we build software this way? For Microsoft, SAP, and other technology companies, prototyping is orders of magnitude cheaper than it is for Toyota and General Motors. Executives at tech companies would love to reduce the unpredictability of development schedules, often thrown off-track by unexpected design issues. So why hasn't set-based design caught fire in the technology industry?
That question has been plaguing me since hearing an excellent presentation by Jean Tabaka and Bill Wake on this topic at Agile 2009. I'm not sure of the answer ("More research required," says the analyst), but I'd be amazed if it didn't include two factors: (1) the nature of the product being developed; and (2) the unspoken assumptions of the tech industry.
The Australian product management consultancy brainmates just published the results of a survey on a very interesting topic, social media usage among PMs. The short list of questions get right to the heart of the matter: Do you expect to be using social media more?
The brainmates survey indicates that PMs are ready to embrace, or bracing themselves for, social media as an increasingly useful tool for product marketing, product feedback, and collaboration. In contrast, PMs do not expect to be increasing their use of social media for monitoring "to find references to their products or services and any references related to their market, customer segments or competitors." Interesting, especially given how much electronic ink that social medianiks have spilled about using Twitter, Facebook, et al. to see ourselves (or our brand) as others see us.
If you're still baffled, flummoxed, or concerned about Facebook's now-infamous privacy policies, here's a handy chart from The New York Times. (Thanks, Madiha, for the pointer.) While the diagram retains a neutral tone, it's hard to read the phrase 50 settings with over 170 options without having a "What the hell?!?" moment.
In defense of Facebook, they're no worse than many technology companies that devise confusing UIs, full of knobs and dials that users don't understand or use. These companies are still to blame for creating the circumstances in which a confusing UI is hard to avoid, so they're not completely blameless.
An apology to future generations
Here's where we venture into the idiosyncratic sub-culture of the tech industry, which is hard to understand if you've never been part of it. In spite of having big development budgets, a staff of seasoned professionals, and months to build a useful product, tech companies repeatedly build software that begs the question, "Daddy, why is your product so hard to use?" (Even weirder: usability is often inversely proportional to the price.)