If you understand the important market problems, you can make a good product.  If you understand how important each problem is, for each group of customers, you can make a great product.  If you’re new to this series, go back and start at the first article, we’ll wait for you right here.

Overall Product Comparison Process

This is a relatively long series.  Each article will start with a recap of the overall process.

Getting useful information from comparing products requires you to:

1. Introduction & Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems they care about solving.
4. Determine how important solving each problem is, relative to the other problems, for your customers. (This article)
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition.
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to the others.

Important Problems

In the previous article on defining market problems, we identified 6 personas / contexts by which we would compare the kindle fire with other products.

1. Tina - A hi-tech prosumer who is using the device to get smarter about the latest trends in her industry
2. Tim - A hi-tech prosumer who is using the device to enjoy niche fiction content, particularly comics, e-zines and self-published works
3. Kenny - A typical kindle user who is using the device for his work in the finance space, studying proposals and business plans, etc
4. Karla - A typical kindle user and voracious reader who is using the device to eliminate the large pile of books on her nightstand
5. Chris - A basic consumer who would is studying business in college
6. Christina - A basic consumer who is in a book club, and who is always reading the latest best seller

The reason it was important to identify contexts is that the important aspect of personas is to identify groups of users with homogeneous perspectives on the relative value of solutions to particular problems – and the three personas previously identified would place different values on the solutions, depending on the context in which they were using the device.

Revisiting the Market Problems

We also identified a set of problems that these personas would want to solve.

1. Read Anywhere – Be able to read content in multiple physical environments / on multiple devices, and not lose my place in the book.
2. Annotate – Be able to annotate / highlight what I’m reading for future review.
3. Talk About It – Be able to have conversations with other people who are reading what I’m reading.
4. Find More to Read – Make it easier for me to find other content that I would like to read.
5. Subscribe – Be able to subscribe to magazines / newspapers / blogs / serial publications.
6. More From My Network - Be able to read what people I trust are reading.

This process is iterative, and in reviewing the 6 problems above, a valid question is – are problems (4) and (6) different versions of the same problem?  When writing requirements, it is important to specify the problems and not the design.  This is a tricky one, as it blurs the line between requirements and design.  Reasonable people can make either of the following interpretations:

• The market requirement is to “find more to read” by any means necessary – it could be through receiving recommendations from the user’s network, or it could be based on some not-specified “black box” heuristic and scoring algorithm.  These two requirements are duplicates.
• Yes, ultimately the user is trying to find more to read, but this is actually too abstract – consider the goal of “enjoy using the device,” which is also the ultimate goal, and too abstract to be useful in guiding the product creation.  Asking people you trust for recommendations is a well established practice for finding reading material, and people make the distinction that it is inherently different from, and provides unique value relative to other approaches (like finding similar products, or “people who bought this also bought this other thing“).

Based on research I’ve done for previous clients (primarily on findability and recommendations in an eCommerce context), my personal perspective is that these problems are distinct, and should be treated differently.  This is one of those Art of Product Management situations, where different product managers can, will, and should reach different conclusions.  For this analysis, the problems will be treated distinctly, and the data that I invent will reflect that I believe these problems would manifest with different importance for different personas in different contexts.

In contrast to the above analysis, problem (1) conflates the two notions of “multiple devices” and “multiple environments.”  People familiar with eInk technologies and Amazon’s Whispersync technology may see these as independent solutions to reading in direct sunlight, and moving from device to device respectively.

I’ve combined these two ideas, primarily because of the influence of this presentation about multi-screen strategies from Precious , a design and strategy consultancy.

[image from Precious article]

My interpretation is that the notion of device shifting is something that is intentional – use the right device for the right environment – and not arbitrary.  Based on that, and the technologies that enable reading in different physical environments – like direct sunlight or a dimly lit room – should be evaluated as part of implementing a device-shifting strategy, and not independently.

Combining these two (in this example) is an opinion-based decision, just as keeping problems (4) & (6) distinct is an opinion based decision.  If the data you gather in identifying problems leads you to combine or separate those problems, do so.

Gathering the Data

In the previous article on identifying market problems, I indicated that you are using a mix of qualitative and quantitative data-collection techniques to identify the problems.  It is during those activities that you also quantify the relative importance of solving these problems.

Innovation Games are a particularly engaging way to gather this type of information [disclosure: while I haven't formally done work for the company, I have worked with and know and respect the founder Luke Hohmann , and likely will work with him again in the future].  I’m including them here because they have worked for me.  A couple examples:

• 20/20 Vision – get customers to put solutions to the problems into relative order (for them).  Effectively, a card-sorting exercise.
• Speedboat – the relative priority insight you get from this game comes when people put anchors at different depths, indicating the severity of a particular problem.
• Whole Product – this brainstorming game can also be used to identify what people perceive to be Must Be (table-stakes) capabilities of your product.

Surveys can also be used to gather data when you need to get feedback from larger numbers of people, or are operating in an environment that is less collaborative.  A simple approach – ask the question “How important is it to you to solve problem X?”  Read up on Likert scales to understand the dangers of asking this type of question, and determine if you need to bring in someone who is an expert at survey design to minimize the impact of bad survey design in your results.

Quantifying the Results

Using the word, quantifying, may not be wholly accurate here – it implies something scientific, when really you are synthesizing the data you have received, in order to eventually determine the relative importance of solving (or improving your solution of) specific market problems.  A made-up word like numberifying might be better.  If quantifying, used in this context, causes your head to explode, please comment below – I suspect this might be a hot-button for folks, but I’m not really sure if it is.

[larger image]

The above table shows hypothetical data representing the “quantified” relative importance of having a solution for each problem, to each persona / context.

For example, Kenny wants to use a device to review and annotate proposals and business plans – internal company documents.  He can do this on any of a number of devices, but the ability to do it “anywhere,” as long as he can annotate, is what really matters to him.  He’s not at all interested in capabilities to find more to read, discuss what he’s reviewing, or subscribe to new content.

For Christina, however, the act of reading is more social than private.  She is not worried about making notes in what she reads or subscribing to new content – she’s reading books and talking about them with her friends.

Gaining Insights

We’re not to the point in the series where we can actually compare competing products effectively yet, but you can already start to get insights.  Imagine you are designing a product for Christina.  Your business case is about going after the “Oprah book club” audience, and Christina is your target user.  You already know which problems are important to her, and more importantly, which problems are not important to her.  You can completely eliminate the subscription and annotation capabilities from your product and create something that Christina would love.

This step alone allows you to avoid the elastic user problem.

Usually, you aren’t able to design a product for just one user.  You can’t be all things to all people.  This is part of the analysis you have to do to determine what to build first – identifying the relative importance of problems to each persona.  The next step is to figure out the relative importance of each persona.  Combining the two allows you to understand the overall relative importance of each problem.

Summary

Creating a great product for your customers means not only knowing who your customers are, but also knowing which problems they want to solve, and among those problems, which ones it is most important to solve or solve first.  When comparing your product to competitive products, the best measure is one that compares the products based on the most important problems for each group of customers.

Recapping the overall flow of this series of articles on product comparison

Getting useful information from comparing products requires you to:

1. Introduction and Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems your customers care about solving.
4. Determine how important solving each problem is, relative to the other problems, for your customers. (This article)
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition.
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to other products.

Comparing products without an understanding of the important market problems by which to compare the products is a waste of time.  This is the third in a series on comparing products - jump back to the introduction if you haven’t already read the previous articles.  Go ahead, we’ll wait, then come back.

Overall Product Comparison Process

This is a relatively long series.  Each article will start with a recap of the overall process.

Getting useful information from comparing products requires you to:

1. Introduction & Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems they care about solving. (This article)
4. Determine how important solving each problem is, relative to the other problems, for your customers.
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition.
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to the others.

Too many product comparisons are actually mislabeled positioning papers, highlighting differences, and putting one product in the best possible light.  An honest product comparison must compare products in the context of problems that customers are willing to pay to solve.  Those are the important market problems.

Important Market Problems

Probably everyone reading this has heard the Henry Ford quip about how if he had listened to his customers, he would have built faster horses.  A great marketing sound-bite, but not actually true.  The market problem that cars initially addressed wasn’t “get there faster”, the market problem was “spent fuel” disposal (for horses) in major cities – 2.5 million pounds per day in New York City (hat tip to Super Freakonomics for the first reference I saw).  If cars had generated as much manure as horses, do you think they would have been as successful?

The first step in identifying the important market problems is to identify a set of market problems that might be important. Then you can form an opinion about which ones are important, based on which problems are important to the potential customers in the markets on which you are focusing.  Identifying problems is an unconstrained activity, like collecting seashells on a beach.  There will always be more shells.

You will find shells that aren’t very pretty or are broken.  You will find some shells that are “perfect”, and there will always be some shells that exist, that are “perfect” that you won’t find.  The tough part is knowing when to stop looking for shells and move forward with the ones that you’ve already found.  You have to decide when your shell collection is “good enough.”  You can’t have a collection that includes all of the seashells, you don’t want a meager collection with too few shells, and you want the best shells you can find to be the ones you display on your coffee table.

This is a good example of the debate between big up-front design (BUFD) & big up-front requirements (BUFR) and incremental product development.  In The Design of Design, Frederick Brooks provides a great discussion about this debate between rationalism and empiricism.  The best approach I’ve found to date is to use a combination of agile and waterfall techniques to strike a balance between good enough and right now.

The best approach that I’ve found to do this to combine incremental development techniques to the activities of product management, combined with timeboxing to impose practical, artificial constraints on the process.  An agile product management process looks roughly like the following:

[larger version]

The steps of market research, analysis, and synthesis are the activities you perform.  Data is what you collect, and insights are what you form.  Analysis of data also leads you to perform more research.  Synthesis of those insights into a cohesive vision for your product will lead you back to more analysis and more research.  Note that this process has no ending – it goes on forever – or for as long as you are trying to solve these particular market problems.

As an example – in the previous article we identified a set of personas for our Kindle Fire example:

For this series of articles, I will pretend that three personas were developed, in order to demonstrate this approach to comparing products:

1. Hi-Tech Prosumers – people who get excited about convergence, highly value additional multimedia capabilities, live a multi-device existence, and are acutely aware of competitive products.
2. Typical Amazon Kindle Users – people who placed high value on the reading experience, the convenience of being able to easily get new content, and the absence of a subscription fee.
3. Basic Consumers – people who read primarily on paper media, have recently started consuming multimedia on their computers, and anticipate becoming part of the “post pc era.”

I will also invent additional data as we explore the rest of the product comparison process.
Comparing Products Part 2 – Who Are Your Customers?

However, defining requirements for those personas risks creating a product that only satisfies the basest of goals – the lowest common denominators.  These examples don’t take into account the context of use – e.g. why is someone reading on their device? – and thus we are at risk of not creating the right product for any of them.  Even introducing two simple contexts

• Education - Reading for work or school (directed study) or to gain knowledge about a topic (undirected study)
• Entertainment - Reading for pleasure, the literary equivalent of watching a movie

You’re probably not going to want to take notes on the uses of foreshadowing and allegory when reading for entertainment.  It may be critically important to annotate key concepts and ideas when reading for education.

This single distinction should be clanging a bell in your head – it is very easy for one product to be better than another in one context of usage than in the other.  Looking at the three example personas from the previous article, there is not a good way to say “educational use is more important” for one group of people than for another.  If we iterate and refine our list of personas it will lead to a better comparison of products.

1. Tina - A hi-tech prosumer who is using the device to get smarter about the latest trends in her industry
2. Tim - A hi-tech prosumer who is using the device to enjoy niche fiction content, particularly comics, e-zines and self-published works
3. Kenny - A typical kindle user who is using the device for his work in the finance space, studying proposals and business plans, etc
4. Karla - A typical kindle user and voracious reader who is using the device to eliminate the large pile of books on her nightstand
5. Chris - A basic consumer who would is studying business in college
6. Christina - A basic consumer who is in a book club, and who is always reading the latest best seller

Identifying Possibly Important Problems

Now that we have a (better) idea of the customers for whom we are solving market problems, we need to create a list of candidate problems that might be worth solving.  I am not an expert on user research – so there may very well be a better way to do this, and hopefully someone will share that with us in the comments section – but here’s how I’ve learned to do it.  It is at least “good enough.”  The approach I’ve used is a 3-step process.

1. Seed the Cloud – Start with what you think you know already
2. Refine the List – Validate and enhance that list through qualitative interviews
3. Empirical Validation – Assess the relative importance of those problems through quantitative research

Seeding the Cloud

I like to start by capturing my initial ideas in a mindmap or concept map – an ad hoc, semi-structured view of ideas.

[larger image]

I will then drive some brainstorming (more on brainstorming) or idea-seeding or Innovation Games exercises to develop a refined list of market problems that might be worth solving.  These processes may lead to other artifacts and usually result in updates to my mindmap.  These exercises bring others into the exploration, so that it isn’t The World According to Scott – but it is still the world as seen “from the inside.”

Refine The List

What we’ve done at this point, while creating a set of questions worth asking, possibly, is still heavily biased as an inside-out view of the market.  It may be informed by previous research and synthesis of ideas, but it still reflects what we think about the market, not what customers in the market thinks about their problems.

The next step is to gather qualitative information from customers and potential customers that represent your target personas.

Anecdotally, this is the same process for driving outside-in innovation from a product management perspective.

Mostly-open-ended conversations with people that are reflective of your personas is how I transform from an inside-out view to an outside-in view.  I’m not asking people “what they want” (remember the faster horse), I’m getting validation that the problems they face are the ones I think I understand (waste disposal).  This usually uncovers additional problems I have not thought of, and discounts problems I may have thought were important.  Ethnographic research provides this type of information – and when I’m working with a team that does this work, I utilize it.  Usually, I’m not, so I will find representative users and ask them questions, or observe their behavior.  Essentially, I’m playing the 80/20 game – some insight is better than no insight.

Empirical Validation

At this stage, you still only have a list of possibly important market problems, but now you have much more confidence that the list is valid and mostly complete.  You also have some qualitative insights into the relative importance of problems to be solved (maybe you did a card-sorting exercise, or created interrelation digraphs, or played the 20-20 Vision game, to get those inputs).

Now you can gather empirical data, to gain some statistical significance to your analysis.  You can do surveys that help you characterize and profile user behavior.  You can even do analysis of social networks, to see which problems resonate and why particular products get good (or bad) word of mouth.

Amplified Analytics has a presentation on slideshare showing how they can mine statistically significant information about features in the context of products. [Hat tip to Gregory, for the pointer to this].

I would suggest using a similar approach to try and understand which problems people face (and solve) versus which features they prefer (as solutions).  But the same applies.  I’ve had good results creating surveys and using Google Docs to aggregate results that allow me to characterize problems, (reported) behavioral patterns – like frequency of use, and (reported) relative importance of solving particular problems (like performance times for specific actions), and quantifying data-characteristics (e.g. how many emails someone sends, and to how many different people, in a given day).

Example Problem List

Given that we’re not actually doing a rigorous (and free) analysis of the Kindle, I get to “pretend” that I did research following the examples above, resulting in the following list of market problems, that are of (at least some) interest to our target personas.  We’ll use this list moving forward in the rest of the series.

1. Be able to read content in multiple physical environments / on multiple devices, and not lose my place in the book.
2. Be able to annotate / highlight what I’m reading for future review.
3. Be able to have conversations with other people who are reading what I’m reading.
4. Make it easier for me to find other content that I would like to read.
5. Be able to subscribe to magazines / newspapers / blogs / serial publications.
6. Be able to read what people I trust are reading.

Summary

It is important to be creating a product with an identity.  That means knowing for whom the product is designed, and for which uses.  You have to know who your users are, and which problems they want to solve.  If you’re going to compare products, you should compare them based on their suitability as solutions to these important problems.

Recapping the overall flow of this series of articles on product comparison

Getting useful information from comparing products requires you to:

1. Introduction and Overview (so that the step-numbers align with the article numbers)
2. Identify your customers.
3. Articulate the problems your customers care about solving. (This article)
4. Determine how important solving each problem is, relative to the other problems, for your customers.
5. Characterize how important it is for you to solve the problems of each group of customers.
6. Discover which (competitive) products your customers consider to be your competition.
7. Assess how effectively each competitive product solves each important problem.
8. Assess how effectively each competitive product solves each important problem, for each important group of customers.

With this information, you can create a point of view about how your product compares to other products.

Attributions

• Thanks Stéphane Vandenwyngaert for the Model T photo.
• Thanks michaelaw for the smiling coffee drinker photo.
• Thanks Dora Pete for the self-portrait photo.
• Thanks Benjamin Earwicker for the spontaneous photo.

A lot of teams that I’ve worked on and with get hung up when thinking about defining requirements for “migration projects” and “system upgrades.”  There’s some intangible barrier to being market focused when it comes to improving existing internal systems.  Every new product represents a solution to an existing problem.  Why do so many projects move forward with teams that are blind to the actual requirements?

New Products

Even “revolutionary” products like the iPod are just addressing existing market problems.  Part of what makes this statement true is looking at things from a market perspective – thinking about the valuable problems that people are willing to pay to solve.  Even if the iPod were the first mp3 player (it wasn’t), it would still only be an improvement.  The first mp3 player was not new, it provided an improved way to listen to your music on the go.  You could put your whole music library in your pocket.  Much better than a stack of cassettes melting in the glove box of your car, or a tape getting caught on your keys and unraveled when you pull it out of your backpack.

What’s important, and difficult (especially for people with technology backgrounds), is to think about it in terms of what people are trying to accomplish – not how they are trying to accomplish it.  In a business process view, it is the difference between process (why) and procedure (how).

There’s a continuum of migration projects, ranging from completely new to identical processes.  Neither extreme technically exists – think of it as a range from infinite change in the existing process to 1 / (infinite change) in the existing process.

Near the “completely new process” /infinite change end of the spectrum are processes that are completely new to you.  Remember, you’re solving a problem, perhaps in a very innovative way, that people are already solving some other way.  You’re just providing a better solution approach.

Near the identical process end of the spectrum are projects are “pin-compatible” platform migrations and near-sighted legacy system migrations.  Moving from an old gas-guzzling car to a new, more efficient model is a good example.  I mention “near sighted” because that old system was designed to meet an old set of market needs, so the new system will, by definition, not meet current market needs – it will only meet the old market needs.  Pragmatically, when considering organizational change, it may make sense to do your system upgrade in two stages: migrate the systems (“nearly identical process”) and deal with all the gotchas of migration first, then start re-engineering the processes and optimizing the procedures to address new market needs (major and minor process changes, respectively) second.

Set aside the possible, possibly rational rationale* to migrate the implementation first, and the functionality second.  Consider that a deployment and logistics detail and get back to the problem at hand.  Most of the times I’ve been involved in system migrations, they have been initiated as cost-savings platform projects.  Over the last few years, more often the migration project gets prioritized as a means to an end – “doing new thing X is prohibitively expensive on the old system.”  That opens the door to talking about goals.

* Couldn’t pass that one up.

Capturing Goals

On a recent project to migrate part of a company’s operations from one platform to another (system consolidation, after an acquisition), I created the following Ishikawa diagram to represent the goals for the migration project.

Even a “don’t change anything” project has real underlying goals.  Once you discover them, you open the door to having conversations about making things better.  Might be a “do it later” situation, but often, there is an opportunity to grab some of the low-hanging fruit during the system implementation.

The most important reason to capture the goals when “everyone already knows the goals” – aside from the fact that that is never true – is to make sure decisions are being made eyes-open.

Requirements live outside of the timeline of a particular project.  Once you’ve identified those requirements (aka market needs / company strategy), the next question is to determine which of those goals this project is intended to support or advance.  That question drives a lot of clarity into strategic thinking, and those answers drive a lot of clarity into project execution.

When you don’t share the context of the goals of the project, you are effectively blindfolding your team.  You prevent them from discovering opportunities to make things better.  You prevent them from making the right choice, when decisions are otherwise (without the context of goals) arbitrary.

For example, we talk about satisficing as a means to know when to ship – when it is “good enough.”  Without context, the opinion of “good enough” comes from someone on the team, without guidance.  In an agile environment, with self-directed teams, you’re making a trust-based decision to explicitly empower the team to make those decisions.  Don’t you want to give them some information, to help them make that decision?

Conclusion

This article really only explores part of the process of making real, large, projects happen in large environments.  That is a topic I’ll be talking about in a couple months.  You won’t get a sense of sated accomplishment from reading just this article – too much of the end-to-end, start-to-finish of real projects is unaddressed.

You will, however, know how to start the project.  Define the goals.  Someone will tell you the goal is to “Copy what the old system did.  We don’t have time to re-engineer.  Why are you bothering me?  Let me know if I need to find someone who can get the job done.”

Now you know how to respond.

**Attributions

Thanks foxtongue for the blindfolded typists photo

Ask someone what they want, and they’ll tell you they want a faster horse.  Provoke them, and they’ll tell you they have a ‘get there faster’ problem, an ‘equine waste disposal’ problem, and issues with total cost of ownership.

Thought Provoking

If your requirements elicitation session looks like the photo above, you’re doing it wrong.  However, just asking people what they want and confirming that you heard what they said is also not enough.  Active listening is important, but to capture great requirements, you also have to provoke thought about why someone is expressing a “requirement.”

Adrian Reed wrote a great article this week (hat tip to Kevin Brennan) on asking provoking questions that leverage lateral thinking techniques to get better insight into the true requirements.  Adrian presents eight questions, such as “Imagine if we fast-forward to 2 years after the implementation of this project, what will the organisation look like?”  Some of his questions remind me a lot of the ideas behind Enthiosys’ Innovation Games (and Luke Hohmann’s Innovation Games book).  The remember the future, and product box games immediately come to mind.

Unprovoked Thoughts

Most good subject matter experts I’ve met, when asked about the important problems to be solved, try and be really helpful and incorporate elements of solutions in their descriptions of problems.  They will say things like “the system must integrate with [other system] to do X.”  They may even ultimately be right, that this particular system integration is a constraint, and that “X” is the only acceptable (by policy) way to achieve “Y.”  But usually, neither constraint is a requirement – it is a solution approach.

Subject matter experts who are not as good at having and sharing insights about their domain often confuse problem manifestations with their underlying problems.  By analogy, it is requesting treatment for a runny nose, when the problem the you have is the flu.  You can dry up your nose and still feel horrible.

Provoking Questions Reveal Real Problems

Adrian’s questions are designed to help you understand that you’re treating the flu, and not a runny nose.  Requirements gathering is a lot like diagnosis of a medical malady.  You have to discover the real problems.  The problems that people are willing to pay to solve.  You have to uncover the latent problems that are “hidden” behind problem manifestations.

In a (rare for me) American football analogy – the problem manifestation is that your quarterback is completing 1 of 20 forward passes.  Replacing the quarterback and receivers will not solve the problem.  The problem is that your offensive line is not able to give the quarterback sufficient time to throw higher-probability-of-success passes.

Asking questions that force people to describe their objectives differently is a good way to bypass solution-design answers.  It also creates chinks in the armor of problem manifestations.  Completing more passes is not the future you’re looking for, winning more games is the goal.  When you’re treating your flu, your goal is not to be sick – but with a dry nose.  Your goal is to be well.  When you ask someone to remember the future, they will will describe being not sick, not being dry-nosed.  The product box will be a description of a winning team.

Check out Adrian’s list of questions, and ask yourself, how do you get to the root causes?  Ishikawa diagrams (also known as cause and effect or fishbone diagrams) provide a great visualization tool if you’re a spatial thinker or a whiteboard-talker.  In the example below, you can quickly see that spending too much on fuel is part of the real problem – that the cost of operation is too high.  You can likewise see that under-inflated tires are a source of poor fuel economy.  Check out the Ishikawa article for an explanation, or this article on providing context (with Ishikawa diagrams), and this article on buyer and user personas for more examples of problem decomposition.

If you’ve got any examples of problem-statement-turned-problem, chime in below…

A picture is worth a thousand words.  A prototype is worth a thousand lines of code.  Two key elements of product management – and of agile development are elicitation and feedback.  Low fidelity artifacts can significantly improve both.  Polished, codified prototypes can create problems that prevent you from getting the benefits of communication.

Prototyping Anti-Pattern

David Bernstein has three good quick-read articles about prototyping in the agile zone.  The first one depicts the primary anti-pattern of prototyping – mis-set expectations.

As I was walking him through the different screens I could see he was starting to get uneasy. As I talked I could see him becoming paler and tenser, as if he saw a ghost. After a while I asked him if he was ok. He finally said, “You mean to tell me that I just wrote you a check for over $100,000 for less than a week of work?”

Prototyping Caveat

The second article is quick reminder of one of the goals of a prototype.

The purpose of a prototype is to elicit feedback from others or verify a design approach will work. When doing this we generally only concern ourselves with the “happy path” through our code.

A Prototype is Not a Product

David’s third article explores a little more about the mis-setting of expectations, and provides a good parallel from the film industry.

Prototypes are rough sketches without the robustness of a final product and it is often confusing to users when we show them a half-baked version of their project for feedback, even though they know it is not yet finished.

Agile Prototyping on a Napkin

David’s advice is (good and) primarily about using low-fidelity prototypes to avoid disrupting the elicitation and feedback process.  Folks in the user experience community have known this for a long time, and adapted their processes accordingly.  Back in 2006, I wrote about prototype fidelity as part of exploring ways to use this insight in requirements gathering.  Prototyping, in particular, is a great way to elicit implicit requirements – those unspoken (“you should have asked!”) requirements that your customer or stakeholder assumed you knew, or didn’t think to tell you.

Multiple Levels of Interaction

David focused on the initial “will this approach work?” elements of getting feedback on a design – and by inference, some low-fidelity user acceptance testing that the proposed approach will meet your customer’s requirements.  Jan Miksovsky wrote an excellent article (also in 2006) that provides excellent guidance on how much fidelity to build into your prototype, depending on where you are in the design process.  This is important – the type of feedback you need at different stages of your design process varies.  Jan proposes that the first prototypes be rough sketches, just as David points out.  Jan goes on to show how and when to add additional fidelity to your prototypes (read Jan’s article to see his great visual examples).  Like I said, the user experience community has known about this for a long time.

Prototypes Are For Two-Way Communication

The key element, and the reason for creating prototypes, is to get two-way communication.  A prototype is not just a status update about your design.

A prototype is the start of a conversation.

[thanks uninen for the image]

Prototyping is not only useful for design conversations, it is critical to understanding your requirements.  Yes, a prototype will you get feedback about the design-execution of your proposed solution.  More importantly, a prototype can help you make sure you’re solving the right market problems.

Prototypes Are More Than Interface Mock-Ups

The first thing we think about, and everything you’ve read so far in this article, is about getting feedback on the user interface of the product.  Prototypes are also useful for gathering business rules*, understanding system complexity, and defining, clarifying, and validating requirements.

*In that article, I show prototypes as “not being useful” for gathering business rules.  At that time, I was thinking in terms of interface mock-ups only, not other prototypes.

Use interface mock-ups when you need feedback about user interaction.  Use other artifacts when you need feedback about other aspects of your product.  You can use prototypes as an active-listening technique when gathering market data too.  There are lots of ways to draw stuff to help with communication.

I’ve regularly used flow charts to prototype processes.  Within those flow-charts, which are initially prototypes of how the product will behave, are decision diamonds.  Those decision diamonds prototype the enforcement of business rules within the to-be-created product.  In the spirit of DRY (don’t repeat yourself), a quick polishing of your process diagram can serve as a persistent artifact of the requirements.  Just like a user interface mock-up.

In more complicated scenarios, I’ve also used UML statecharts and data flow diagrams to prototype behavior.

In the section on up-front planning in last week’s article on risk management and release cadence, I talked about the mental leap that people need to make to envision a product that doesn’t yet exist.  Prototypes are like big springboards that help people leap that chasm of imagination.

Important Safety Tip

Don’t use the wrong prototype (mock-up, flow chart, etc) for the wrong conversation or with the wrong stakeholder.  Showing when and where business rules are being enforced (in the process being designed) is great for getting feedback about your interpretation and potential embodiment of those rules.  It will be a disaster if you try and have this conversation with someone who is not the owner of those policies – like a representative user.  Sometimes, policies are “owned” by non-technical people who struggle to read diagrams.  You may have to walk them through how the diagram works.  They’re smart – they’ll get it.

Just remember – use the right prototype to emphasize the right ideas, and elicit the right feedback.

As product managers, we talk about creating the right solutions with our products. Understanding the very real problems our customers face, understanding the very real opportunities our markets present, and manifesting that understanding in a product roadmap.

Other than being “not as good,” how expensive is it to build the wrong product?

The Cost of Poor Quality

There’s an analog to the market dynamics of making poor product decisions – executing with poor quality. Many research studies and articles have identified the market impacts of poor quality.  This has become so well accepted that people today cite it like a law of physics (one example here based on this 1988 IEEE research by Barry Boehm and Philip Papaccio) as the “1-10-100 rule.”  The primary conclusion of that research is that ten dollars spent on fixing bugs:

• Costs and saves $10 when you catch (and fix) the bug during implementation.
• Avoids $100 in costs when you catch the bug during QA and send the product back to development (then test again).
• Avoids $1,000 in costs versus waiting until your customers catch the bug in the field, causing the team to remedy the problems, rush out a patch release, and/or go to heroic lengths to manage a PR problem.

This is an opportunity in front of your product team – a 100x payback from investing in quality during the development process.  Of course, be pragmatic about it - if the cost of testing exceeds the cost of bugs, don’t test.

This is not a solved problem, by any stretch, but the solutions and methods to solve this problem are well understood now.  In fact, a 2001 article by Barry Boehm and Victor Basili shows that in some cases, the labor costs to resolve bugs can be as low as 5:1 – when considering a subset of smaller systems, when using more “agile” processes.  That lowered ratio does not take into account the lost market opportunities and the costs of cleaning up collateral damage to your product – just the immediately realizable (and measurable) costs of resolution.

One very real problem, when talking about “bugs” is in defining what a “bug” is. And the definition of a bug is a matter of perspective. A developer can reasonably assert that “if it meets the spec it is not a bug, it is working as designed.” What if the spec is wrong? The developer may not be guilty, but collectively, your team screwed up. There’s a “bug” in the requirements.

What Is A Requirements Bug?

Now things are getting interesting.

If you wrote a requirement that you interpret as “A” and your developers interpret as “B” – you definitely have a bug – the team won’t build the right product. For each $1 you could spend making sure you have bug-free requirements, you could:

• Make sure you have a shared understanding of the documented requirements through active listening before development begins ($1). Following the Rules of Writing Requirements will help prevent this miscommunication.
• Wait until the engineering team is ready to demo their progress ($10). They will have to build it again, because they built the wrong stuff.
• Wait until development is complete and QA is validating that the code meets the spec ($100). This gets tricky if you are thinking “A”, the developers are thinking “B”, and QA is thinking “C.”
• In classic throw-it-over-the-wall mode, wait until the product is launched, and it is the wrong product ($1000). Assuming “A” was the right problem to solve, the cost of entering the market with a solution to “B”, leaving “A” unaddressed, is impressively high.

This gets interesting because the above assumes that “A” was the right problem to solve. What if “G” was the right problem to solve, and “A” was the wrong market problem? Even if everything (else) is working perfectly – you document requirements for “A”, the engineering team creates a marvelous “A” and it launches without implementation errors – you still fail, and incur the 1,000x cost of a failed product launch.

There is an even larger opportunity in front of your product team – a 1,000x payback on discovering and choosing to solve the right problems for your customers and markets.

• Would Palm still be independent if the Pre had solved a compelling problem?
• Why did Intuit have to buy Mint.com – could they have embraced the same customers with Quicken?
• What is Garmin going to do now that “free” GPS mapping and turn-by-turn directions are becoming ubiquitous? If it is “more of the same,” how much are they wasting?

Wrapping Up

I’m not aware of any studies that show that “requirements bugs” fit the same 1/10/100/1000 cost explosion model that “implementation bugs” exhibit. Emotionally, it “feels about right” to me – it passes my “sniff test.”

There are times when days of research would have been required to avoid or redirect a few hours of implementation effort on projects I’ve worked on. And I’ve seen man-years invested solving problems that didn’t involve much more research.

My intuition from products and teams I’ve worked with is that it probably averages out somewhere around 10x.

What does your gut (or your data – if you have some, post a link below!) tell you?

One of my colleagues got into a debate with one of his colleagues about the differences between goals and requirements.  His opponent fired the following salvo: “[That] is not a business requirement in any company of the world…”

What you call your requirements is less important than how you communicate them.

Labels

I’ve worked with a lot of companies that use different labels to describe their descriptions of the problems that need to be solved. This is not another article about requirements versus specification (specification = design constraint, btw).

If you’re not a long time reader who’s followed the debates and discussions on this topic in the past, check out these articles and comments, where we’ve had some great discussions on that topic – with particular thanks to Roger Cauvin for keeping the debate front and center.

• Requirements Versus Design: Which is Which and Why
• Requirements Docs – One Man’s Trash is…

The central theme is that the debate about “what versus why” centers around differences in people’s perspective on the problem.

This challenge is not really about that (but it makes for good background).  The complaint my colleague received was really a critique of the way that the why of a set of requests was communicated and labeled.

Actionable Goals

Companies have strategic goals (increase shareholder value, gain market share, etc) that serve to guide the investments and activities of the organization.  However, for the teams that are creating products, those goals are too vague to be actionable.  I guess this is where my set of labels comes in.  I don’t think the labeling of a goal as a goal (versus labeling it as a requirement) is abstractly important, however, when people value making a distinction, here’s how I do it.

A goal is something your business (or user) is trying to achieve.  It is too abstract to have a single valid solution approach.  Once your business stakeholder(s) decide on a strategy by which they will achieve that goal, the business will define requirements for the actionable project(s) that execute this strategy.  This is an ideation step that lives inside the “why” box from a business analyst’s perspective.  Here’s an example:

Warehouse Manager

You’re in the IT department of a large company.  You’ve been assigned to support the warehouse manager (or COO, or vice president of order fulfillment or whatever).  Your warehouse manager is responsible for procuring the products that your company sells, keeping inventory on hand, and delivering those products to customers when they have been purchased.

Your warehouse manager is measured (or promoted) based on her performance relative to the following:

• The time that a customer has to wait between placing an order and receiving the product.
• The cost impact of warehouse operations on the products.

Your warehouse manager focuses on these two metrics because of your company’s goals – provide good customer service, be profitable, and grow revenue.  Those abstract goals influence product pricing – it must be low enough to grow revenue in the target markets, and be high enough to be profitable.  Since market pressures drive pricing decisions, typically a profitability target will then create cost-reduction pressures (profitability also influences pricing decisions, selection of markets, positioning within that market, etc).  A customer service strategy can also include a “you get your product quickly” component – as it does in this example.

Your warehouse manager now comes to you and says “I have an initiative to lower costs.”

Is this a goal or is it a business requirement?

Ultimately, it doesn’t matter what you call it, but for you to actually do something you need to know more.  That’s why my approach is to call it a goal.  Your warehouse manager’s problem is to lower costs.  You need to decompose that problem to understand how you (and your team) can do something to help her achieve that goal.  The reason you have to do that is that you need a problem statement at the right level of abstraction.

In elicitation conversations with your warehouse manager, you learn that all of the costs of operating the warehouse are allocated to the different business units, who operate as profit centers.  The warehouse operates as a cost center.  The warehouse manager treats each business unit as a customer, and provides a service of “fulfilling product orders” in exchange for funds that cover the costs of operation.  The allocation of costs is done per product that appears in the warehouse.  Since allocation is per product, it could be something like $1.30 per product in “warehouse costs.”  There are multiple sources of those costs (that are then allocated per product), and there are multiple ways to approach reducing the cost per product.

Your warehouse manager develops a strategy (probably a “mini-strategy” from the company’s perspective) to lowering costs.  She rules out “sell more products” as an approach, because she can’t control that.  She also can not affect her fixed costs (rent, depreciation, labor).

Eventually you discover that there is another cost hidden in the provisioning model – products are purchased, they sit in the warehouse for a while, then they are sold and delivered, and eventually money is collected from customers to pay for the products.  Your company has to pay in advance for the products, and doesn’t get their money back until funds are collected from the customers.  That money is “tied up in inventory” when it could have been invested otherwise – so there is a cost associated with high inventory levels, that directly correlates with the amount of inventory in stock.  When a new version / revision of a product is introduced, your inventory may become obsolete (it is definitely devalued).  And since markets are moving targets, your prospects of selling a product change over time – a risk that you will not be able to sell all of your inventory.

At the end of the day, the amount of inventory you have on hand has a cost.  The more you have, the more it costs.  A rule of thumb I heard 20 years ago was that inventory costs could be as high as 1/3 of the cost of the product for each year you keep it around.  If that is true, that is something like 0.5% added cost for every week the product is in inventory.  Here’s something the warehouse manager can potentially control.

Currently, your warehouse manager has 8 weeks of inventory on hand (on average) for products, which allows her to ship quickly.  She realizes she is adding 4% to the cost of the product.  She decides that if she can cut those costs in half, she will be a heroine.

Her business requirement is to reduce inventory levels from 8 weeks (on average) to 4 weeks (on average).  She also has a constraint that no more than 1% of orders be delayed by more than a day (due to running out of inventory).

Now you have requirements that are unambiguous and measurable.

Conclusion

Don’t trap yourself in worrying about the labeling of goals / requirements, but if you have to work with someone who does find that really important, before you call it a requirement, make sure it is at the right level of abstraction.  And of course, make sure you follow the rules of writing requirements.

Engagement – that’s what this whole product management blogging thing is about.  Check out what Tyner Blain readers found to be the most engaging articles in 2009.

Deep Dives

If you’re new to Tyner Blain, you may be surprised by the length of the articles here.  I joke that they are long because I don’t have time to edit.  Stewart Rogers jokes that they are long because I’m incapable of writing a short article.  If you’ve been here a while, you know what you’re in for.  If you’ve been here a long while, then you’re glad (like me) that I don’t write one per day any more.

Product Management is simultaneously a broad and deep discipline, requiring us to have a breadth of perspective combined with a depth of insight.  We then have to apply that in a market context, effectively navigating the political waters of our organizations.  Most of the articles here either try to skim the breadth of a range of related topics, or plumb the depths of a single topic.  Doing that in under a thousand words is pretty hard.  Most of the articles here also link to other articles, to try and provide even more depth and context, and encourage additional critical thinking.

One measure of the quality of the articles here is how often they stimulate readers to read further, or dive deeper into the topics.  While web analytics won’t allow us to measure how thought-provoking an article is, we can look to see how many people dive into the linked articles, versus how many people move on to something else.  We can measure the bounce rate of an article to see how often people leave a page without following any of the “tell me more” links.

Looking at ~170,000 page views at Tyner Blain in 2009, narrowed down to only those articles with at least 100 page views, here is the top-ten list of most engaging (or “least abandoned” if you’re a “cup is half empty” person) articles:

1. Use Case Series: Introduction: A collection of articles on the “traditional” forms of use cases – informal, formal, UML.
2. Agile Development of Use Cases: A dive into the dynamics and cadence of an agile process for developing use cases.
3. How Do You Manage Market Data?: A collection of articles exploring different market-immersion techniques in depth.
4. Scheduling Requirements Changes – Part 2: A focus on practical techniques for managing change with an agile development process.
5. Yesterday’s BPMN Post Was A Big Fat Lie: A mea culpa and clarification of interest to folks following the BPMN Series.
6. Everything I Needed To Know I Forgot in Kindergarten: Why asking why? is important.
7. Plan Your Next Sprint by ROI – Part 1: Prioritizing by Bang for the Buck, not just Bang.
8. Ten Common Mistakes of Going Agile: A collection of articles about common pitfalls encountered when adopting agile practices.
9. Perpetually Almost Finished Projects: Organizing a project with discrete deliverables and rolling-wave planning to avoid the “90% done, 90% remaining” problem.
10. How To Use Timeboxes for Scheduling Software Delivery: One of my personal favorites.  A rational approach to making trade-offs when your “perfect” plan has to change.

OK Stewart, that’s only 519 words.

There’s really only one way to travel down a waterfall – in a barrel.  A lot of people died this way, but some survived.  Software projects have been predominantly waterfall projects since the start of software projects.  And stakeholders rode down those projects, basically in a barrel.  The people riding Niagara Falls 100 years ago didn’t know if they would survive until they got to the end.  Stakeholders in waterfall projects don’t know if they will succeed until the end.

An agile project is dependent upon tight interaction (and feedback) with stakeholders.

If you’re running an agile project, and your stakeholders are old-school barrel-riders, how do you make it work?

Expectations, Documentation, and Communication

The success of any project is dependent on setting and managing stakeholder expectations.  In Managing Stakeholder Goals, we talked about assuring that those goals are addressed by our requirements.  And in a later article, we proposed a way to balance the goals of different stakeholder groups when those goals are in opposition.  Those are good tools for making sure we are initially aligned with what we are hearing from stakeholders.

We need to also apply active listening techniques to assure that what we thought we heard is what the stakeholders thought they said.  One way to do that is to write use cases (or user stories) so that we can communicate the intent of the product back to the stakeholders.  This still primarily helps with kicking off a project, in the desired direction, with the correct goals.

There are many ways to document this initial intent of the project and stakeholder goals.  It is analogous to a stakeholder selecting a sturdy barrel and picking a good spot on the river bank to push off.  We’re well positioned to eventually succeed, assuming nothing changes.  After a harrowing fall, we find out how well we did.

A well-run waterfall project will provide status updates to the stakeholders along the way.  Imagine your stakeholder wearing one of those in-helmet headsets that NFL quarter backs use.  We publish effective status reports to let the stakeholder know what’s going on.  Like the falling barrel, however, a waterfall project has inertia.  The project, barring significant outside influence, will keep going in the direction it started.  Projects have change control boards to manage that change, but emotionally, I find that a formal change-approval process tends to inhibit change, rather than encourage it.  That barrel will keep falling.

Some project teams will try and do very heavyweight documentation to maximize the likelihood that the project will end up where it should.  The problem is, this heavyweight documentation only improves the chances that the project will end up where we used to think it should go.  It does not help us change the trajectory of the project as new insights are gained.  Just as responding to those changes provides a competitive advantage, ignoring those changes exposes a competitive weakness.  Someone will come along and exploit your weakness if you don’t respond to change.

From these dynamics, we can conclude that “big up-front requirements”, while better than “no requirements,” are actually a waste of energy and time, relative to an ongoing adaptation to change.  That adaptation to change, however, should also be documented.  It needs to be documented for two reasons – to manage expectations of stakeholders, and to keep the implementation team focused on creating the most valuable capabilities in your product.  As you get smarter about what is valuable, you need to apply that knowledge and change the path of the project.

This is where communication becomes critical with stakeholders too.  Especially the old-school barrel-riders.  They are used to being in the barrel, maybe with an occasional “looking good – you’re still falling straight down” message along the way.  They are not used to hearing “we’ve decided that gliding over the rocks is more valuable than falling – please extend your wings now” messages.  The shocked “what wings?!” response is what they immediately think.

Agile Expectations

An agile project will avoid the big up-front requirements, and gather just enough requirements for right now.  What your stakeholder might hear is “agile is magic – we don’t need detailed requirements.”  The real message is “agile is better – we don’t need details about the requirements yet.  But we will need them later.”

A given team needs the same amount of specificity in requirements to achieve the same result, regardless of project approach.  One team I worked with would not set the tab-order in a form to go from top to bottom if you didn’t specify that.  It simply didn’t occur to them.  Another team was very effective with “gather the following data in a form…” – and they would layout the form, manage tab order, add reasonable field validation, assure proper markup and support for screen readers (for visually impaired users), and implement a candidate error-message/feedback design for users.  The first team would never succeed without details, the second team would view those details as wasted effort by me to write them, and by them to read them.

I think most of the initial creators, proponents, and early adopters of agile processes are members of the second camp.  They designed agile to not require detailed documents, but to allow it when needed – because they acknowledged that some people need the details.  They were reacting to heavyweight processes that were designed to work for “any team” at the cost of slowing down the best teams.  Kent Beck told me once that when people tell him about the importance of testing, his response is “so, lack of testing burned you before?”  When people stressed the importance of gathering requirements, his response was “you’ve been burned by a disconnect with stakeholders.”

Enough is the operative word here.  You have to document enough.  You have to communicate enough.  You have to set expectations with your stakeholders that things will change.  And as those things change, you have to stay joined at the hip with your stakeholders to validate those changes.

While your team is responding to changes (based on feedback from stakeholders and the market and competition and implementation discoveries) with new plans, you have to feed that information back to the stakeholders.  It is a two-way communication.  And it needs to be a continual communication.

I joined a six month project once in the last month of the project.  Here’s a sanitized sequence of events describing what happened.

1. Initial vision for the project was defined and requirements defined and tied to goals and value.
2. The estimates came back and said “no way it will happen before the business-imposed deadline.”
3. The team said “let’s be agile” and chose a component of the vision to do first.  That component could be completed by the deadline, and stakeholder expectations were set – (a) do this visible thing first, “meet” the deadline, and then (b) regroup, re-prioritize, and then do the next thing next.
4. The team started developing the solution, and worked for 5 months.  After 5 months, someone concluded “we won’t finish by the deadline.”  A couple weeks later, the estimate was that the team still had between 1/3 and 1/2 of the work remaining to complete the first component of the vision.
5. In presumably unrelated events, all but 2 of the internal stakeholders left the company.  Literally.
6. When the CIO and president of the company engaged the project team, they weren’t thinking “we have an over-run on the first component of our vision” – they were thinking “not only is it not done, but what you’re trying to do is not the right thing.”
7. Project was stopped one week after the original deadline for the first component (which was not completed).

It may be that this was unavoidable, but one thing was clear – the “build the first thing first” expectation was not communicated effectively.  It didn’t help that the team did not track velocity, so it wasn’t until the end of the project when the “you’re going to hit the rocks” message was first heard by the stakeholder in the barrel.  Way too late to affect change.  For this and other reasons, I contend that the project was not agile.  It was a Chevrolet with a Ferrari sticker on it.

We can ignore the labeling of the process and focus on the lack of ongoing expectation management as the ultimate doom of the project.

Evolving Expectations

Patrick Masi had a couple great comments on our Simple Agile Model article.  Patrick pointed out a problem with simple documentation artifacts like this.  The early “here’s all we need right now” artifacts were insufficient to capture the full extent of what the stakeholders needed.  I’m not sure exactly where things broke down, but Patrick implied that the ongoing clarification with stakeholders was not happening.

This is a completely different manifestation, I suspect, of the exact same problem described above.  Thinking about Patrick’s comments is what got me heading down the whole “barrel rider” path in the first place.

I don’t believe I’ve worked with any stakeholders who would say “yes, ignore what we learned this year – it is more important to build last year’s product.”  I’ve definitely worked with stakeholders who did not have time to commit to the support of an agile project.  The ironic thing about agile projects is that they may do more requirements work through the course of the project than non-agile projects.  An agile project will respond to change.  That means some work is re-done.  It also means that some valueless work is avoided.  You can’t categorically say which influence is larger.

One possible source of the pain Patrick’s team felt is mis-set expectations of what is being delivered when.  Imagine developing a checkout-process for an eCommerce website.  The complete checkout process is too large for a single sprint, so you break it down into valuable atomic deliverables for each sprint:

1. Registered customers can buy any products, using previously saved billing / shipping info.
2. Individual product and “per order” discounting works and customers can use gift cards to pay for all or part of the order.
3. Anonymous customers can place orders (without accounts) and registered customers can modify billing and shipping information.
4. Orders can be placed as gifts (with gift receipts and wrapping services), and online call-center reps can interact with customers real-time to help with the process.

This is a nuanced message – basic checkout in sprint 1, with increasing capabilities in each sprint, until “complete checkout” is done in sprint 4.  That is a reasonable plan, but requires a more detailed conversation with stakeholders so that they know what is coming and when.  You don’t want someone freaking out after the 3rd sprint when they can’t place gift orders.

Another possibility is that the elicitation process before the third sprint (re-visiting checkout again with the same stakeholder) did not tease out that anonymous users must provide an email address (for order confirmation email, and to secretly create a “shadow account” for that customer).  All of those details need to be gathered, and it can be harder to spread out the conversation over multiple sprints than it is to have it all up front.  This is just incomplete discovery, but with delayed (and recurring) impacts.

In User Stories Applied, Mike Cohn stresses that the brevity of user stories is intentionally designed to facilitate (and I would add “dependent upon”) conversation.  I find it to be both a strength and a weakness of user stories.  It is strong because you can cover a lot of ground quickly (breadth) and capture a number of stories, much like the list above.  It is weak because the requirements documentation does not stand on its own – it requires conversation to fill in the details.  I’ve had some success using the “Verify that…” user acceptance tests as the method of documenting those details (depth), in conjunction with the brief, easily consumable stories.

You can write the stories quickly to decompose and schedule across sprints (revisiting the schedule as things change), and then write the verify statements as UAT for each sprint as it occurs.

Another benefit of the UAT is that it is explicit and cuts through the walls of the barrel for a stakeholder who “doesn’t get agile” as Patrick puts it.  “Here’s our lightweight multi-sprint plan – now lets define the specific acceptance criteria you need” is a pretty effective conversation.

Conclusion

You have to stay closely connected to your stakeholders – not just for messaging, managing, and changing the big-picture direction of the project, but also to drill down into the details at the last practical moment.

A business process is not just a sequence of steps.  A business process is a series of decisions and actions.  Some decisions are obvious and can be actively managed.  Some decisions are hidden, and until you discover them, you can’t manage or improve them.  Here is a real-world example of the discovery of a hidden enterprise decision.

Enterprise Decision Management

Over the past couple of years, I’ve collaborated with and become friends with James Taylor, an enterprise decision management guru.  He and Neil Raden wrote the book, Smart (Enough )Systems , you should get it if you don’t already have it.    It is sitting on my desk right now, and every time I pick it up I have to mark another page with a post-it note so I can find that good idea again later.  If you aren’t convinced, listen to this interview with James about their book.

James and I developed a presentation, Getting It Right: Rules and Requirements in Software last fall for the International Business Rules forum.  Below is a slideshare of a shortened version of the presentation, delivered to the Austin IIBA this spring.

A large portion of that talk was dedicated to discovering hidden business rules within use cases.  The reason we dedicated so much time to rules discovery is that the first step to managing decisions across your enterprise is to discover and isolate those decisions!  In this article, we will look at an example of a decision hidden within a simple business process.

A Simple Business Process

The following is a simple real-world business process.  The details of the steps in the process have been modified to clarify this example.

The process flow example above depicts an automated process that involves searching internal systems for an existing customer (record).  There are three possible outcomes from the search, shown above from left to right: no results are returned from the search, a single result is returned, or multiple results are returned.  When no results are returned, a new customer (record) is created, and the automated process continues.  When a single result is returned, that customer is used and the process continues.  When multiple results are returned, a new customer (record) is created and used, but the automated process is interrupted and a manual intervention is required before the process can continue.

This third path confused me when it was initially presented to me this way by the subject matter expert who explained the process to me. The business creates a new customer (record) even when multiple results are found because they don’t have time to determine which result is the right one, within the automated process.  They would rather create a duplicate customer (record), continue with the automated process, and clean up the mess later.  That’s much better than losing a sale (a very real risk because of delays due to manual oversight.

As part of this elicitation session, I applied a variation on active listening by talking to the diagram above (on a whiteboard) and enhancing it.

Impacts and Decisions

One technique that is effective in reaching agreement, generally, is to inspire the other person to “have your idea” so that it becomes their idea.  Once I understood the process above, I realized that there was an implicit decision in the process.  Instead of making the statement – “you have a hidden decision in your process” and then hoping the business stakeholder (also in the room) would care, I chose to start with the impact.  Presenting the impact of a hidden decision first might expose that decision and trigger acknowledgment of the hidden decision by the stakeholders.  The following diagram shows how I first modified the flow on the whiteboard.

The subject matter experts had told me that when there is a manual intervention in the otherwise automated process, the process is sometimes abandoned.  Imagine customers walking away from an online sale because (for some reason) the sale cannot be completed without an unexpected delay.  I represented this with the “Abandon Process?” decision in the flow.  This decision was never drawn before, because it is the customer’s decision, and it can not be controlled by the business.

I also pointed out that the business makes money only through the last step in the process, “Continue Automated Process.”  My goal was to accentuate that this abandonment decision has a very real value.  The stakeholder and subject matter experts agreed – this was something they had told me previously.  But they had never drawn it directly within their process.

As it turns out, this did not trigger any additional insights.  It did however, set the stage for describing the relevance of the hidden decision.

The Hidden Decision

After setting the stage, I updated the process flow diagram to expose the hidden decision.

The hidden decision is the decision of picking one of the many search results (top right corner of the diagram).  Your first response may be that the business is not picking any of the results.  My response is that choosing none of the provided results is a choice, just as picking any one of them would be.

This view of the process highlights that if the business could automatically choose a “best” result when searching returns multiple results, the business would avoid the risk of abandoned processes due to manual oversight.

With the current process, the business stakeholder acknowledged that the hidden business rule is ” pick none of the results 100% of the time”.  With current project schedules, there is nothing that can be done about that in time for the immediate software release (of the software that embodies this process).

Before our meeting was over, the business stakeholder added determination of future-state business rules to define the “how do we pick one?” decision to the deliverables for the next release.

A Smart (Enough) Decision

James and Neil (I would guess) will tell you that ideally, the decision (should we pick one, and which one should we pick) should be informed by the process.  A feedback loop can be created where we identify the customers (the people who might abandon the process), and determine statistically which ones are most likely to abandon the process.  For those people, it is especially important that we be able to “pick one” from a set of search results, thus completely avoiding the opportunity to abandon the process.  For those people who are unlikely to abandon the process, the “pick one” decision is less important.

If it were easy to “pick one”, we would consider changing the way search is handled to never return multiple results.  In this real world example, that is not an option (I’m intentionally not sharing the reasons, to avoid disclosing too much).  The only option in this case is for the business to respond intelligently (enough) when presented with multiple search results.

Conclusion

This process flow example has two primary outcomes – generate profits, or don’t generate profits.  The first modification of the process flow makes that possibility explicit.  That allows for an analysis to determine if there are any hidden decisions in the flow (there are) that impact the outcomes of the flow.  There may be other hidden decisions, but they do not impact the profitability of this process, so they were not explored.

Your strategy should be driven by the needs of the market.  Becoming market-driven is critical to intentional product success.  But it is not enough to understand your market.  You have to sustain your understanding, and take advantage of it, competitively.

Markets Evolve Over Time

We all acknowledge that markets are not completely static.  If they were, there would be no impetus for innovation.  Customers change, their environment changes, and the competitive landscape changes.  All of these changes cause a market to change.  Even if a given market were static, you don’t have perfect information about it.  Your understanding of that market increases over time.

The market is an abstract concept, and you have to make decisions about something tangible.  What is tangible is your understanding of the market.  And you make decisions based on your understanding of the market. You can visualize the market in a way that may cause you to rethink (or solidify) your approach to solving market problems.

In the chart above, we are showing that there is some amount of information (think of information as an understanding that we haven’t developed yet) about a market.  It represents the potential of what could be understood about the market.  Over time, the amount that can be understood increases.  Also note that there is already a non-zero amount of “understanding” at the start of the chart.  The market did not spontaneously spring forth from an oyster the moment you decided to look at it.

You Affect Your Markets

There is also an important dynamic to consider – you affect your markets by introducing solutions.

Whenever someone introduces an innovative solution to a market problem, the market changes.  Solving that problem exposes another problem.  Or it may introduce another problem.

• When cars replaced horses, they introduced atmospheric polution problems.  Before that, we only had to worry about horse waste.
• When airplanes solved the problem of traveling long distances in a short amount of time, more people began traveling further.  And those people discovered a need (desire) to stay connected (phone, internet, etc) while en-route.
• When it became convenient to carry music around with you on a portable player, the problem of carrying all of your music around with you was discovered / created.

You can argue that these problems were introduced because of innovative solutions, or that the problems were latent, and were only discovered because of the innovations.  It doesn’t matter.  What matters is that these problems were previously unaddressable, and now solutions to these problems have value.

Your Knowledge of Your Markets

Using the diagram above as a baseline of what can be known, and overlaying your knowledge looks like the following:

At the moment when you decide to understand a market, you don’t know anything about it.  Your knowledge rapidly approaches what “can be known”, and assuming you have perfect research, elicitation, and synthesis skills, you eventually understand all that can be understood about the needs of the market.

So much advice has been written about being market focused, that it is easy to think that this is all you need.  As soon as you understand “everything” you define requirements and start creating products.  Being market focused is extremely important.  But you have to sustain that focus.

Competition in Your Market

In the diagram above, you see the dynamics of your market.  You develop an understanding of your market, a competitor delivers an innovative solution to a problem, and you have to play catch-up.  Note – this is only talking about playing catch-up in your understanding of the market.  You also need to continue to develop new solutions for the market in order to capitalize on your understanding.

The next diagram shows what this will look like when there is active competition in the market.

The diagram above shows three disruptive events.  You innovate, someone else innovates, and you innovate again.  Each time someone else innovates, they have an edge on understanding the market.  They just solved a problem, uncovering new problems that can be solved, and you have to gain that knowledge too – it wasn’t available (or didn’t exist) previously.

Competitive Advantage

Each time you innovate, you establish a temporary competitive advantage.

When you introduce a novel solution to a problem, the market uncovers new problems.  Presumably, you have already thought about the next steps.  You have already engaged the market (through prototyping and other elicitation activities) to get feedback on your solution.  Hopefully, as part of that exercise, you’ve also explored “what’s next” and incorporated that into your plans.  This is the advantage you have created.  If you don’t explore “what’s next,” you waste that opportunity.

The opportunity won’t last forever.  Your competition will see your solution, talk to your customers, and otherwise explore “what’s next.”  It will take time, but they will catch up.  Over the long term, you benefit from exploiting a series of these opportunities.  Look at the iPod and the Zune.  Apple has delivered a series of disruptive changes, continually building on what they have learned.  Microsoft is playing catch-up with the Zune.  Each version of the Zune shares a lot of design cues and features with earlier iPods.  To Microsoft’s credit, they are trying to innovate too – like with the “squirt” technology that lets you share a song temporarily with another Zune user.  Either this is not a valuable problem, or the solution is not effective – because it has not taken off (in buzz, market share, or general clamoring for an iPod-based equivalent).

Fast Follower Competition

Some competitors intentionally act as second movers.  Instead of focusing their efforts on discovering problems or developing innovative solutions, they focus on playing catch-up very very well.

A fast-follower reduces (but does not eliminate) your temporary advantage.  At the same time, the fast follower creates their own advantage relative to every other competitor in the market.  This can be a very effective strategy, especially when there are multiple innovators in a single market.  The fast follower can follow the best ideas of each innovator, possibly even ending up with a better overall product than any of the innovators (who are slow followers of other companies).

Microsoft is clearly a follower of Mozilla when it comes to browsers.  The tabbed navigation concept introduced in Firefox was a game changer, at least for the tech-savvy who need to juggle multiple web pages at the same time.  Personally, I was thrilled to move from multiple Internet Explorer windows to a single Firefox window with multiple tabs.  IE7 has that capability now too.  I don’t know the browser market well enough to know if I would characterize Microsoft as a fast follower, but my guess is no.

After the post-World War 2 reconstruction in Japan, the Japanese automakers definitely acted as fast followers.  They did it with assistance from the US, and even moved past the US automakers by choosing to listen to Deming (a guru on efficiency and quality) instead of ignoring him like the US big 3 (automakers) did.  And it did indeed pay off for them – Toyota is poised to unseat GM as the number one automaker in the US for 2008.  There are certainly other factors at play, but the Japanese companies would never have had a chance if they had not been competitive in the first place.

Business Agility

Business agility is one of the hotter buzz-phrases these days.  The business-rules-automation market is thriving on the desire of businesses to become more agile.  Why does agility matter?  Because it can make you dramatically more competitive.

Business Agility is not the same as agile development!

Business Agility is a measure of the ability of a business to adapt to the changing needs of the market.  To adapt quickly, your company has to accomplish two things:

• Quickly identify and understand the changes in your market.
• Quickly deliver new and improved solutions that address the changing needs of your markets.

[How to quickly execute is covered in other articles in the business rules (including their impact on agility) and agile development categories on Tyner Blain.]

In the diagram above, you (the red curve on the top) are innovating repeatedly.  You are also adapting to the changes in your market from other innovations (and other sources of change, not shown).  You are practicing agile product management.  Your competition (the green curve on the bottom) is not.  As this trend continues, you see that your exploitable advantage becomes a sustained advantage.  You will have an ever-increasing advantage as you stay tapped into your market.  If you are executing (to deliver product) and communicating (to educate), you will be able to leverage your insights into a position of thought leadership.  [Note: "thought leader" is a title that can not be self-annointed, it has to be earned and perceived within your market / community.]

The end result is that you will be consistently aware of unserved market needs that you can serve before your competitors can.  That translates into increased demand for your products, which you can use to grow share, grow profits, etc.

That’s why business agility matters.  It isn’t cost reduction that is important, its top-line growth.

Agile Product Management

Staying tapped into your market like this is a strategic component of agile product management.  While continuously staying tapped-in (or Tuned-In), you regularly interact with your internal stakeholders to make agile development processes work.  Enthiosys has a great introduction to agile product management (free download with registration), if you’re getting frustrated with the many “empty presentations” about agile product management, then definitely check that one out – it has meat.  Relative to their onion, the topics in this article map to the portfolio and product layers.

If you aren’t already convinced of the value of a tight market focus, consider the following diagram, contrasting the impact of agile product management and traditional, waterfall product management.

• The red curve on the top (same as previous slides) represents an agile product manager staying tapped into her market.
• The grey curve in the middle represents a product manager staying tapped into the market, but not as tightly.
• The green curve on the bottom shows what happens when your organization is trapped in a waterfall delivery model.

The green curve, instead of reflecting understanding, reflects the understanding against which the team executes.  When you lock in or “freeze” the requirements, then begin a sequential development process, you stop taking advantage of market insights.  You essentially decouple your implementation team from the market – “we know enough already.”  So even though your product manager may be learning more (the grey curve), you aren’t taking advantage of that knowledge, so it is adds no value.

As an agile product manager, working with an agile implementation team, you will run circles around your waterfall competition.  Not only will you establish thought leadership, but you will be creating a distinctive competence for your company.  Your ability to understand the market, and quickly respond to changes in the market with valuable solutions will differentiate your company.

You also effectively change the dynamics of your sales over time.  Your accelerated insights allow you to release products (or capabilities) earlier.  Here’s a diagram from an earlier article on the ROI of agile that highlights the impact of this:

If we take the most conservative approach to modeling sales with an agile process, the graph would look like the following:

The sales volume curve is shifted to the left without changing its shape. The exact same growth curve applies to the product (this is the conservative assumption). The decline in sales continues to decline. The difference is that our previous time horizon (which remains fixed) now includes additional sales.

Product Life Cycle and the ROI of Agile Development

Agile Without Product Management

There are people who suggest that product management has no place in an agile environment.  Those people believe that markets can’t be understood until they are served.  They will argue that customers “don’t know what they want” based upon the feedback they get from prototypes.  Customers change their minds.  Yup.  But it isn’t that the customers don’t know what they want, nor is it that markets don’t have shared needs/problems/goals/requirements – they do.  Providing solutions to those problems drives next-level thinking, and the identification of new and different problems.

If you don’t have product management, you can only succeed through luck.  Throw stuff against the wall and see what sticks.  If something sticks, you win.  This is better than a waterfall model that ignores the market (for long periods of time where release plans are “set in stone”).  But it falls well short of driving a very efficient, adaptable implementation team directly towards identifiable market needs.

Great product management starts with an insightful understanding of your market.  Not just understanding a customer, and not even understanding all of your customers, but understanding your target market.  What works for you?

The Needs of The Many…

Mr. Spock was on the right track in Wrath of Khan, when he said “logic clearly dictates that the needs of the many outweigh the needs of the few.”  And Captain Kirk apparently took Pragmatic Marketing’s training, since he responded, “Or the one.”  [That was their original mantra circa 1982, before the more common "Your opinion, while interesting, is irrelevant."]

It isn’t just the crew of the starship Enterprise that believes an understanding of your target market is critical to product success.  I believe it, Pragmatic’s folks teach it, every good product manager I’ve run across embodies this belief.  [Note: Steve Yegge has a very intense article where (I think) he believes it too, but believes that it is futile to try and understand a market that doesn't include you.]

Tools and Techniques

We have a lot of articles here that help you communicate ‘an understanding of the market needs’ with your implementation team – where implementation equals development AND testing.

1. Documenting market needs (existing and new markets)
2. Making strategic decisions to address those needs
3. Engaging with stakeholders to validate needs
4. Prioritizing / planning product releases / roadmaps to align a release schedule with targeted needs
5. Engaging with stakeholders to clarify needs
6. Gathering and documenting requirements details and inter-dependencies
7. Validating feasibility / communication of intent with implementation (development and test) teams
8. Prototyping and eliciting user feedback

To name a few.  We’ve also written about several techniques you can use

• Gathering requirements via interviews
• Applying (and improving) your active listening skills
• Persona development, and differentiation of user goals from corporate goals (and from buyer goals)

The Missing Link

With all the current hub-bub about the bigfoot hoax (“I think I’m going to have a heart attack and die from not surprise!” – Iago, Aladdin), I couldn’t pass up this mug shot.

Collecting the customer-need data, with something more than anecdotal evidence, is tricky.  One of the premises of the agile movement is that you can’t, so don’t waste time trying.  I’ve always approached it by gathering anecdotal data, looking for root causes to create problem statements, and then working to map back to personas – dangerously extrapolating trends from a handful of datapoints.  And it seems to work.  But it doesn’t scale.  There must be a better way.

I had a great conversation with someone who asked the Austin PMM yahoo group what tools they used for tracking “customer feature requests.”  [Thanks again, btw, if you're reading this.]  The requestor was looking for something less than Feature Plan.  Just a mechanism for tracking feature requests.

Here’s the problem.  A feature request is to a market requirement as a gorilla suit in a block of ice is to a frozen captured Bigfoot.  Tracking and managing feature requests isn’t what we actually need to do.  Tracking and managing market requirements is what we need to do.

What Do You Do?

OK, so you manage a product that is sold by a sales team.  Those sales people, and account managers get feature requests all the time.  Or you have a SaaS product, and you built in a feedback mechanism.  A 2006 survey of SaaS vendors found that the ratio of feature requests to bug reports was on average, 5 to 1.  That’s a lot of feature requests.  Your process should look like the following:

1. Review feature requests.
2. Do something, possibly using some tool(s).
3. Determine market needs, prioritize markets (or needs), and update your roadmap…

Share what and how you do it.  Some questions I would ask if you were teaching me how:

• Assuming you map ‘features X, Y, and Z’ to an actual ‘requirement A’, how do you chunk those inputs – by persona, by market segment, something else?
• Do you have a way to automate any of the analysis (e.g. mapping a market need to a segment or persona)?
• If you had a magic wand, what would make that job easier?
• Any lessons-learned / advice for new product managers?
• How do you close the feedback loop with the customers who originally submitted all of those feature requests?

Thanks in advance for any responses!

Is your product successful because you were lucky, or because you were methodical and intentional?

Do you want to build a plan where you are dependent on good fortune, or do you want to make your own “luck?” Both approaches work, but only one makes sense as an intention. Slide 3 of your presentation to a venture capitalist should not say “And then we get lucky!”

Product Success Is Not Easy

Saeed Khan wrote a critique recently, in On Product Management, of an article by Phil Meyers on the Tuned In blog. Phil’s article is an analysis of the pending re-organization at Starbucks, and the one quote that Saeed keyed in on was:

At the end of the day, its simple. Create a product or service that your buyers want to buy and the rest takes care of itself.

Saeed’s point is that it is not that easy. A lot of hard work goes into creating a successful product. And Saeed’s right.

Maybe Phil’s point is that the executive should not worry about the details, and trust in his team to do all the hard work. But he doesn’t really come out and say that, so we can’t really back him up on that front. Let’s give him the benefit of the doubt anyway. There’s another point that Phil makes that is potentially disturbing:

Looking at metrics like average same day sales and products per square foot lead you down some strange paths. Schultz even admitted as much in a letter from the board about a year ago in which he worried about the company ‘losing its core’.

Yes, abandoning your goals to pursue your metrics is bad. But don’t abandon your metrics to pursue your goals – unless all you want to do is get lucky.

You might argue that a company like Animoto got lucky when their product spread virally within Facebook and their user base jumped from 25,000 to 700,000 users. But if you listen to the interview that Amber MacArthur did with co-founder Brad Jefferson, you will realize that it was only when they tweaked their product offering – a response to empirical analysis of product adoption metrics – did their success explode. I would argue that they made their luck by being intentional.

Empirical Processes

When you can perfectly model your business analytically, you can measure the inputs and know (with certainty) the outputs. As a college engineering student, I learned this. Real world processes can never be perfectly modeled analytically. As a professional engineer, I learned this too. Real world processes are empirical. The secret to great engineering is to apply analytics to those empirical processes to create disruptive innovation, and combine it with empirical controls that help you statistically predict the likely outputs. The answer is simply that neither analytics nor empiricism alone can help you achieve greatness.

Business processes are also empirical in nature. Even when you can devise an analytical model for the behavior of an isolated system, you have to acknowledge that no real world system is isolated. You have to expect unexpected inputs into the system. As Saeed points out, you have to apply analyses to make smart decisions when developing your process (or business model, or product). And what Phil appears to discount is that you also need to apply empirical measurements to your process (or business or product) to control the expected results.

Creating Successful Products Intentionally

This article proposes that there are two paths to product success. The first path is simple. Cross your fingers, then get lucky. The second path is harder. Be intentional.

1. Identify your market (and therefore your customers and competition).
2. Identify their problems, and select the ones you will solve.
3. Create a product roadmap (aka a “plan”) to solve those problems.
4. Design and implement solutions to the most valuable problems.
5. Get feedback on your solutions.
6. Incorporate your feedback into your plan (step 3) and repeat.
7. Revisit your market (step 1) and the problems you choose to solve (step 2) and repeat.

Note: Step 7 should occasionally replace step 6, so that you stay focused on your market, and not just an out-of-date snapshot of what used to be important to your customers.

1. Identify Your Market

There are a lot of ways to pick a market to focus on. You can chase demographics – there sure will be a lot of retired people in the US thanks to the baby-boomers. You can go with what you know – years of paying attention to an industry presents ample opportunities to understand the market. You can create an entirely new – blue ocean – market by solving problems people don’t even realize they have until you offer a solution. Choosing a market is the subject of many books, not just an item in a list.

Once you choose a market, you need to segment the market into groups of people who share the same problems and who value solutions to those problems similarly. You can apply market research to improve your market segmentation.

2. Select The Problems You Will Solve

You use elicitation skills to identify the problems that your customers face. And when you have to address multiple market segments, you can prioritize the problems across those market segments.

3. Create a Product Roadmap

Once you’ve prioritized the problems you are going to solve, create a product roadmap. Your product roadmap should show the problems you are solving, and the order in which you will solve them. When you define sequencing, you also must define your approach to scheduling product releases.

4. Design and Implement Solutions

There are two keys to successful execution of the plan you built with your product roadmap. First – use rolling-wave planning to define near-term details and long term vagaries. Second – make sure you have continuous integration as a key component to managing quality throughout the process, instead of checking quality at the end (or even worse – ignoring quality).

5. Get Feedback on Your Solutions

This is half of why agile (when done right) works [Can you believe the discussion over the last year on this article is up to 27 comments?!]. Feedback is not just something you get when sharing a prototype with stakeholders. Feedback is also something you must get as part an incremental release methodology.

You can even measure the ROI of your designs, and incorporate feedback at the design level.

6. Incorporate Feedback Into Your Plan

There’s no point in gathering feedback if your organization and your process are organized to resist changes to the plan. Contrary to what the Standish Group’s CHAOS study has always implied [and we've made this implicit mistake too], release schedules are not the primary measure of project success. In a fantastic article at Dr. Dobb’s Journal, Scott Ambler points out that in his survey results, almost two thirds of professionals find that doing the right thing is more important than meeting a project schedule.

Schedule: 61.3 percent of respondents said that it is more important to deliver a system when it is ready to be shipped than to deliver it on time.

Do the right thing. If the right thing involves changing the schedule, that doesn’t make it wrong. What makes this work is the fact that you are getting feedback early and often. It is a risk mitigation strategy, designed to reduce the possibility that you will create an unsuccessful product. It is not a strategy designed to keep your project on schedule no matter how mis-aligned you are to your market.

7. Revisit What You Are Doing And Why

If step 6 is small-scale course correction, this is large-scale course correction. You may discover that solving a big problem for your customers exposes a new “biggest” problem that wasn’t there before. By revisiting step 2, you can choose to tackle or ignore those newly discovered problems.

You may also discover that by leveraging your investments to date, you dramatically improve the ROI of solving problems in another valuable market segment. This is because even if solutions to those problems have the same value, solutions to those problems now have much lower costs (for you). By revisiting step 1, you give yourself the opportunity to best manage your strategy, your resources, and your plans.

Conclusion

Product Success may have an element of luck, but you should never plan to hit the lottery. Be intentional in what you will do, and a good plan, executed well and adapting to change, will get you there.

We’re dedicating our “blogging time” this week to doing some infrastructure upgrades – we have to address some security issues on the site. Until we get through these changes, we’ll be recycling some of our existing content. For our recent readers, it will be “new to you” and for our long time readers, we appreciate your patience. Today we look at one of our better received articles on active listening.

Ten Supercharged Active Listening Skills To Make You More Successful [15 Mar 2007]

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone’s needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone’s input is valuable. If you haven’t tried active listening, you may think it is a passive, receptive activity. Here are ten active listening skills that will help you, your customers and your team.

Our active listening article goes into details on the following 10 Active Listening Tips:

1. Acknowledging
2. Restating
3. Reflecting
4. Interpreting
5. Summarizing
6. Probing
7. Giving Feedback
8. Supporting
9. Checking Perceptions
10. Being Quiet
11. [Bonus] Extending

I hope you enjoy them and put them to good use – they really do make a difference

In this article, we build on our ability to represent straight forward business relationships in UML class diagrams. These relationships describe how two objects are related to each other. Representing relationships in class diagrams helps us to better understand the domain and helps us to uncover hidden requirements. Occasionally, we have to deal with more complex relationships that involve more than two objects to properly describe. This does not happen as frequently, but when it does, our modeling efforts are more likely to uncover overlooked requirements. In this article we learn how to describe relationships that involve more than two objects.

Catching Up On UML Class Diagrams

If you navigated to this page first, it is the fifth in a series introducing UML Class Diagrams for requirements elicitation.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
4. Uncovering Requirements With UML Class Diagrams Part 4: Defines generalization (inheritance) and how to use it.
5. Uncovering Requirements With UML Class Diagrams Part 5: This article

Jump back to the other articles and get up to speed if you need. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work.

Understanding Details About The Relationship

One reason you may want to deal with more than two objects is obvious only after you change your way of thinking. So far, you’ve been thinking about objects (classes) and relationships (associations). Sometimes, when you need to understand the details of the relationship, you should think about the relationship as an object. It is both a relationship AND an object. And you draw this with an association class. We’ll walk through an example that illustrates the idea clearly, then we’ll look at the steps needed to create a relationship that is also an object.

Consider that you are gathering requirements to support software for tracking court cases – perhaps a mashup site that combines the latest public record lawsuits with entries from LinkedIn (my profile) and Crunchbase.

As part of your requirements gathering, you need to understand how these court cases work – so you start with a class diagram.

First – identify the main players in the lawsuits:

Both a plaintiff and a defendant are litigants, as they are involved in lawsuits.

That represents a simple relationship. A plaintiff sues one or more defendants. When you show this diagram to one of your stakeholders, she likes that you captured that one plaintiff can sue more than one defendants. She also likes that you can determine “who is the plaintiff suing” as well as “who is suing a given defendant.”

You point out one small problem – it is not clear if the plaintiff can only sue multiple defendants one-at-a-time, or if the plaintiff can sue multiple defendants in the same lawsuit. You get the answer (multiple defendants can be sued at the same time), and as you start to scratch your head about how to represent it, your stakeholder interrupts (they do that):

“We need to be able to show lawsuits with a “most recent” view, and a “largest” (in dollar amount) view on the main page of the site!” You realize that your diagram doesn’t work, and you make a note to yourself about the multiple-defendants issue.
You need a way to capture information about the suit. Suddenly, instead of a verb (sues), you need a noun (suit). You need to reason about the relationship. So you update your class diagram.

Your updated diagram now shows that a single plaintiff, in the context of a single suit, can sue multiple defendants. You also capture that you need to know the trial date and the dollar amount of the suit. You erase that note to yourself, because your diagram now clearly indicates that one lawsuit involves multiple defendants. You make another note to yourself that it is not clear if a plaintiff can be involved in more than one suit with the same defendants (he can). You’ll deal with that later.

What you’ve drawn is something (the suit) that is both a relationship and an object. In UML class diagrams, this is called an association class.

Creating An Association Class in a Visio UML Class Diagram

To create an association class, you use the Association Class shape in the Visio UML Static Structure stencil.

Drag the association class onto the page.

By now, you realize that you need to suppress the end names in the display. Right click on the shape and select “Shape Display Options…”:

And disable the display of the end names:

Now your shape will look like this:

You can manipulate the shape and its placement in two different ways. You can select and drag either line end (to connect to another shape in the diagram)

Or you can drag the “class” portion (the box) of the shape to wherever you want to place it. [Note: When you drag the class, it looks like you are disconnecting the line from the shapes and messing everything up. It is not happening. When you release the mouse button, the class will be where you put it, and the line will still be where it was before.] There is a dashed-line that connects the class (the box) to the association (the line). Visio automatically updates that for you – you never have to worry about it. In fact, if you don’t like it where it is, you can’t do anything about it either.

You could use the rotate-handle (the green circle on top) to rotate the box, but please don’t. Class diagrams, by convention, are drawn with everything aligned with the page. To get the line on top, just drag the line ends above the shape (or drag the shape below the line ends).

You use the same rules for showing directions with an association class that you do with a regular association. If the business needs to think in one direction – “Who has the plaintiff sued?” then show that arrow. If the business wants to think in the other direction – “Who has sued a particular defendant?” then show the opposite arrow too.

Even More Complex Relationships

The cool shape above lets you draw a three-way relationship. It is most handy when you need to understand something about the relationship itself – treating the relationship as a noun instead of a verb. You can create relationships in UML class diagrams that involve more than three objects. These are called N-Ary Associations. The “N-Ary” part is geek-speak for “binary, trinary, quaternary, etc” – any number is valid.

Earlier, we glossed over one question – “Can a single plaintiff, related to multiple defendants in the context of a single suit, also be related to those defendants by another suit?” You can use an n-ary association to depict this.

In the Visio UML Static Structure stencil, select the N-Ary Link shape.

Drag it onto the page

It looks a bit like a decision diamond from a flow chart, but with handles. Drag it to where you want it to be in your diagram and then start connecting the line ends to the related classes.

After you’ve connected the ends (or before, but after is easier), double click on the shape to bring up the properties dialog.

You’ll see three “Link Ends” – just rename them to show the multiplicity of the connections. You will end up with a final diagram that shows:

One plaintiff can sue one or more defendants in one or more suits. You could (and I will) argue that this is even more ambiguous than the previous diagram.

• Who does the suing? Is it the plaintiff, the defendant, or the suit itself?
• Are they even suing? Perhaps the relationship is just “they are all in the same room at the same time.”
• When a plaintiff sues multiple defendants, is it one defendant per suit, with multiple suits? Can it be? Must it be?

Personally, I never use an n-ary association when modeling complex relationships. I much prefer the association class.

A Simpler But Busier Alternative UML Class Diagram

You never have to use an association class. You can always represent the situation with three classes and two associations as the following diagram shows:

Instead of an association class, you create a single class (suit) that represents the noun, and you break up the single association (suing) into two association (attacks with, defends against). In some ways, this is more precise than using an association class. You can tell from the diagram above that

• A single plaintiff attacks with one or more lawsuits.
• One or more defendants defend against a single lawsuit. Therefore, there could be two suits between the same plaintiff and the same defendants at the same time.

What you lose is a notion that the suit establishes the context of the relationship between the plaintiff and the defendant(s). Ultimately it is a judgment call about which form to use (the association class or the normal class with two associations). If understanding the specific multiplicity data is important, you should use the two-association diagram. If it is not, I personally feel that the association class provides clarifying context.

Next Up

In the first five parts of this series we’ve covered

• Using classes to represent business objects and entities.
• Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
• Using composition and aggregation to show how objects are treated when grouped together.
• Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.
• Using association classes and n-ary associations to express more complex relationships.

If you understand all of these concepts, you are ready to create UML class diagrams of the business domain and concepts. You are ready to use these tools to uncover otherwise hidden requirements. If you want to study some of the more arcane details around UML class diagrams, you should be ready to read Scott Ambler’s articles.

• UML 2 Class Diagrams – an explanation, in detail, of how and what and why to draw things a particular way
• UML 2 Class Diagram Guidelines – advice on how to make your diagrams consumable and appealing

Just keep in mind that Scott jumps right into complex topics (which you are now ready for), and also includes tips and advice that are only relevant when creating class diagrams of implementation designs. Just filter that stuff out. Or come up with a way to leverage those details to the modeling of business ideas, and share them here.

Thanks for following along this far, and if you have any questions or would like to see us cover anything else about using UML class diagrams for uncovering requirements, add a comment below.

The hardest part of gathering requirements effectively is uncovering the requirements that people don’t immediately tell you. You have to ask the right questions. And one of the best ways to find the right questions to build a class diagram of the business domain. This article continues our introduction to class diagrams.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are three that came before it.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: Discusses combining objects into collections and concepts.
4. Uncovering Requirements With UML Class Diagrams Part 4: This article.

So jump back to the other articles and get up to speed. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work.

Generalization: A Dog Is A Mammal

We’ve looked at objects and relationships between them. We’ve looked at the special association relationships that give us aggregation and composition. Generalization is another form of relationship, but not one that tells us how different objects interact – one that helps us better describe objects. We could talk about a dog, and create an object that represents a dog. But what if we also wanted to talk about a horse? They have some things in common, because they are both mammals. Generalization allows us to talk about mammals too. That’s fine, but let’s use a business example instead of a classroom example.

The key to this generalization relationship is to think about the phrase “is a.” A dog is a mammal. Don’t confuse this with combining objects into an aggregation. A pack has a bunch of dogs in it. A zoo has a bunch of mammals (and other animals) in it. But a dog is not a specialized pack. It is a specialized mammal.

Remember “…is a…”

This relationship carries special meaning – all things (characteristics, behaviors, etc) that are true about the general object are true about the specialized object. But all things about the specialized object are not necessarily true about the general object.

• All mammals have hair, therefore all dogs have hair.
• All mammals have live babies (they do not eggs), therefore all dogs have live babies (puppies).
• All dogs are pack animals, but all mammals are not (elephants are, but shrews are not).

Technical folks usually call this inheritance – the specialized object inherits all of the properties and behavior of the generalized object. Inherit is almost as good of a word to use as generalizes. Where inheritance really helps as a term is it allows us to think in terms of parents and children objects. The mammal is a parent and the dog is a child of mammal. The terms parent and child make it much less cumbersome to talk about generalization relationships.

Understanding Insurance Policies With Generalization

Consider that you’re working on a project for a life insurance company. In your first conversation with a subject matter expert, you hear five different terms for describing insurance policies. At a convenient pause, you stop the interview, walk over to a white board, and draw class diagram objects for each of the five items.

You ask your expert how all these objects are related to each other. She explains that all life insurance policies are either term policies (they last for a fixed term of time) or permanent policies (they last for as long as the premiums are paid).

You recognize this as a generalization relationship.

• Every Term Policy is a Life Insurance Policy
• Every Permanent Policy is a Life Insurance Policy

Your SME also informs you that permanent policies, as a form of investment, are always one of two special types – whole life policies and variable insurance policies. Whole life policies have a fixed return for a fixed premium. Variable policies invest your premium in market securities, and the amount of money available at the time of payment depends upon the performance of the policy. More generalization relationships.

• Every Whole Life Policy is a Permanent Policy
• Every Variable Insurance Policy is a Permanent Policy*

[*As far as I know. If there is such a thing as a variable term life insurance policy, my apologies - just assume that your company does not sell one.]

You draw the generalization relationships on the white board, and you move forward in eliciting requirements. This drawing is known as a hierarchy.

Drawing Generalization Relationships in Visio

You use the generalization shape in visio to create generalization (inheritance) relationships between classes in your class diagram.

As you drag it onto the page, it looks like the following:

The shape is an arrow with a closed (but not filled) arrowhead on one end. You connect that arrowhead to the parent class – the more-general of the two. The tail is connected to the child class – the more-specific of the two.

Once you draw all the relationships, your Visio class diagram will look like the following:

Now you’re prepared to understand the other information your subject matter experts are sharing, in the context by which the business is describing their requirements.

This hierarchy makes sense, but it seems to be completely different from all the other class diagram stuff we’ve done. How can you combine these different views? It is the combination of them that really brings out the value.

Relationships, Classes, and Inheritance

The first thing to realize is that association relationships, composition relationships, and inheritance relationships can all happily co-exist within the same UML class diagram. In fact, much of the insight you gain into uncovering requirements only comes when you combine these different analyses within a diagram.

The structure we looked at above provides a good description of how a company manages the policies that they write. What you are likely to want to document are requirements around selling those policies. Each time a policy is sold, an agreement is created. That agreement is a copy of the policy sold (at the time of selling it), with the insured person’s name filled in. You can imagine the policy to be a form with blanks that need to be filled in. Each time a policy is sold, someone makes a copy of the “official” policy, fills in the blanks – name of insured, policy dates, etc – and then it becomes an agreement.

Introducing the term agreement allows the business to treat the two ideas separately. A policy defines the agreements that can be sold at any given time. An agreement is one policy, as sold to an insured person (customer).

[click for larger diagram

As you can see from the diagram, we have the same hierarchy for describing insurance policies. We've added some other objects and relationships.

Objects

• Agreement. A policy written by an agent for an insured person. The agreement is written in a specific state.
• Agent. An agent is someone who sells insurance policies (agreements). The agent lives in a specific state.
• Insured Person. Someone who purchases an insurance policy (agreement). The person lives in a specific state.
• Insurance License. An official document that allows someone to sell policies in a specific state for a period of time.
• NASD License. A special license from the National Association of Securities Dealers that allows someone to sell variable insurance policies.

Relationships

• A life insurance policy is used as a template for an agreement.
• An agreement is written by an agent.
• An agreement is held by an insured person
• An agent holds one or more insurance licenses.

From the diagram, we can understand that an agent sells an agreement to an insured person. That agreement is based on a life insurance policy. The agent holds at least one license to sell insurance.

Notice the relationship between the agreement class and the life insurance policy class. The life insurance policy is at the top of an inheritance hierarchy. Each other type of insurance policy (term, whole life, etc) is just a specialization of life insurance policy. The diagram depicts that the agreement can be one of any of the different types of insurance policy. And therefore, an agent can sell any of the types, and an insured person can hold an agreement of any of the types of insurance policy.

When reviewing these relationships, you discover that this is an overly simplified representation. You capture the additional information and update your diagram.

More Complex Class Diagram

As part of reviewing the diagram, you discover that variable insurance policies are treated very differently than other insurance policies.

• An agent must have a different type of license (an NASD) license to sell variable insurance. Because of this, the business treats these agents as being special - they are called "Broker / Agents" and are subject to many different internal policies and procedures. Some of those policies represent enforcement of legal regulations, and others are internal policies.
• A broker / agent can sell both variable and fixed (non-variable) insurance policies.
• A variable policy is a combination of a fixed policy and an investment. As such, the business thinks about those customers as investors, and not just insured people. This distinction is really only relevant to sales people and marketing - who will use different approaches to sell to people who want investments.

You update your class diagram to look like the following:

[click for larger diagram]

This diagram is much more complicated.

• We enhanced the hierarchy for insurance licenses to reflect that broker/agents need a different type of license (NASD license) to sell insurance.
• An insured person holds a fixed agreement, where an investor holds a variable agreement.
• An agent can only write a fixed agreement, where a broker/agent can write any type of agreement (fixed or variable).

The diagram is almost too complex to absorb within a UML tutorial. If you were writing these requirements, and did not create a similar diagram, you would be in trouble. In the best case, you would end up with an implementation that met all the requirements, but did not use a good implementation design (due to lack of context). It is more likely that either you would miss some requirements, or your implementation or test team would miss some.

The diagrams that have had the most impact, in our experience, are diagrams that have a similar level of complexity.

Next Up

In the first four parts of this series we’ve covered

• Using classes to represent business objects and entities.
• Using simple associations (relationships) to demonstrate how objects are dependent or how they relate to one another.
• Using composition and aggregation to show how objects are treated when grouped together.
• Using generalization and inheritance hierarchies to show how similar, related objects can behave differently.

All of the tools you’ve learned so far deal with binary associations – an agent sells a policy, a book club reviews books. In the next article, we will look at relationships that involve more than two classes.

Uncovering Requirements With UML Class Diagrams Part 5: Complex Relationships

UML Class Diagrams are very effective at uncovering requirements. They give us insight into how the business thinks about objects and their relationships. And from that understanding, we think to ask questions we might otherwise overlook. In this part of our series, we look at how to represent when one object is made up of other objects. The two types of relationships we explore are composition and aggregation.

Catching Up on UML Class Diagrams

If you’ve found this article first, there are two that came before it.

1. Uncovering Requirements With UML Class Diagrams Part 1: Discusses how to represent objects and entities from a business perspective.
2. Uncovering Requirements With UML Class Diagrams Part 2: Discusses simple relationships between objects or entities.
3. Uncovering Requirements With UML Class Diagrams Part 3: This article.

So jump back to the other articles and get up to speed. We’ll wait for you here. As a reminder, in this series, we’re specifically focusing on using UML class diagrams for uncovering requirements – as part of analysis, not design. We’re talking about what the business needs, not how the solution will work. UML class diagrams can be used for both, and most tutorials are written for programmers doing design work. This one is written for people who work with requirements.

Relationships of Combination

When a collection of bananas are combined, we call them a bunch. Crows exist in a murder, and lions in a pride. Teams are made up of players. It is a deck of cards. An order is a collection of line items. We have always had the notions of both individual items (or people) and combinations existing as an interesting entity. Sometimes we treat them the same – you can eat a banana or a bunch. You can feed a lion or a pride. Sometimes, we deal with the combined entity. You shuffle a deck, you fulfill an order.

Understanding this type of relationship can be very important to understanding what your customer (aka “the business”) needs. You are describing the mental model of the business. Business people think about fulfilling an order, not “fulfilling all of the items on the order.” A user may want to archive the history (all the previous versions) of a file, or she may just want to keep the most recent version. Thinking about these concepts helps you uncover the requirements.

There are two jargon terms – aggregation and composition – that apply when we talk about multiple things as one combined thing. They have precise meanings.

• Composition – when one item is part of another item, the relationship is composition.
• Aggregation – when one item can be included in another item, the relationship is aggregation.

If that doesn’t make sense, this “formal” distinction will really mess you up:

Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts.

Scott Ambler

Here are some examples that may simplify things:

Composition

• A building is composed of one or more rooms (a room is part of a building)
• A plane is composed of a fuselage, one or more engines, and one or more wings (a wing is part of a plane)
• An order is composed of one or more line items (a line item is part of an order)

Aggregation

• A team includes more than one players
• A library includes more than one books
• A market includes one or more customers

Ambler’s definition makes sense, when you think about these examples. You could shut down a library without destroying the books – likewise, you could kick one of the players off a team and the team would still exist. That’s what he means by coincident lifetimes.

Drawing a Composition Relationship With Visio

To draw a composition relationship in Visio, you use the composition shape from the UML Static Structure stencil.

When you first drop this shape on the page to connect two classes, it looks like the following:

There is a solid black diamond on one end (the first end) and nothing on the other end. In UML, this is stating that an order is composed of line items. By default, Visio shows the “end names” as it did with the association shape. You can fix it the same way we did before. Right click on the line and select shape display options.

Then make the same modification we did before, to show the shape name and suppress the display of the “end names.”

Now you have the kind of display you want. Note the check marks at the bottom of the dialog – you only have to make this change once per class diagram. Unfortunately, Visio does not remember this change, so you have to do it once for every diagram (every new file, and every new tab within the same file). Annoying.

Double click on the line to update the information about this composition relationship.

You will end up with the following (we re-arranged it to make it easier to read):

Drawing an Aggregation Relationship With Visio

Drawing an aggregation relationship is almost the same as a composition relationship with Visio – it just requires an additional step.

In this example, a book club reviews books. You want to show that the book club includes members. Note – members can come and go without causing the book club to be disbanded. You can think of aggregation as membership in a combined entity.

First, use the composition shape again (the same as above), and update the properties as we just did. You will see

The Visio stencil does not include a special aggregation shape, so we will cheat by changing the formatting of the composition shape. Select (in the menu at the top of the window) format > line…

And in the dialog, you will change the display of the “Begin” end-point.

Aggregation is represented in UML Class Diagrams with the same diamond-shape as composition. The difference is that the shape is “empty” instead of being a solid black diamond. Click “Apply” and “OK” and you end up with what you want:

Note: If you change the format of the composition line first, and then change the properties (“Joins” etc), Visio will reset the line end to be a solid diamond again. It resets. Annoying. If you copy an aggregation line, the copy reverts to the solid diamond again too. Very annoying.

Next Up

Up to this point, you’ve learned how to define classes (and attributes), simple relationships (A book club reviews books, and a member reads books), and combinations of items as compositions and aggregations (an order is composed of line items, and a book club aggregates members).

Next, we will cover hierarchies, usually thought of as “Is a” relationships. A Sales Rep is an employee, and an employee is a person.

Uncovering Requirements With UML Class Diagrams Part 4: Generalization (inheritance) and how to use it.

We continue our exploration of UML Class Diagrams with this article that explores how to represent basic business relationships in a class diagram. Drawing these relationships can dramatically clarify requirements documents. Using a class diagram to supplement other requirements documents provides for a centralized reference that enables a shared understanding of the problem domain. That understanding prevents mistakes in interpreting requirements.

Getting Up To Speed

We started this discussion of class diagrams last week. In it, we presented the notion of a class. When a stakeholder cares about a concept, idea, or thing, we represent it as a class.

The business cares about customers. And customers have addresses and credit ratings.

Classes and Attributes

How do you know when something should be an attribute, and not another class? In our example above, think about Customer and Address and Credit Rating. One way to make a distinction is to say that if an attribute has other attributes, it should be a class. A credit rating is just a number. But an address is a compound object made up of multiple attributes.

An address can have multiple lines of street address information, as well as city, state, zip code and country information. That is a good indicator that it is likely to be a class of its own. If we were to represent an address as attributes of a customer, we would have to include each of the “sub attributes” as a separate attribute of customer. That feels bad, from a design standpoint.

The distinction is one of design, but generally speaking, if the concept stands on its own, it should be its own class. An address is related to the customer. A credit rating is a property of a customer.

Simple Relationships

How do we show a relationship between a customer and an address?

The customer receives bills at an address. That is the relationship between the customer and the address. The business wants to know where to send bills for the customer. We’ll talk more about relationships in a bit. First, we’ll cover the steps in visio for creating the relationship shown above.

Showing Relationships With Visio’s UML Stencil

The relationship shown above is called a binary association, because it shows the association between two classes. There is an object (Visio calls it a “master shape”) in the Static Structure template for creating these, aptly named binary association.

Drag that onto the page, and connect the two classes for which you wish to show a relationship.

The default display properties for the binary association shape cause the shape to display some weird information – called the “end names” of the relationship. The shape also does not give us the arrowhead, or the name of the relationship, Receives Bills At. Right click on the line and select “Shape Display Options…”

Remember this, you will use the dialog that pops up a lot.

We want to do three things for now:

1. Check “Name” so that the name of the relationship (Receives Bills At) will show up.
2. Un-check “First end name” so that it is hidden.
3. Un-check “Second end name” so that it is hidden too.

Click OK, and the shape will have updated to look like the following:

The name is defaulted (to “Association1″), and no arrowheads are showing up. We also have two asterisks, an no “1.” We need to update the shape’s properties (not display properties) to include that information. Double click on the line and you will see the following dialog (Fill it out to match):

[click for full size view]

• Name: Enter “Receives Bills At.” for the name. Note – some people prefer mixed case or lower-case. Any approach is fine, just be consistent. The name is the name of the relationship and it indicates the meaning of the relationship.
• Name Reading Direction: forward and backward will confuse you. It confused me for years. This is what determines where the small solid triangle shows up to indicate the direction of reading. Customer Receives Bills At Address, instead of Address Receives Bills At Customer. One day, I realized that this field only controls if the triangle shows up before or after the text. With up-down relationships, I still get confused. Use the standard of top-to-down is the same as left-to-right, and you’ll eventually get used to it.
• Association Ends: This section shows the two ends as rows in a table – with five columns describing each end. For now, we will only focus on the last two columns. This is another area for confusion – the first row represents the top-left end of the line (when you drag it onto the page) and the second row represents the bottom-right end of the line. You can move the ends of the line around after you place it on the page, and the rows in this table will maintain their original associations. Try not to get frustrated when you get these backwards. I still make that mistake all the time, after creating a few hundred diagrams over the course of a decade. Think of the top-left end of the line as the “first” end, and the bottom-right as the “second.” Then when you move it around, you might remember which is which. If you get in the habit of attaching the line first to the “from” class, and then to the “to” class, you will start to get the hang of it.
• Multiplicity: Multiplicity allows you to specify how many objects can be on either end of the relationship. In our example, a customer can receive bills at only one address, but multiple customers could share the same address. My stepdaughter and I each have iTunes accounts. We are two separate customers, but we have the same address. Since I attached the “first” end to the Customer class, there is an asterisk in the first row, and a “1″ in the second row. [*See below for explanations]
• IsNavigable: Either the UI designers for Visio expected all of their users to be Java programmers, or they ran out of space. “IsNavigable” can be translated into “Should the arrow be shown on this end of the line?” Since, as a business, we care about the address at which a customer receives bills, we show the arrow for the “second” end. But we don’t anticipate (commonly) needing to determine all of the customers that receive bills at a particular address – so we don’t show the arrow in the opposite direction.

Types of Multiplicity

There are a few different concepts that can be displayed for multiplicity. Your developer co-workers and math geeks will call this cardinality. That’s probably even the better term to use. But since Visio chose multiplicity, so will we, at least for this article.

• 1: Exactly one object of this type is involved in the relationship. A customer has one billing address.
• *: Any number of objects (or none at all) are involved in the relationship. Any number of customers can receive bills at a given address.
• 0..1: Zero or one objects are involved in the relationship. A driver may or may not have a drivers license.
• 0..*: Same as “*”
• 1..1: Same as “1″
• 1..*: Any number of objects (as long as there is at least one) may be involved in the relationship. A shipment can include any number of items, and it must include at least one item.

This brings us back to our original relationship example.

The small class diagram above represents the following:

• A customer has a credit rating.
• An address includes three fields for “street information”, city, state/province/county, zip or postal code, and country fields.
• A customer receives bills at exactly one address.
• Any number of customers (or none at all) can receive bills at any one address.

Simple Relationships Revisited

With the mechanics of using Visio out of the way, we can show some examples of some other simple relationships.

• A sales rep sells products to any number of customers.
• Any number of customers purchase products from a sales rep.

Both examples above depict the same relationship, and either is acceptable. What would be bad would be to use the passive voice and say “any number of customers are sold products by a sales rep.” This is the same advice that applies when writing use case names – don’t use passive voice.

There are opportunities to misread requirements when relying solely on UML. Imagine we had a requirement that any customer always make purchases from a single sales rep. The goal is to provide a sense of relationship for that customer. Both of the diagrams above technically express that requirement. If a customer could have more than one sales rep, we would show “1..*” instead of “1″ for the multiplicity on the sales rep side of the relationship.

Someone reading the examples above could reasonably be unsure about the intended requirement. Is there a single sales rep for a given transaction? Is there a single sales rep for a given customer, regardless of the number of transactions? Only the latter interpretation is technically accurate – but either is a reasonable interpretation. Professor Daniel Berry, author of The Ambiguity Handbook [The actual title is From Contract Drafting to Software Specification: Linguistic Sources of Ambiguity, A Handbook], explained in a lecture last year at the 2007 IBRF that UML stands for Undefined Modeling Language. This is a good example of that.

By including the diagram within, or as a reference from, a requirements document, you provide both the context and the graphical clarity needed to understand the intent. Don’t rely solely on the diagram!

A product has a price. One product has one price. This relationship is almost too simple, making it difficult to come up with a good name for the relationship. “A product has a price of price” is awkward.

“A product will be sold for a price” is better. If we were limited to “has a”, we could make an argument that the price should be an attribute. But the price may have properties (like currency used), or may be calculated dynamically based on coupons or contracts.

Using action verbs will help with both understanding and elicitation. If you are reviewing the diagram above with a stakeholder, you are not likely to get any discussion from “product has a price” – of course it does. But if you show “product will be sold for a price” you will immediately trigger responses. Especially if you ask “how do you know what price to sell the product for?” Use active verbs with explicit meanings instead of “weasel words” like “has a.”

This is a very clear way to indicate that from a business perspective, the customer has a billing address and a shipping address, and no reason to expect them to be the same. If you have to worry about export compliance, you may add an “end use” address – the location where the product will ultimately be used. Imagine how messy that would be if we had used attributes instead of classes!

As messy as that would be, this highlights why we use classes. Think about some other business relationships we have not drawn. Credit card authorization uses the billing address. Taxes may be* calculated based upon the billing address or the shipping address. Shipping charges would be based upon the shipping address. [*I believe that for physical goods, the shipping address is used, and for electronic downloads, the billing address is used.]
There is no limit to the number of entities and relationships that can be represented in a class diagram. As a guideline, think about usability. Are you producing class diagrams as part of exploring specific areas of the business? Are you making sure that a complex set of relationships do not get oversimplified? Are you “boiling the ocean” with a giant encyclopedia of the business domain? If you are – why?

Summary So Far

So far, we have discussed classes as a means to represent entities from a business perspective. We’ve also introduced some simple relationships. Those relationships show how pairs of entities interact or inter-relate. We’ve shown how to make the relationships directional and bidirectional – depending on which way(s) the business needs to look at things. And we’ve covered multiplicity – how many of each type of object are involved in the relationship.

There is still a fair amount of ground to cover between here and Scott Ambler’s comprehensive reference. If any of the concepts so far are unclear, or if there’s something you want to make sure we cover – add a comment!

Next Up

In our next article on using UML Class Diagrams for unearthing requirements, we will look at more complex relationships.

Uncovering Requirements With UML Class Diagrams Part 3: Combining objects into collections and concepts.

UML Class Diagrams can be used not only for documenting software design, but for documenting software requirements. One of the challenges in writing clear, unambiguous requirements is being precise about what a particular word means. This is especially true with symbolic terms like “quote” or “customer” – where everyone knows what they mean – but they mean different things to different people.

Why Create UML Class Diagrams for Requirements?

One of the first articles we wrote in 2005 provides a very simple class diagram example, and an explanation of why you should use class diagrams to clarify your documents.

In prose, we could also capture the same information as follows:

1. The system shall include a representation of customer orders.
2. Each order will have a single associated customer, and each customer can have multiple orders. Note that a customer is not required to have any orders.
3. Each order will have at least one, and possibly multiple line items. Each line item is uniquely associated with a single order.
4. Each line item represents a single product. Note that a product is not required to be represented in a line item. A product can be represented in multiple line items (even within the same quote).

OOA is compellingly powerful as a descriptive tool – it took less time to draw the diagram, and it can be easier to read than the prose.

A Picture is Worth A Thousand Requirements

UML class diagrams, in addition to being potent for communication, can also help with requirements discovery. They provide a clarity and explicitness of understanding that helps you gain insight into the topics being explored.

Getting Started or Getting Refreshed

If you already know UML, or generally know how to draw UML 2 Class Diagrams, you can “test out” of this article, and go to the best, most thorough explanations we know of, courtesy of Scott Ambler.

• UML 2 Class Diagrams – an explanation, in detail, of how and what and why to draw things a particular way
• UML 2 Class Diagram Guidelines – advice on how to make your diagrams consumable and appealing

If your eyes glazed over, that’s ok. There is a lot to absorb. There are a lot of advanced concepts that can be represented in class diagrams, and Scott provides explanations and examples of how to do most of them. If you are new to modeling with UML, or are only interested in what you need to know to document requirements, those articles may be too advanced for now. We’ll try and close the gap. Keep those links handy, both for reference, and for deeper explanations than we cover here. If Ambler’s articles are written to help you be a master craftsman, we want to help you become a journeyman first.

Class diagrams are incredibly powerful tools for anyone doing requirements work. I never wrote about them before, because Ambler already did. And he didn’t leave me wanting more, so I never knew what to write. After a recent conversation with someone new to modeling, I discovered that he did leave a gap. There’s a fair amount of learning you need to do before you can really get the value from his articles. Ambler also addresses both the analysis and design uses of class diagrams.

We will focus exclusively on using UML class diagrams for analysis. So if you are a business analyst or requirements analyst, this will help. If you are a developer, this will help you read the diagrams that analysts create. If you are a product manager, this will help too, but I think you’ll need to do this less frequently than a business analyst would.

We do assume that you are already comfortable using Microsoft Visio, but have not used it for creating class diagrams. You don’t have to use Visio, but the tools in Visio are good ones for creating class diagrams.

Visio Template for UML Class Diagrams

The easiest way to get started is with the default drawing type already available in Visio.

Create a new file, and select the Software category, then scroll down and select “UML Model Diagram” in either US or Metric units. When you do, a number of stencils will automatically load for you. You want to use the UML Static Structure stencil.

These are the shapes that you use to represent objects in a class diagram. You can safely ignore all of the other stuff that Visio provides in the other templates.

The Class

When you drag the “Class” shape onto the page, you get the empty looking box on the left. Visio automatically names it for you as “Class1.” The class represents a concept, entity, item, or object. It is important for analysts to remember that what you are drawing is “how the business thinks about these objects” – not “how developers will implement a representation of the objects.”

There are three areas in each “class” shape. The shape on the right shows that the top area is where the name of the class appears (in bold), the middle section represents attributes, and the lower section captures operations that can be performed by the shape. This feels like describing an implementation or design. The terms attribute and operation certainly sound like programming. UML Class Diagrams may have initially been created to help developers design solutions, that would certainly explain the names. There is still a lot of power to be unleashed – so take it on faith for now – we’ll present some examples that demonstrate the value of class diagrams for analysis.

Imagine that you are thinking about a lamp. Perhaps you are designing an emergency battery backup system, and one of the things you need to think about is how much wattage a lamp requires to operate. The wattage of the lamp, in English, is a characteristic of the lamp. Programmers call it an attribute. For our purposes, the terms are interchangeable.

A lamp can be turned on. That is pretty intuitive. We imagine ourselves turning on a lamp. Actually, all we do is turn a dial (or flip a switch). When we turn the dial, the lamp turns itself on. If we were really playing with language, we might say “When the user requests illumination, the lamp turns on.” We would never use that phrasing for a concept as simple as a lamp, but you get the idea. The operation is something that the object can do. Dogs bark, cats meow, lamps turn on.

When we are creating class diagrams for requirements discovery, we will always use class names, almost always use attributes, and almost never use operations.

A customer, in the diagram element above has an address. The customer also has a credit rating.

The two elements above represent the same information. A product has both price and weight. We also find, during our requirements exploration, that we need to know if a product is available. Perhaps our users need to know if a product is available right now before suggesting it as an up-sell item to a customer. If that is our requirement, we realize that we need to know the availability of the product. You can either include the question “Is it available?” or a single name for the attibute – “Availability.”

It is better to use the word “Availability” for two reasons. First, it is consistent to say “price, weight and availability.” You could achieve consistency with all questions – “What is the price?” “How much does it weigh?” and “Is it available?” But that becomes overly wordy. The second reason for using a single word is to avoid embedding rules in your requirements.

Consider the “Credit Rating” attribute for the Customer object. What we really want to know is if the customer’s credit is good. The definition of “good” will change over time, or may become complex. “Good enough for small purchases”, “Good when putting 20% down” are examples of the definition of “good” becoming complex. Or maybe you’re loaning money, and you can improve your profits with notions of “pretty good” and “really good.” You will create business rules to define what you mean by good. You happen to know that those rules will reason about the customer’s credit rating, so you should capture that value.

You could but should not represent the notion of “Is Credit Good?” with an operation:

You end up specifying design here – however unintentionally. Depending on how you interpret this, you are either saying “Customers are responsible for determining if their credit is good” or “The credit worthiness of a customer is determined without considering anything other than the customer.” While precise for programmers doing design, this is a pretty ambiguous thing to document in an analysis. By adding this operation, you are not providing unambiguous insight into how the business thinks about customers. So don’t do it.

Next Up

In our next article on UML Class Diagrams for analysis, we’ll look at relationships between classes.

If there’s something in particular you’d like to see explained, add a comment below and we’ll either fold it into the series or answer in the comments. And remember – you can subscribe to the comments for any article, just click the link.

Uncovering Requirements With UML Class Diagrams Part 2: Simple relationships between objects or entities.

Barry Boehm, inventor of the spiral model of software development, may also be the originator of the CRACK acronym for the type of users we want on our projects. When defining (and executing on) projects, we don’t just want CRACK users, we want CRACK stakeholders. And we want them to stick around. In fact, we’re addicted to them.

What Are CRACK Users?

We are not talking about substance abusers here. We are talking about users, and stakeholders in general, who have the following characteristics:

• Collaborative - stakeholders define goals and provide feedback and are available to work together
• Representative - they characterize (or embody the personas) who make up our key users
• Accountable - along with collaboration comes a sense of ownership: we succeed or fail together
• Committed - not just in percentage of time dedicated to the project, but also continuity of involvement over time
• Knowledgeable - understanding more so than knowledge leads to insights but both improve our deliverables

Thanks, Mike Griffiths, of Leading Answers, who points out the value to agile teams of having CRACK users. His article is actually focused on what to do when you can’t get users – and I love suggestion number three. Thanks Mike, and keep it up!

Before giving Mike all the credit, I wanted to see if anyone else was writing about CRACK users. Several of the top search results pointed to articles or presentations by Barry Boehm, who, due to his significant software engineering contributions, gets our “he must have invented it” accreditation.

As a quick tangent – during the search, I found a couple presentations by Barry were awesome.

• 2003 SERA Keynote Address – talking about agile and deliberate (non-agile) project approaches
• Systems of Systems: Characteristics and Challenges – dealing with enterprise architectures and projects in the tens of millions of lines of code arena.

This is a short one, but the idea is strong, and the linked presentations give you plenty of good stuff! Thanks Barry and Mike!