Blog

Value is a key concept in digital product innovation. We’re always in the business of evaluating potential benefits to customers, or evaluating concepts to choose the best approach. At the same time, the term “Value” is used extremely vaguely and its usage is frequently debased. In this post, I draw on some simple distinctions and basic equations to clarify this area.

Types of Value

There are certainly many different kinds of Value and ways of creating it that matter to companies. Making progress towards its objectives, mission, and vision is, by definition, of Value to the company. Acting in accord with its “values” is also of Value to the company.

Just because the financial consequences (indirect benefits) of these activities may be impossible to calculate doesn’t mean they are of no Value. It is only that their Value should be assessed qualitatively, rather than quantitatively. Incidentally, it is much better to leave their assessment in purely qualitative form than to force it into a pseudo-quantitative form, although this is often done by decision analysts. When combined with poorly-defined fundamental concepts and simplistic mathematics, planners and decision makers can easily be mislead about the consequences of their choices.

On the other hand, many things of Value to a company that are difficult to estimate—much less calculate precisely—can still be handled very well through more sophisticated means of quantification, such as probability distributions.

The Meaning of “Value”

But before we can discuss complicated types of quantification, we must first get clear about the meaning of Value itself. Part of the difficulty talking about “Value” is that there are many loosely-defined terms used as synonyms for Value or for each other, including

There isn’t much hope of establishing solid foundations for this field without carefully defining these terms and clearly distinguishing them from each other. The absence of such clarity is very likely to have been responsible for much of the unsatisfactory strategic planning in the product-development field, causing inefficient projects and less business benefits than could be achieved.

Knowing the Value of each potential Solution to an environmental problem is critically important to owners for many obvious reasons. These include

• Choosing the strategy that produces the highest Value
• Demonstrating Value to management, as Solutions reduce liabilities and risks
• Increasing Value by finding higher-Value Solutions

Anything that increases present or future profit, however directly or indirectly, has Value to a company. It can be calculated in three distinct ways. The next three parts of this post give the equation for each.

The First Equation for Value

Let us begin with a clear, solid definition of financial “Value,” putting aside the conventional ERSP assumptions that tend to confuse the concept. The first, simplest, general definition of Value (V) is

B is Benefit and C is Cost. For example, if the Benefit of $2M of product-development work is that it reduces a $10M liability (say, average monthly cost of unsold hotel inventory for a resort) down to $5M, the Value to the company of this activity is

In many circumstances, calculating Value as B – C is most appropriate, partly because it produces a Value in dollars.

The Second Equation for Value

However, there are other circumstances where a second way to calculate Value is more useful—as a percentage (the familiar cost-benefit ratio):

For example, if you are considering buying one of several computers with different levels of performance and different costs, you can divide each computer’s performance score by its cost to get a measure of its Value in terms of its costbenefit ratio. Another example, in the area of investing, would be if you invest $100 for a year and it turns into $150, you would say your Benefit was the $50 appreciation or return ®) on your Cost, which was an investment (I) of $100. This produces a 50% Value or Return on Investment (ROI).

The Third Equation for Value

A slight refinement of this equation leads to a third way to calculate Value, which is more meaningful when the Benefit is not merely appreciation on the principal of an investment (its “Cost”).

For example, if you pay your financial advisor $1,000 to find some better investments for you, and these investments improve your annual income from investing by $5,000, the Value you received from the financial advisor would be

In such cases, you have to subtract the Cost incurred to produce the Benefit before dividing by the Cost to get the true ROI. You took a chance on the financial advisor by paying him/her $1,000, hoping the advice would pay off. When it did, you ended up $4,000 (not $5,000) ahead for the year. This has the same effect as investing $1,000 and having it produce a $4,000 profit or ROI, which is 400%.

When people talk to me about “Agile Product Development”, this cartoon from Fast Company always comes to mind:

And as someone wrote in the comments: “Fewer steps, but more expensive than ever…”

It’s hard for industry practitioners to admit it, but Agile is just an admission of failure: the result of low-grade product strategy, leading to unusable and erroneous plans, leading to baseless designs, little collaboration with IT, terrible communication processes, zero feedback—all landing in IT’’s lap for implementation, and IT feeling on the hook for all of it.

Is it any surprise that they turned around and declared that planning is a waste of time, fixed bid impossible, and champion trial and error instead?

But hold on a minute, didn’t we, as project managers and product managers, try to get IT’s cooperation in understanding what could be done, specifying it, and estimating what it would take to do? Wasn’t that information consistently not worth the powder to blow it to hell?

As for whether Agile is really a good software development methodology—that is something to discuss later (but think, maybe projects just got smaller, or simpler, with the rise of the web and modern programming frameworks—just a thought, because it would be enough to explain all the gains purportedly accruing from “Agile”). Here, I just wanted to point out a couple of much-overlooked facts that one notices if one “follows the money”, by asking the question: who really benefits from the Agile process, who gets what they’ve always wanted?

First, what do software developers and their companies get?

• Free themselves from software planning and requirements, something they’ve been trying to get away from for years as useless, top-heavy, bloated baggage that gets in the way of the real work
• Reverse the specialization of the software planning and design industry, by absorbing planning (such as it is) and design into their software-development teams, freeing themselves from one or more intermediaries between them and the end-client, something they’ve always disliked for many business reasons (who wouldn’t? who want’s to be dependent on another company’s work to win sales and satisfy your customers? who wants always to be in a position of discounting prices for subcontractor rates?)
• Abdicated scheduling, in favor of 30 day sprints that deliver top priority features, on the principle that “something is better than nothing”. Who could disagree?! Software developers have never been any good at planning or estimating, and instead prefer just to put their heads down and just make something that works! How could you argue with that? Why, are you against productivity? Are you against speed?
• Abdicate, contractually, any real responsibility for end-results: you pay by the sprint, or by the hour, and sign-off as you go. Behind you, a glorious trail of “releasable” features, in front of you, a glorious highway of future features and enhancements. No software company wants to be on the hook for whether the thing they developed is actually useful or what the business wanted, and believing that software is ever “finished” is a pipe dream. To misquote the poet W.H. Auden, “a program is never finished, merely discarded.”
• Make acceptance a matter of subjective customer opinion: objective criteria for quality and performance—that’s too risky. People don’t know what they want, they can’t agree. They pretend to agree, or think they agree, and then they change their minds. They’re always changing their minds. And who can blame them? The world is constantly changing. It’s just the way it is. If you need to agree on what to deliver, it has to be small enough, and tangible enough, and fast enough that we change our minds if we don’t like it without losing the farm.
• Demote project management: in Agile, project managers are low-skilled, low-paid project administrators (fancifully called SCRUM masters), compared with the full regalia of their Project Management ancestors. As everyone knows, software project-management has never been worth a nickle, so good riddance to those pesky over-paid project managers.

Second, what do their customers get?

• “Visibility” into the development process: every month, there is something to play with, tinker with, see if it works,
• Quit while we’re ahead: rather than year-long delays, we can cancel the project quickly if we realize it’s headed in the wrong direction
• Change our minds: as long as we’re willing to pay for it, we can change our minds–which of course we’re likely to do because there are next no plans or specifications to guide us

Can you smell what I’m smelling? Feedback welcome…

I once had to design an online checkout process that accommodated an extremely wide range of product types: lodging, tickets, rentals, lessons, air transportation, vacation packages, season passes, lockers, retail items, travel insurance, gift cards, events, and rewards cards. To accomplish this information-architecture miracle, I first had to answer the question: is there a manageable scheme that is capable of full describing all of the differences that could make a differences to sales and checkout for the target set of product types? Here is my scheme, which has since stood the test of time on other projects:

Introduction

Naming a company or product is part of what is traditionally referred to as “branding.” I have sat through many silly exercises and long, inefficient engagements conducted by branding companies designed to elicit a great name for a company or product. As a digital product-strategy consultant, I often find myself in the branding business, and I use an extremely rational, fast, yet very creative process, summarized below.

Stripped to its bare, rational essentials, branding is just the process of designing the verbal and non-verbal “identifiers” that single out a company and its products and services from the crowd, and groups them together into a recognizable family. Verbal identifiers are the names, taglines, and taxonomies for the company and its products and services. Non-verbal identifiers are commonly logo and corporate styles for palette, typography, stationery designs, copywriting, etc.

As part of this effort, we find a way to communicate, to the degree possible, the kind of customers, the kind of their unmet needs, the kind of benefits, and kind of product features relevant to the company while warding-off potential misunderstandings or negative associations. When done well, this is of great help to the company’s marketing and sales function. Only naming is addressed in this post.

1. What is a name for?
2. What distinguishes a good name from a bad one?
3. What difference does a good name make?

Drawbacks of a Poorly-Chosen Name

A poor name is a barrier to marketing and sales:

1. Confuses customers about what the company does or who they are
2. Misleads customers
3. Undermines confidence in the company and its products and services
4. Thwarts attempts to remember or use the name to connect with the company
5. Gives marketing and sales departments a lot of unnecessary and expensive work to do to overcome drawbacks of name

Benefits of a Well-Chosen Name

A good name facilitates marketing and sales by communicating, directly or indirectly:

1. Who potential customers would be (self-select themselves as potential customers)
2. The type of products or services offered
3. Reputation, authority, and scale of company

Criteria for a Company Name

The following outline is the criteria for a good company name. The importance of each criteria depends on the specific company situation. They should be rated before they are used. I have divided them into primary (which apply significantly to almost every situation) and secondary (varies with the type of company.)

Primary Criteria

1. Usable: short and easy to spell, ease to abbreviate
2. Categorizing: indicates what industry or type of company and/or type of products or services and/or who potential customers would be (context before content), at the right level of specificity (i.e. not too vague or too detailed)
3. Image: right image, status, or class for target customers (e.g., cheap, casual, popular, contemporary, cutting edge, risky, young, ordinary, formal, professional, reliable, special, exotic, alluring, exclusive, quality, high-end, traditional, conservative, safe, luxury, glamorous)
4. Memorable: e.g., uses puns, wit, humor, surprising or novel techniques, allusions or associations. e.g., “Just Desserts”
5. Fit: after initially talking about the company, will potential customers immediately understand why the company has that name? (accurate, clear, makes sense)
6. Unique: differentiated in spelling and sound from competitors; unlikely to be confused with someone else; not already trademarked or service marked
7. Strategic: anticipates company growth and future business lines; does not limit the company’s potential domain of business (another reason for meaningless names).

Secondary Criteria

1. Language Universality: has the same or approximate meaning in all the languages or are likely to trade in, or no negative associations (e.g., this is sometimes why Latin or Greek based names, such as LexisNexis, are used, as these are broadly meaningful in all Indo European languages, or why meaningless coinages are invented, such as Skype)
2. Differentiating: emphasizes the important and differentiating elements of the company’s key benefits (unmet needs/solutions relative to competitors), and not emphasize unimportant or undifferentiating elements
3. Authority: tells you who owns or runs or is connected to the company (e.g., famous owners, Fulbright & Jaworski L.L.P.; or if ties to parent or merged company are important)
4. Legal Entity: makes clear the legal form of the entity (indicates scale, solidity, reliability)
5. Locality: indicates where the business or service area(s) are located
6. Capacity or Size: indicates magnitude of the company (big or small, e.g., Global Payment Systems vs. Cherry Creek Boutique)

Miscellaneous Notes

The right frame for evaluating a name is from the point of view of a new entrant into the market. E.g., Nike is household name, but as an entrant name it scores relatively poorly. New names should not be judged by the same standards as old, established names. Companies have many more opportunities to modify or abbreviate their name once it has become established (e.g., Federal Express -> FedEx).

Meaningless names or coinages such as “Skype” are last resorts because they require so much explanation (i.e., expensive marketing) to get established. They are appropriate if none of the relevant criteria below can be satisfied. This would be the case, for example, if you were a global company selling products with nothing in common among them, to everyone in the world. Coinages are by definition “innovative” and are generally associated with a young and informal company image.

Entrants in new product categories may want to coin new names in an attempt to dominate the associations of the whole product category or the activities associated with it. E.g., “to Xerox”, “to Google” for photocopy and search.

Product Category Naming

In most cases, needing to define a new product category is serious drawback for a company. This is because it is beneficial in most cases for potential customers, business analysts, and reviewers to understand the context of your company’s products and services without having to study them in detail. It allows them to pick you out as relevant with little effort; consider you in the right contexts where you have positioned yourself; make correct sense of your marketing messages (context before content); compare you against the right competition; and select you from alternatives in their decision-making processes. It also saves you from having to establish the product category, which is a time consuming and costly affair, and opens you up to a lot of skeptical scrutiny because most markets are suspicious of the impression of innovation carried by the introduction of a new product category. It is often inflated.

New product category naming should only be done if existing product categories are very inadequate, such as when the combination of the most significant categories of potential customers, unmet desires, product benefits, and product features are so different from the nearest existing product category that the business cannot get its message out without a new category. If it needs to be done, the business should restrict itself to subcategories, supercategories, or adjacent categories (i.e., consistent with a coherent product taxonomy). Cells phone vs. Smart phone is one example of an effective creation of new product category. Without the Smart Phone category, a Blackberry is reduced to comparing itself to a Razor, only bulkier with more features.

If you decide to define a new product category, it often advantageous to make the new product category part of the name of your product to help communicate it. E.g., Blackberry Smart Phone

Strategic Prerequisites for Naming

1. Who are your customers?
   1. Business Demographics
   2. Categories
2. What are their unmet needs/desires/self-interests relative to your company?
3. What alternatives do they “hire” to meet those needs, and what industries/product categories are they in?
4. What are the pros and cons of those alternatives?
5. What is special about your alternative (features) and how do its benefits compare?
6. What are your future areas of expansion? Customers, their unmet desires, new products, etc.
7. What kind of image do your customers respond well to relative to your company? (the following scheme is very simple, but surprisingly effective)

Linguistic Naming Techniques

For each of the ideas above, it is useful to brainstorm variant phrases using the guidelines below. These form the creative “soup” out of which effective brainstorming can form names.

• Synonyms
• Metaphor (speaking of one thing in terms of another, e.g., calling a piece of software a “workplace”)
• Humor (esp. word play or puns, e.g., “Just Desserts”)
• Metonymy (using part for whole, or using the name of one thing for that of another associated with it. E.g., referring to the President as “The White House”)
• Association (more important the shorter the name: ideas, feelings, literary, situational, etc.)
• Portmanteau (blending two or more words, e.g., Wikipedia is a blend of “wiki” and “encyclopedia”)
• Foreign or classical terms or etymological roots (e.g., Xerox from the Greek root “xer” meaning dry, or “LexisNexis” meaning a central connecting hub for text; often rely on our (unconscious) etymological familiarity with the terms)
• Acronyms (an abbreviation formed by the initial letters or syllables of a compound name that can be pronounced as a single word)
• Coinages (invented words, usually conforming to English phonology, morphology, and etymological roots)

Group Method for Naming a Company or Product

1. Introduce the problems of a bad name and the benefits of a good name
2. Introduce the criteria for a company name, a product, and a product category
3. Agree on weights of criteria for this situation
4. Try some worked examples with the group
5. Define/agree on the strategic prerequisites of naming
6. Brainstorm synonyms, metaphors, puns, metonyms, associations, foreign or classical terms
7. Brainstorm names
8. Critique against criteria, give a qualitative score, shortlist until you have a list of about four names all with high scores
9. Vote/pick the best name

One of the main contaminating ideas in the discipline of user-interface design is the idea of “user experience”. I mention this with some embarrassment, having been Director of User Experience in the past, run (and continue to run) workshops on User Experience, and worked as a User Experience practitioner for many years. But the elephant in the room was always that the concept never really made any sense, and was not the right way to describe what we were really after—something whose importance is not in question.

To put it simply, what matters is purpose, not experience. Who cares about experience if one’s purposes are not accomplished? Achieve the user’s purposes (which include all the desired qualities of great usability, aesthetic appeal, and inter-personal relationship qualities as criteria for satisfying those purposes), and the experience will take care of itself. The triumph of experience over purpose is principally the work of the media and marketing industries, who seized UI design from the grimy hands of the engineers who had been making unusable software for decades. But this solution was almost as bad as the ailment it was meant to cure, because it greased the rails for a takeover of the disciplines of software design and UI design by the marketing industry, aided an abetted by advertising as the chief use of the web in its early commercial years and arguably still today (as a percentage). The marketing industry’s preference (maybe forced on it by the quality of the products they have to market) for stimulating feelings over satisfying user’s genuine purposes has had and continues to have a deeply negative affect on the quality of software, especially online software.

To put things back the way they should be, user experience should be properly understood as a species of communication quality, founded on Communication Theory and the advanced disciplines that describe who to analyze, assess, and how to design a communication system: General Systems Theory, Cybernetics, Information Theory, and others. Not advertising, media production, or graphics design—although they have their role to play. The foundation of communication quality is clarity about purpose, which is to be found right in the very heart of the mathematical definition of information, as it was formulated from Shannon’s work by Gregory Bateson (to paraphrase):

Information is encoded news of a difference that makes a difference to the sender relative to some purpose, with feedback loop from the recipient to the sender.

To speak and think of Information as a “thing” is part of a “metaphorical family” we normally use everyday. This family of metaphors has been named “communication as conduit” by Lakoff and Johnson, after its most central theme (see Metaphors We Live By). For example, consider these ordinary expressions:

• It’s hard to get that idea across to him.
• I gave you that idea.
• Your reasons came through to us.
• It’s difficult to put my ideas into words.
• When you have a good idea, try to capture it immediately in words.
• Try to pack more thought into fewer words.
• You can’t simply stuff ideas into a sentence any old way.
• The meaning is right there in the words.
• Don’t force your meanings into the wrong words.
• His words carry little meaning.
• The introduction has a great deal of thought content.
• Your words seem hollow.

This family of metaphors is at the heart of the “Bullet Theory of Communication.” This is the theory that words are “containers” for meaning shot back and forth between people like those vacuum-pipe canisters in drive-through banks and old department stores. Although my simile is a bit of a caricature, this is the basic idea behind many theories of language and philosophy of language at large today.

Although we use the idea of Information as a thing, an object, a container, all the time, it is sometimes important to remember that this is just a figure of speech, and that there is actually no information to be found, anywhere.

How can this be?

For example, suppose you’re trying to get my help in firing a mortar over the brow of a hill to hit some target or other. Imagine we’re in the army. I’m your spotter. You fire a shot, and I peer through my binoculars and say, “Bob, you missed! Aim two degrees to the right.”

It would seem as if a piece of Information has come into the world, wouldn’t it?

Let’s say, then, that in this example you don’t do anything in response. You don’t fire, you don’t change your aim. Do I know if I have informed you of anything? I do not. Has any informing gone on? It isn’t possible to tell.

So what? Well, the point of this illustration is to show that all that’s really going on when we talk of information are processes of informing and being informed. The idea of Information is just a reification of those processes.

When we turn the processes of informing into a “thing,” we lose something important: 1) we lose the idea that the criteria for information having been conveyed has nothing to do with noises my mouth makes, or the scratches I make on a piece of paper, but the behavioral outcome resulting from the interpretation by the recipient; 2) that the meaning of a piece of information only exists relative to my purpose in sending the message (pace Roland Barthes); and 3) that I can only be said to have informed you when you provide some feedback to show me that you have understood me correctly. I.e., you turn 2 degrees to the right on your next shot.

Even if you reply, “Right you are, John,” but you don’t do anything else, I still cannot be said to have informed you. Who knows what you think I said? You might have thought I said “That sodding hissed! Maimed too many trees you blight!” (well, you get the point.) Feedback is necessary for informing to happen.

In short, it useful to remember this definition of Information:

Information is encoded news of a difference that makes a difference to the sender relative to some purpose, with signature, address, and feedback.

In this example: Encoded (English), news (about your shot), of a difference (that it missed), to the sender (me), relative to some purpose (hitting the target), with signature (from me), address (to you, Bob), and feedback (you change your aim 2 degrees to the right on the next shot.)

This definition is founded on Shannon’s Information Theory, but includes insights from Weiner, Bateson, Watzlawick, and Emberling. It is very simple, but very fundamental to all of the work we do in the fields of information and communication.

* Roland Barthes: famous for his theory of the “death of the author.” To the literary theory buffs among you, I should say that I am not trying to contradict all that is good and valid in post-structuralist literary theory, only to point out that whatever literature is, it is something rather different what I am talking about here. If I say “Pass the salt,” and you interpret that as my asking you to perform a god-like extraction of all the salt in the ocean and give it to you, we’re into something else…

So I came across this entry in Wikipedia on the “Information Age,”:

‘Information Age’ is a name given to a period after the industrial age and before the Knowledge Economy. Information Age is a term applied to the period where movement of information became faster than physical movement, more narrowly applying to the 1980s onward. Under conventional economic theory, the Information Age also heralded the era where information was a scarce resource and its capture and distribution generated competitive advantage. Microsoft became one of the largest companies in the world based on its influence in creating the underlying mechanics to facilitate information distribution. It has been estimated that the Information Age lasted from approximately 1971 to 1991.

The superficial problems with this are as follows: an  Economy does not follow an Age, only another Age does.  And a 20-year-long Age? That is more like a Blip. How can information travel faster than physical electrons? If this entry only refers to the transportation of information, then the Information Age was heralded by the steam engine. But that sounds nit-picky.

The most interesting thing about this Wikipedia entry (a resource that I find invaluable, but not for the reasons Wikipedia would like), is that it is a perfect example of how stuck we still are in Industrial-Age thinking about Information. The metaphors come thick and fast: it is resource, that can be moved at a certain speed, it is scarce, and it can be captured and distributed. In other words, Information is Raw Material, only slightly more elusive than coal.

I propose two attributes define the transition from the Industrial to the Information Age.

1. Shifting from power, energy, force, mechanical, self-contained, and “closed system” concepts, metaphors, ways of thinking, to informational, hermeneutic, epistemological, organic, inter-connected, and “open system” concepts, metaphors, and ways of thinking about things

2. Shifting from physical “forms of instantiation” of products and services to informational, digital, virtual, software forms of instantiation

And on there hangs a tail… I guess this is too much to go into right now. But what I think we can say is that we are a very long way from #1, and that most of our attempts at #2 are quite primitive because we are such a long way from #1.

What are the disciplines to pave the way for changing our thinking from Industrial Age ways to Information Age ways? They are General Systems Theory, Cybernetics, Information and Communication Theory, and Developmental Stage Theory.

“Inadequately defined requirements” has been for decades one of the biggest reasons software development projects go way over schedule and budget, are often canceled, or fail to result in a useful product. Many studies have concluded this. Here’s one oldie but goodie. I have participated in many atrocities of this nature myself. But these criticisms miss the point, I think. Requirements Gathering itself, as a method, will always be doomed to produce bad products. In this post I outline some of the reasons why, and it is meant as an intro to a solution to the problem, which I will write about later.

Requirements Gathering is typically the first phase of a software development project, but it has its parallels in non-software design. This is the part where the systems analysts or business-process analysts figure out what potential users want from the product. The satisfaction of these wants will be end-result of a successfully implemented product.

There are three presenting problems with this approach

1. It is often nearly impossible to know who your “users” will be, except in very narrowly defined situations, such as accounting software.
2. Users often don’t know what they want, or what they need
3. What most users say they want is often not very relevant for what they will actually find useful

But perhaps the most fundamental problem has to do with the whole frame of this approach: it bypasses problem-definition and starts with solutions. But solutions to what?

Designing this way is like designing by committee. It results in an incoherent laundry list of ideas, and there is no way to tell if you’ve captured all of them. There is really no way to know what “all of them” means. What you have is a list of possible features: but the fundamental question still remains: what is the purpose of this product? What is the purpose that will meet what needs? You need to know this first, before you can even ask potential users the right questions. Requirements-gathering leads to products with no focus, no core direction. No way of prioritizing features, except by voting on them, and they are vulnerable to whims, politics, and power.

Another way of looking at it: a product is a solution to a problem. By asking users what they want, you are asking people to come up with solutions to an as-yet unstated problem. You can implement all the solutions, and end up with something that doesn’t actually solve the real problem, because no one figured out what that really was. This may seem obvious, but it happens all of the time. People will keep coming up with more solutions, and they will change their minds during the implementation, because there’s nothing underneath it to guide it to tell if their requirements were the right ones, or whether any are missing. There’s no purpose. This is, after all, a planning problem.

Without a clear purpose and a clear hierarchy of “means” that rigorously “rolls up” to the purpose, you’ll never know when you’re done, or if you really succeeded. The underlying architecture of the product will be horrible, because sound architecture—both internally and in those external interfaces of the product the form the user’s experience—is a mapping of the product’s purposes on to the product’s features for the sake of usability. Without sound purposes, bells and whistles will vie for supremacy, the features will be disorganized, important ones will be missing, incorrectly defined, or irrelevant. Software architects won’t really know what they are doing. Ask any software architect or programmer: they hate requirements documents. They can’t design from them.

I don’t know how this awful method arose. But I would guess it arose from the failure of autocratic design methodologies whose principal focus was technology, rather than users and their problems. That is, arguably, worse. But what we have now is no solution.

What’s needed is a quite different approach, requiring a quite different set of ideas and skills from those that either users or techies can provide: digital product-innovation development.

Use Cases are one of the most commonly used parts of the UML (Unified Modeling Language), for expressing the Requirements of a new piece of software. But here are their flaws, and some suggestions for improvement:

Too low a logical class: this is shown up in the term “Use Case” itself. “Cases” are instances of things. As a software engineer, you don’t want instances of uses, you want the uses themselves. You may have to start with the cases, to get an understanding of the Use they are cases of, but the Business Analyst should end up with Uses, and not cases of Uses.

Conflates Dynamic, Static, and U.I. models (or, in other words, conflates means and ends): Use-Cases were partly intended to be a solution to the common problem of requirements-documents containing too much premature implementation detail mixed in with the description of what the user is meant to be able to do. But they have not gone far enough. Use-Cases mix in information about the U.I. (e.g., information about picking from lists, viewing error messages, confirming actions, etc.), and they don’t differentiate dynamic (about how the software will execute tasks) from static elements (how it will be organized, OO-style, into classes, properties, methods, and events) of the specification. This leads to kind of “impedance mismatch” when the software engineer tries to translate them into software architecture and programming specifications. Plus, the mixing-in of U.I. leads to a lessening of clarity of the core program logic, and a premature design of the user-interface, as well as, perhaps more often and more serious, the overlooking of much of the U.I., which in web applications can be a considerable percentage of the total code. Leading on from that, it encourages the team to think of the Information Architecture and Visual Design as “hanging out loose”, and leads to problems of integration, of how to easily put the whole thing together.

Obscures the holonarchy of vision, objectives, and goals for the software: the Use-Case model is not well integrated with the overall goals of the application. Yet the Use-Cases are meant to be an expression of what Users do to accomplish those goals. They are the means, whereas the goals and objectives are the ends. What this comes down to is a fundamental misunderstanding about what the Requirements phase of the software development process is. What it is typically thought to be is a “gathering” exercise, a compiling exercise, an exercise of interviewing people and finding out what they want. But it isn’t that. It is a PLANNING exercise. Requirements are really the Activity Plan level of the application, by analogy with a traditional plan. And as such, it is part of the Planning Discipline, which has its own sets of criteria for quality that are well-established, and far more sophisticated than anything you’ll find in the Requirements literature of software development.

If the Requirements phase is not understood as planning, and executed as such, many, many things go wrong: the requirements won’t add up to the goals of the application; the goals of the application will be poorly defined and misunderstood, but people won’t know it, or won’t know to know it; it will be much harder to estimate, plan, and divide up the work than it otherwise would be, resulting in project management problems; the software architecture will be worse, because, just as in an organizational structure of a company, such a structure is a mapping of the purposes of the organization onto its resources, its people. In the case of software architecture, the purposes are the Uses, and the resources are the Classes that accomplish those Uses. The architecture is the mapping of those Uses onto those Classes, using sound criteria for effective classification, organization, and nomenclature.

Too declarative: Use-Cases are intended to be declarative only. But the activity level of any plan is by its nature something closer to a flowchart: it has decisions and branches. In moving away from complex flowcharting of traditional specifications, and via a misapplication of the metaphor of Objects to Actions, Use-Cases make it hard to express the essential conditional dynamic of User Actions.

Unnecessarily Object-Oriented: The purpose of OO is to close the gap between the problem domain and the solution domain, by making the solution domain conceptually closer to the problem domain. The Uses of an application are in the problem domain, and therefore do need any gap-closing done to them. That is, if we use the appropriate conceptual framework, that of Planning. Actions roll up to goals, which roll up to objectives… individual actors work for teams that roll up to supervisors, that roll up to managers, that roll up to the organization as a whole. This is inherently object-oriented already.

To apply the methods of OO to Uses is a weird kind of mind-flip, where we take something that can be inherently expressed in the problem domain, and first suck all of that information out of it by construing Uses as objects, and then, we turn around and wonder how we’re going to put all that information back, and so we try to back-engineer it using OO forms of representation that we use in the solution domain (a domain of program classes, methods, properties, and events). This just makes the requirements unnecessarily complicated and hard to understand. It is a mindless application of the OO metaphor, losing sight of what we’re trying to accomplish.

Gives software-engineers too much of the wrong kind of work to do: Another reason for Use-Cases is to make it easier for the software-engineer to derive classes from the Requirements. The reasoning goes that if the requirements are in OO format, then it’ll be much easier to derive classes from Use objects. But this is not really the case: the domain of Uses is completely orthogonal to the domain of Classes. Uses are part of the dynamic aspect of the system. Classes are part of the static aspect of the system. For example, consider the Use-Case “Activates Credit Card.” The software-engineer is going to see that here we have a Method (”Activate”) of the a Class (”Credit Card”). In normal Use-Case representation, every time there is a case of activating a credit card, you will see a reference to “<includes> Activates Credit Card.” This kind of representation misses the point: the point is to give engineers what they need to write good software, and to do that, the Business Analyst must provide both a dynamic and a static model, because it is too hard to express both in one model. The dynamic model is isomorphic with the domain of human of purposes. The static model is isomorphic with the static OO domain of the implementation. So what this means is that instead of a lot of misguided OO information wasted in the Use-Case model, the BA should provide a static model, a logical representation, of high-level Classes, their methods, properties, and events, and that are needed to accomplish the Uses. The BA then x-references those for the software engineer.

Now the engineer is in the position he wants to be, which is to be able simply understand the requirements and now how they will translate into software. He will be able to see, at a glance, that the task “Activates Credit Card” is invoking the Activate Method of the class Credit Card. This will lead to a much more satisfactory breakdown of labor between BA and engineer, and much clearer, more accurate, more implementable requirements.

It will also, very importantly, provide an easy framework for the specification of the U.I. The U.I. is a mapping between the Uses and this static model. The fields in the U.I. are mapped to classes in the static model. Controller logic can easily be expressed verbally, in terms of transformations and conditions that obtain between receiving Input and writing Output. The resulting Requirements therefore would consist of three models: a Use Model (dynamic), a Class Model (static), and a UI Model (mapping between the two for the sake of user-system collaboration.) This is very close to the MVC framework that the application will actually be implemented in, thus making translation much easier.

Inconvenient to Document & Update: My final criticism of Use Cases is a purely practical one, that, even with CASE tools and their ilk, they are unnecessarily complicated to draw, and unnecessarily cumbersome to update. If they were simply expressed as a textual outline goals and actions, and x-referenced to actors and the appropriate class in the static model, life would be a lot simpler.

Looking back on nearly a hundred software projects, here’s my diagnosis of the top sources of problems that cause problems with quality, efficiency, and stakeholder satisfaction:

1. Perspective: wrong perspective on the true role of websites, online products, & communication functions for companies. A limited IT or Marketing perspective, instead of the right understanding of the Internet’s potential, married to a clear business-focus. These projects, after all, should only be done for the sake of worthwhile ROI for the company.
2. Research: not investigating the business reasons & goals for the project, to ensure that the project produces them. Not doing the right kind of research into the right questions, & making sound, well-informed decisions at each step of the project, including whether or not to proceed.
3. Planning: little or no planning at all. Relying on trial & error. Thinking that planning is either not possible or counterproductive (e.g., inhibits creativity). Poorly-chosen or ill-defined project-objectives. Relying on the design work to reveal the purposes of the project. Leaving “strategic” planning to design agencies or company personnel without the skills to do it right. Working from a plan that just isn’t detailed enough to do an adequate job guiding people’s work at each step in the project. Beginning design work, such as UI or visual design, without adequate specifications, or beginning coding without adequate designs.
4. Budgeting: setting budgets before planning, setting objectives, & making sound decisions. Then being stuck with an unrealistic budget for a project that isn’t fully understood.
5. Methodologies: critical steps done in the wrong order. Steps omitted. Conflating user-interface design with visual design.
6. Product development: inability to come up with innovative product-concepts without relying on geniuses or sheer luck, since no research into business objectives or user aims was done to provide the right foundation for innovation. Product development geared toward the wrong user aims, usually identified from demographic market-research. Product development done backwards: concepts/technologies in search of ways to profit from them. Merely copying the competition, as a common way of trying to cope with these challenges, which is no way to capture the dominant market-position.
7. Non-modular services: companies have to buy the whole service or nothing. Thinking they have to get one firm to outsource the whole project to—a myth propagated by design and development firms, which is really the result of poor or unclear methodologies that do not allow for modularization. Leads to the using the wrong people for parts of the project. No pausing for decision points & reevaluating whether to proceed, how, and with whom.
8. People: lacking the requisite perspectives & skills for their part of the project. The people doing this kind of work usually come from IT, marketing, or graphics design backgrounds. They rarely understand how companies really work and what online- solutions to their problems must entail. They rarely have the skills to do effective planning and project-management. They are only really set up to execute assignments given to them—not to research, innovate, make decisions, consider business needs, or define objectives. These critical first steps are therefore left to their client or business analysts, who may not know enough about the latest technology and its potential applications (such as how to virtualize various business functions) to do an adequate job of these things either.
9. Project-management: unskillful, haphazard, and sloppy. Ineffective communication and collaboration among members of the outsourced project-team and between that team and client staff.