The industrial age is behind us. It was surpassed by the knowledge economy, rapidly evolved into the attention economy. Successful companies realize that attention comes as a result of conversation. We’re now in the conversation economy.

Software as a Service and Conversation

Software as a Service (SaaS) products are products where instead of paying an up-front licensing fee, customers make recurring payments, for as long as they use the software. As soon as the software becomes obsolete, or you no longer need it, you stop using it – and stop paying for it. As long as the product continues to be relevant, and continues to provide the best solutions for your problems, you’ll keep using it.

Peter Cohen at SaaS Market Strategy Advisors, recently did some analysis on the lifetime value of a SaaS customer. What was particularly interesting was that he found that the return on investment (revenue versus cost of acquisition) grows dramatically over a one, three, and five year analysis. His analysis is particularly exciting because he’s quantified the benefits of focusing on your existing customers.  Anecdotally, he shows that Salesforce.com needs to keep customers around for a bit under three years to cover their marketing expenses.  Given how integral CRM becomes once deployed at a large company, that’s not a bad bet – Salesforce can become an entrenched player, who will only be displaced when their customers focus on the ongoing costs (versus the ongoing benefits).

In my previous article on the economics of SaaS (and the extended remix version published in The Pragmatic Marketer), I provided a qualitative analysis, and the logical conclusion that SaaS providers are incented to focus on their existing customers. Cohen’s analysis supports those conclusions and makes them more concrete.

Long Term Relationships and Conversation

A long term relationship with your customers requires you to have an ongoing conversation with them. To keep that relationship going for years, it also needs to be a fantastic conversation.

A fantastic conversation is one where not only you, but your customers are engaged. Ask yourself – if you’re talking to your customers over coffee, are they leaning back, or leaning forward? Engaged users are leaning forward, and disengaged users are leaning back.

If your users aren’t leaning forward, you need to figure out how to make the conversation more interesting to them and get them engaged.

Activity Versus Engagement and Conversation

In the bad old days, you either forgot to think about your customers, or you thought about them as active or inactive.   That was the way we framed analysis.  And SaaS models forced us to focus on helping inactive customers re-activate.

A conversational model is different, however.  Just because a customer is active does not mean they are engaged.  More on this later – just planting a seed for now.

The Freemium Business Model and Conversation

The freemium business model is one where some people get to use your product for free, where other people are paying customers who get to use a different version of the same product. The revenues from your paying customers cover the costs of providing your product to all of your customers. This is a common business model to use with SaaS products, but can also be applied to licensed products. The costs of development, support, and ongoing operations are all covered by the paying customers – even though you incur costs from the free-product users too.

In a recent interview with Damon Darlin on the New York Times site, Evernote’s CEO, Phil Libin talked quite candidly about the conversion of users of the free version of Evernote into paying customers. He noted that the longer a user sticks around, the more likely that user is to become a customer of Evernote’s for-a-fee version.

Mr. Libin studied the behavior of the earliest adopters and found that the longer customers used the service, the more likely they were to start paying for it. About 0.5 percent convert to paying customers in the first month. But after about a year, 4 percent have converted. (He says he thinks the figure will top out at about 22 percent.)

While I’m not convinced that 22% conversion is achievable, the trend is obvious, and 4% is a fantastic number.

You have to have a pretty engaging conversation to keep users around long enough to be profitable.

Combining The Activity Model and the Freemium Model

We can combine the active-inactive perspective with the for-a-fee and for-free approach, and we get the following magic square.

This diagram is interesting, but oh-so-2005.  The only moderately interesting insight you get is that the inactive, for-a-fee customers are at risk.  They’re just giving you money for no good reason.  You should probably figure out how to help them before they go away (and take their money with them).

Introducing a Conversation Model – QCP

As I mentioned earlier, being active does not necessarily mean being engaged and conversational.  The following three categories make sense for thinking about “how conversational” a customer is:

• Quiet - An active, satisfied, and possibly loyal, but not outspoken customer (or user).
• Conversing - A customer or user who is engaging with you and with the community about your products.
• Promoting- A customer or user who is actively encouraging other people to become customers or users.

Quiet customers are like the active users in the old model.  They use the software and pay the bills on time.  Quiet customers are passive.  But in a conversational economy, that’s not enough.  It may be enough to keep the lights on, but you can’t hope to defend against your competition when all of your customers are quiet.

Conversing customers are engaged in conversation – with you and with the community (yours and theirs).  Conversing customers are following you on Twitter, they are fans of your Facebook page, and they retweet, like, and favorite your messages.  They interact with you – asking questions, submitting bugs and feature requests.  The write blog posts, and are extroverted in sharing their relationship (with you) with their friends.  In the standard “engagement model” (satisfied, loyal, and engaged), these customers are engaged.  From the conversing customers you improve your understanding of your market, users, and competition.  These customers are the foundation of your business.

Promoting customers are your dream team.  They aren’t just interacting publicly with you, they are promoting your product.  When you begin to focus on word of mouth marketing, or viral product management, you’ll start sending presents to these folks and inviting them to the company kegger.

Your Thoughts and More Thoughts

I’d love for you to share your thoughts here with me and everyone else!

I feel like this is more of a starting point than a comprehensive article.  For example, I have some scribbles about how to move customers  from the “active free” box to the “active for-a-fee” box (and from inactive to active, etc), and how to move people up the QCP ladder.  Will cover that stuff in a future article.

So – chime in, and as my dad would say, please and thank you!

Pictures can convey messages much more powerfully than words.  In a recent discussion about writing whitepapers, I suggested combining the idea-creation advice from Made To Stick with the image-creation advice from Back of The Napkin.  Check out this article to see some concrete examples.

Made To Stick

Paul Young, product manager and author of Product Beautiful,  sent out a tweet the other day asking:

Anyone have any “best practices” for whitepaper development? E.g. most whitepapers I read are stilted, I want to make something compelling.

Tweet, on twitter

I suggested combining the ideas from Made to Stick and Back of the Napkin to create a compelling whitepaper.  Stephanie Tilton then replied with a link to a good article she wrote showing how to apply the ideas from Made to Stick to writing whitepapers.

The book, Made To Stick: Why Some Ideas Survive and Others Die, written by Chip Heath and Dan Heath, has some very powerful ideas for communicating ideas.  Stephanie sums them up nicely in her article:

• Simple
• Unexpected
• Concrete
• Credible
• Emotional
• Stories

Stephanie Tilton, How to Craft Whitepapers that Stick in People’s Minds

Check it out, she goes into more detail, with examples and insights about why they work.  What about the Back of the Napkin ideas?  That’s what this article covers.

Back of the Napkin

I remember feeling like I’d been hit in my frontal cortex with a frying pan at Product Camp Austin (Winter 2009), when I first saw a visualization created by Sunni Brown of Brightspot for one of the presentations.  I remembered hearing about Back of the Napkin: Solving Problems and Selling Ideas with Pictures, by Dan Roam, and immediately ordered it from Amazon.  This is actually the current book for the Smarter Product Managers book club.

Applying these visualization techniques is extremely compelling for sharing ideas.

There is a ton of science behind why (and how) visual presentation of ideas (pictures) works so well.  Dan Roam does a fantastic job of making this approachable and actionable – an excellent book.

Getting back to the conversation…

How to Put Pictures in your Whitepaper

The rest of this article is showing some example images, in Back of the Napkin style, that support the ideas from Made to Stick, as you would include them in a whitepaper.

Imagine you’re writing a whitepaper about requirements elicitation.  There are a lot of important topics you could cover, but to stay aligned with the simple message from Made to Stick, you will want to focus on one idea (for each whitepaper, as Stephanie explains in her article).

User representatives are often offered to business analysts as a “convenient” source of requirements – the actual users are too busy, too valuable, or too easily distracted/upset/encouraged by conversations about the future.  This idea is both bad and pervasive.  You want your whitepaper to convey emotionally why this is bad.  You need something concrete, and maybe you want to tell a story.  Consider this image:

This is poorly drawn (but that’s ok!), but it establishes the metaphor that inserting user representatives into the elicitation process is like playing the telephone game.  The message (user goals) gets lost between the users and the business analyst.  It also points out that the conversation between users and analysts is what makes good requirements elication, well, good (ref. the smiley faces in the drawing if you’re not sure).

Designing for “Everyone” is a Bad Idea

One challenge for product managers is determining which features to include in their product roadmap.  Industry analysts, and sometimes buyers, have been known to use checklists to pre-screen or select products.  That may be true, but using a checklist to prioritize your product development is a bad idea, because you end up creating a product that doesn’t thrill any particular users, and just makes analysts happy.

The quick mock-up of a Consumer Reports style checklist shows a comparison of your product against the competition’s product.  With six features (A through F), it appears that your product is better.  [Here's an article comparing elicitation techniques, with a real consumer-reports-style checklist and an explanation of how to read it.]  You have six “half-circles” which looks to be “better” than two “full circles.”  Therein lies the danger.

Any individual user cares about two or three of those features (capabilities), not all six of them.  Will that user prefer your product or the competition’s product?

That user is thrilled to use your competition’s product, because it does what that user cares about, really well.  Your product is half-baked. Happy analyst, missing user (for you).

Increasing Distribution Channels Decreases Sales

Another key idea from Made to Stick is the notion of presenting the unexpected.  The authors point out that you need to demonstrate an idea that is at odds with the reader’s concept of reality – breaking it – and then rebuild the reader’s sense of reality around your new idea.  That’s where the unexpected comes in.

Consider that you are selling a product into a crowded market, with many places that customers could buy your product.  You do your inital launch, selling through one sales channel.  Someone proposes adding other channels – hey, more is better, right?

How do you prevent this Benedict Arnold from killing your company with what looks to be a great idea?  How about getting people’s attention with this “violation of common sense”:

That will get people’s attention.  What the Heath brothers point out is that to establish credibility with this unexpected visual, you have to rebuild people’s perspective.  You could do that with the following:

Since each store (channel) has a best-sellers list, like the Billboard charts for music, you want to make sure you’re at the top of the list.  Most downloaded is a common metric for software available on shareware and freeware sites.  If people can get your product anywhere they happen to be, it will dillute your rankings at every store.  By targeting your marketing and making your product available at one store, you will get more traffic (at that store) than you otherwise would.  Then new potential customers will be more likely to discover your product because it is at the top of the list.

Climate Change

I touched on credibility in the last example.  As Stephanie points out in her article, the Made to Stick authors were talking more about data than visceral understanding.  The first thought that popped into my head was the effectiveness of Al Gore’s data in his An Inconvenient Truth book (and presentation and movie).  He demonstrates that there is a correlation (and implies that there is a causal effect) between the average temperatures on earth and carbon dioxide levels.

Pretty powerful message.

Conclusion

Pictures like the ones above, drawn as Dan Roam suggests in Back of the Napkin can make the ideas you present in your whitepaper really memorable.  Use the Heath brothers’ approach from Made to Stick in crafting your message, and fold it into your whitepaper as Stephanie suggests.

The result is a compelling and memorable white paper, just like Paul always wanted.

Blue Ocean Strategy provides an interesting reactive analysis of companies and markets.  Personas are used to understand your customer’s needs.  Combining the two provides powerful proactive insights when positioning your product for market success.

Blue Ocean Strategy

The book, Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant, by Kim and Mauborgne, was written in 2005.  The book presents a very compelling way to visualize competition in your market by contrasting the emphasis (or effectiveness) of each company at solving particular problems.  The authors argue that red oceans are competitive markets where companies compete to solve the same problems for the same customers.  Their main idea is that by identifying (and solving) unaddressed problems, you can define a new market – a blue ocean with no relevant competitors.  The “red” in their metaphor implies blood in the water, caused by cut-throat competition.  Their position – by defining a new market boundaries with no competition, you eliminate the blood in the water and give yourself a calm, blue ocean in which to navigate your company.

This is a compelling idea, and has a lot of merit.  The Smarter Product Managers book club (started by Cindy Alvarez) reviewed this book last month, and one conclusion we reached during the discussion is that the examples in the book felt “reverse-engineered.”  I feel that the lack of prescriptive advice from the authors created a sense of “that’s fine, but how do I apply these ideas proactively?”   Some of the examples in the book, like Cirque de Solei and Southwest Airlines, felt very compelling (and are often cited), while others felt a bit more contrived.  Almost as if the authors were searching for data to support their arguments – a big no-no for product managers.

Creating a Blue Ocean Strategy Map

The book presents examples of “mapping” markets based upon the strength of the offerings from companies, along different dimensions.  The following example was created by me (and is used throughout this article), but follows the pattern of analysis described in the book.  This is an unresearched, hypothetical example analysis of the market for vaccuum cleaners – or more generically, floor cleaning products.

 [larger image]

The diagram above identifies seven dimensions by which you could characterize the offerings from each company.

• Breathe Easier / Anti-Allergen – sometimes, people vaccuum their rugs in order to reduce allergens (by sucking up dust), making it easier for them to breathe in their homes.  Vaccuum cleaners work by sucking up air through the carpet, collecting the dirt (that is sucked up along with the air), and filtering the exhaust air (that is expelled into the room).  Different vaccuum cleaners pay different levels of attention to removing allergens during this cleaning process, by (1) getting the allergens out of the carpet and (2) filtering the allergens out of the exhaust air.
• Remove Stains – one motivation to clean your floor is to remove stains.  This is not generally a focus of vaccuum cleaners, but products like the Green Machine do focus on removing stains, while also “picking up dirt.”
• Physically Easy to Use – after back surgery, one of the key pieces of advice my mother received from her doctor was “no vaccuuming.”  When you are young and healthy, you don’t expect vaccuuming to be something that is forbidden by your doctor.  Shoveling snow, climbing a mountain, running a marathon, yes – but vaccuuming?
• Reducing Hassle – Why don’t we vaccuum every day?  Because it can be a hassle to get out the vaccuum, set up the equipment, and actually use it.  When you reduce the hassle involved in vaccuuming, you are likely to vaccuum more often, thereby realizing more benefits from vaccuuming.
• Saving Time – Hassle is not the only barrier to vaccuuming.  If you could vaccuum your house in 5 minutes instead of 105 minutes, you would do it more often.  As a teenager, I used to jog behind the lawn mower, just to get the yard done so I could move on to other things.
• Reliability – While reliability is not a major factor when vaccuuming your house (once), it is a key component of making purchasing decisions – because you don’t vaccuum just once.  The more you vaccuum, the more you care about reliability.  This is also an indirect cost factor – a vaccuum cleaner that has to be frequently repaired or replaced will cost more per year than one that has the same purchase price and is more reliable.  This is also an indirect hassle factor – you may delay vaccuuming your home until you can make time to get a broken vaccuum cleaner repaired.
• Avoiding Cost – A direct focus on cost is primarily driven by purchase price.  Other factors (like reliability, and the cost of replacement bags or filters), but people place greater emphasis on purchase price when thinking about cost.  Consumer Reports and other “product review” companies will often “do the math” for you, taking into account all of the post-purchase costs to calculate total-cost-of-ownership.

The above diagram, with fictitous values for “Strength of Competitive Offering”, shows the competitive landscape for the vaccuum cleaner market.  One of the very powerful features of this visualization is that the Roomba faces “no competition” from the other companies in three of the seven categories – Ease of Use, Hassle, and Time.  A Blue Ocean Strategy analysis would say that the Roomba has created their own market, with an absense of competition.

This gets back to our insight that the examples felt “reverse engineered.”  The Roomba does have a dramatically different value-proposition, and focused on dimensions that are not addressed by their competition.  So why isn’t the Roomba in the book?  Because they still compete in the red ocean.  Unlike Southwest Airlines, they did not differentiate their offering in a relevant way.  And that’s the problem we found in trying to apply the principles from the book.  

It is not enough to be innovative and differentiated, which the Roomba certainly is, you have to be valuably differentiated.

So how do you differentiate valuably and proactively?  Identify the problems that your customers value, but don’t yet have solutions for.  How do you do that?  With personas.

Personas

Personas represent customers in your target markets.  Markets are not homogenous – different people in your markets value different things for different reasons.  You develop personas as archetypes to represent subsets of the customers in a given market who share common problems.  More concretely, personas share common valuations of shared problems.

To combine persona development with the market-mapping concept from Blue Ocean Strategy, create the same map, but for personas.  Instead of identifying the strength of each company/product along each dimension, identify how much each persona cares about each particular dimension.

 [larger image]

In the chart above, I’ve created 6 hypothetical personas who populate our market:

• Single Parent – the classic superman / superwoman who does everything, including keeping the house clean.
• Housekeeper – someone employed to keep someone else’s house clean.
• Office Cleaner – the person who vaccuums your office at 2am every night and picks up all the empty Diet Coke cans and Twinkee wrappers.
• Kid (Doing Chores) – most kids won’t ask for a vaccuum cleaner for their birthday, but when you child is responsible for vaccuuming, do you want a battle every week because they hate it?
• Homeowner – like the single parent, but maybe without kids, and definitely with fewer responsibilities (and more time).
• Retiree – like the homeowner, but with a lot more time, and a less robust physical condition.

[Note - the above examples are really stereotypes and not personas (there is no research to back them up - they are entirely fictional) - don't fall into the trap of thinking persona development is this easy.]

OK, now we have an understanding of how much importance each persona places on each dimension.  It looks like a mess, for this example, when you try and absorb the big picture.  If you focus on a single persona, you get great clarity about what that type of customer cares about.  Look at each curve individually, then look at them all together.  If you’re thinking ahead, you’ll suspect that the Roomba is perfect for the kid doing chores.  But wait, we’ll come back to that.

One insight we can gain from this messy view of the market is that you can’t create a product that is “perfect” for all of these personas.  You have to target a specific persona, and tailor your product for that persona.

Mapping Personas to Products

Now we have two views of the market, along 7 dimensions.  We have assessments of the relative strength of each competitor’s offering, and we have estimates of the relative importance to each persona – for each dimension.  What we need to do is combine the two.

All of this analysis runs the risk of introducing a notion of false precision - we have a lot of data, therefore it must be accurate.  So our inclination may be to try and do some mathematically refined, scientific analysis.  I suspect that would be wasted effort, providing no additional insights, and risking leaps to the wrong conclusions.  I propose a simpler approach.

The analysis we really care about – which product offering is best aligned with the needs of each persona?  A simple mathematical equivalent of “which curves match the best” is an easy analysis.  By comparing the values from each competitor curve with those of each persona curve, we can create a series of “how good a fit is it?” values.

 [larger image]

Imagine a persona saying “how well does each company’s product align with my goals?”  This “simple math mashup” takes into account both “they succeed at what I care about” and “they haven’t invested in something I don’t care about (at the expense of something I do care about).”

You can see that the Roomba clearly wins with kids doing chores.  The rest of offerings stand out less, but do provide insight.  Now you can easily drive strategic decisions – “we want to be the vaccuum of choice for housekeepers” now drives some obvious emphasis on ease of use and a reduced emphasis on reducing costs.

Improving The Model

My two main problems with the blue ocean strategy were lack of relevance (who cares about dimension X) and magnitude (which dimension is most important?).  The model above addresses only relevance – a focus on target personas.  We can overlay some “relative importance of each persona” data, or just manually focus our efforts on each persona in series.  

The other magnitude challenge is in understanding not just which problems are important in absolute terms (kids care a lot about saving time, but not cost), but in relative terms (kids would trade an hour of time for a modicum of ease-of-use).  Essentially, defining the utility-curves for each persona.  For any but the largest, most saturated markets, I would hesitate to do the utility curve analysis in detail – it feels too heavyweight and un-agile.

Conclusion

The Blue Ocean Strategy book provides us with a visceral tool for visualizing relative offerings from competitors in a given market.  Combine it with the same visualization approach for personas that participate in that market, and you gain insights into which problems to solve next to achieve product success.

We spend a lot of time (rightly) on the capabilities of our products – identifying valuable problems and compelling solutions.  This focus is ideal for addressing the needs of our users.  But what if people abandon our products before trying them?  First impressions matter – both for buyers and users.

SXSW BizSpark Accelerator

Microsoft sponsored the BizSpark Accelerator at SXSW this year, where several startups competed by giving a 2 minute presentation of their products / companies.  The panel of judges emceed by Guy Kawasaki and Brad King.  The contestents were the top 20 from 200 submissions.

First Impressions

I was lucky to attend part of the event, focusing on the eight finalists in the Innovative Web Technologies area.  I recorded the presentations, but the camera shakes so badly in my hand that watching them is like trying to listen to a lecture while riding a rollercoaster.

Two minutes is barely enough time to make a first impression.  Each presenter had 15 minutes of Q&A with the panel, where they could get into more details and provide feedback to the entrepreneurs.  First impressions, however, are made by the very first thing you say.  Here’s the first sentance from each of the presenting finalists:

• klout.net – Hi everyone, I’m Joe.  At klout, we measure influence across the social web.
• OtherInbox - Thanks everybody, my name is Josh Baer, and I’m here to tell you about OtherInbox, which helps you save your real inbox for real people.
• Piryx - The idea is that you want to wake up, create an account, run for public office, and change the world. [Note - I lost the first sentance when recording, but this is the first substantive sentance]
• Ribbit.com – My name is David Lee, I am the director of strategy and business development for Ribbit Corporation. Ribbit is a cloud service for enabling communications innovation, bringing together the internet, voice, and data.
• Ringlight - I’m here to talk to you about my company, Ringlight.  My name is Brandon Wiley, I’ve been working in peer-to-peer for a decade, from the first peer-to-peer application, freenet, to the most popular peer-to-peer application in the world, bittorrent.
• Thrive - My name is Avi Karnani from Thrive.  I’m going to show you a new feature we’re about to launch called behavioral budgeting.
• YouData - Let’s talk about internet advertising.  [something garbled as the speaker had trouble speaking clearly into the microphone]
• Zoomorama - Hello, my name is Franklin, and I’m president of Zoomorama.  Zoomorama comes from panorama, the wide open space, and indeed zooming is not just about details, it is mostly about space. [Note that in parallel with the speaker, the display was showing some compelling image zooming technologies]

Every one of these presenters made a first impression.  klout, OtherInbox, and Zoomorama (and maybe Piryx) tell you what their products do in the opening sentance.  Ringlight and YouData both set the tone by identifying an existing space.  Thrive lets us know that whatever it is, we haven’t heard of it before, and Ribbit shared a lot of jargon words.

Elevator Pitch

When I was in presales, I learned how to craft an elevator pitch.  What I had not heard of before this year’s conference was the one-floor/two-floor pitch. 

An elevator pitch is a presentation of what your product (or company) does, that is short enough to be delivered while conveniently riding on an elevator with the really important person you want to hear your pitch.  It is a powerful image, used to remind us that people will usually give us a brief opportunity to get their attention.  To get more time, we have to earn additional attention.

The one-floor elevator pitch is a variation of the elevator pitch, but imagine your audience gets off the elevator after one floor.  You really only have time to get out a sentance or two – just like the above quotes.  

Which of the eight presenters, after giving the quotes above, would get invited to follow their listener down the hall, and which would have to stay on the elevator?

I saw the full presentations, and one of the presenters is a client, so I won’t share an opinion.  Would love to hear yours.

As a product manager, what would you have wanted the presenter to say for the one-floor elevator pitch?

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 picture is worth a thousand words.  Agile values working software over comprehensive documentation, and it values customer collaboration over contract negotiation.  With that in mind, how much is a picture of a model worth?  Check out a simple example, how it helped, and what we didn’t do.

A Complex Conversation

I was working with a client on an eCommerce website, where one of the things that was important to the client was having and managing an affiliate network that refers visitors (and ultimately customers) to the website. The conversations around exactly what the stakeholders of the eCommerce site wanted were pretty convoluted, and different stakeholders described the “requirements” differently.

Affiliate Network Background

An affiliate network can work in the following way:

1. When someone visits a website, and does so by directly clicking on a link on an affiliate partner’s page, the website is able to identify the affiliate partner who “sent” the visitor to the website.
2. The website keeps track of who “sent” the visitor.
3. If the visitor becomes a customer, the affiliate partner who sent the visitor is compensated.  One way to compensate that affiliate partner is by giving them a percentage of the revenue that the customer generates for the website.

This can be a lucrative model for both the eCommerce site and the affiliate partner.  The partner gets paid for funneling traffic to the eCommerce site, but not necessarily doing any other work (beyond what it takes to encourage people to go to the eCommerce site).  The eCommerce site gets increased traffic, at a manageable cost – proportional to the revenue generated by the incremental visitors (who would probably not otherwise visit the site).

Each business gets to focus on its core competency (sending traffic, for the affiliate partner; converting that traffic into revenue, for the eCommerce site).  The eCommerce site invests the majority of the time and money (probably orders of magnitude more investment), and the affiliate partner shoulders all of the risk, but can do this for almost no cost (if they want), in exchange for an uncertain revenue stream.  This blog is currently trying out an affiliate relationship with Carbonite – because I love the product (and therefore think people who visit Tyner Blain will too), and because the revenue generated, if any, will help defray the costs of writing and maintaining the blog.

Specific Complexity of an Affiliate Model

The complexity of this “simple” model becomes apparent when you ask a few clarifying questions.

• Will there be multiple affiliate partners?  (Yes)
• If someone is referred by multiple affiliate partners (on separate occasions), who gets credit? (The last affiliate partner who sends the customer to the site)
• Does the visitor have to purchase during the visit that was made from the affiliate partner’s site? (No)
• Is there an expiration date, after which an affiliate will not get credit for customer purchases?  (Yes, “N” days).  [Note: I am obscuring the actual value for this article, but N is a real number.]
• If a customer who was referred by an affiliate makes multiple purchases, for how many of them is the affiliate partner credited?  (One)

Asking these questions in different ways generated some different, and potentially conflicting answers.  The list above is the “after we put it all together” answer.

A Simple Model

We solved this problem by grabbing the immediately available stakeholders and pulling them into an office with a whiteboard for about 3 minutes.  [Ed: Our first article about using object-oriented analysis as part of requirements gathering is from three[!] years ago, this is not a new idea, and wasn’t then, either.]  I drew the following state transition diagram on the whiteboard, using an active listening technique, to confirm that I had consolidated the inputs into the right set of business requirements.  Documenting business rules with a state transition diagram was very effective at highlighting them.

Most of the explanations from stakeholders were in more of a use-case format, but a state-transition diagram was more effective at validating the rules and requirements in this situation.

The diagram above uses the following approach to describing the problem:

• Some customers are considered to be “actively referred” by an affiliate partner – and when that is true, an affiliate receives compensation for the order placed by the customer.  Other customers are not considered to be “actively referred” and no compensation is due to the affiliate partner.
• Customers can be “temporarily actively referred” and events modify that state.

What the diagram shows, given that context is the following business rules:

• When a customer is referred to the site, the “to be compensated” affiliate partner is identified, and associated with the customer.
• When the same customer is referred to the site by a different affiliate partner, the new affiliate replaces the old one.
• If “N” days pass after a customer was referred by an affiliate partner, that affiliation expires, and the affiliate partner is not compensated for future purchases.
• An affiliate partner is only compensated for the first purchase made by the referred customer.

The stakeholders that were present confirmed that this perfectly represents their business requirements.  Even cooler – a couple days later, the business person most-directly-responsible for implementing the programs came by, looked at the whiteboard, and signed her name on it to record her approval.  We also have a camera-phone snapshot of that.

What We Didn’t Do

I could have titled this article Mini-Model and Requirements, but Agile seemed more appropriate, because we didn’t go over the top with it (and it is a rapid-development, incremental project).  The diagram above also represents the minimum deployable version of the affiliate program for a given release.

We stopped short of creating the following diagram:

This diagram is more of a “classic” artifact that you would see in a BUFR (big, up-front requirements) project.  Our team collaborates regularly, and the affiliate program details were now relevant/timely.  We had the conversations, drew the diagram, confirmed (in about 10 minutes), took a picture, and shared it with the rest of the team.  There would have been marginal incremental value in making a pretty version of the diagram, so we didn’t do it.  Our goal is working software, not comprehensive documentation.

Conclusion

Just do what you need to do, then move on.  For our team, clarifying the intent was important.  Creating a formal, pretty picture added no extra value.  So we didn’t do it.

Business rules are often hidden in processes as hidden decisions.  Once you discover that hidden decision, how do you communicate the impact of exposing and managing the decision?

Hidden Decision

In our previous article on hidden business rules and enterprise decision management, we looked at a process that had a hidden decision.

First, take a look at the process with the decision still hidden:

Here’s the process (with the decision exposed) from that article:

The decision that was hidden was an implicit decision – “Pick One?” – for which the answer was always “No.”  After making this discovery, and communicating with your team, you then have to decide if you are going to make the decision explicit.  Making the decision explicit will involve defining the business rules for how to make the decision, and (if done in software) implementing the decision, or the ability for a person to make the decision.

Impact of a Decision

The diagrams above allude to the fact that there is money to be made in the process, in the “Continue Automated Process” step.  We need to provide a better understanding of how / when money is made.  A slight expansion of the process flow above (replacing the “Continue Automated Process” with a couple steps, looks like the following:

[click for larger version]

The last step introduces a real-world decision: “Sell products?” and only when the answer is yes does the process “Earn Revenue.”

If you’re analytically minded, you can apply percentages to each branch of each decision, and add everything up to figure out an answer.  That might be reasonable for a simple example like this one, but it can become too complex with a more complicated process.

There’s an easier way.  And since the goal is to communicate the impact to someone, you want an easier way.

Truth Tables and Decisions

A truth tables is a tried and true artifact for describing combined sets of decisions.  You can use it effectively to extract information from a decision-heavy process diagram.  Consider the following application of a truth table to the process above:

[larger version]

Each of the decisions in the process flow has a column.  Each row represents a unique path through the flow.  Each cell contains the result of the decision, for that path.  Note that when a path does not involve a decision, there is no value in the cell.

That provides a comprehensive view of the process, which you could build upon.  However, in this case, you are focusing on the impact of the hidden decision (“Pick One”).  The following paths, from the truth table, involve that decision:

[larger version]

Ignoring the other paths, and re-organizing, you find the following:

[larger version]

50% of the time, when “Many” results are found in the first decision in the process, if you pick one of the results, you will earn revenue.

[larger version]

When you do not pick one, 20% of the time, the customer (or user) abandons the process.  For the users that do not abandon the process, you earn revenue 50% of the time.  Taking both into account, you earn revenue only 40% of the time.

Adding Up the Impacts

When there are “Many” results from search, you can improve the performance of this part of your process by 20% – specifically, you increase revenue by 20%.  But only if you always “Pick One” of the many results. You can extend this analysis to determine the percentage of None/One/Many outputs from the search at the start of the process, and determine an overall impact on the process.  If search returned many results 10% of the time, you can increase revenue (overall) by 1% by always picking one of those results.  That gives you the business justification to calculate ROI on exposing the hidden decision.

The end result is that you have a simple way to communicate the impacts (truth table) in the language of stakeholders (ROI).

An effective status report is one that

• Instantly conveys the state of the project.
• Creates a minimum of overhead for the project team.
• Gets you help when you need it, and latitude when you don’t.
• Is fun / energizing to the author and the readers.

An effective status report is not a myth, it is actually easy to achieve.

Goals of a Status Report

You do not create a status report because someone told you to create them.  You create a status report only when it benefits the project.  There are three effective uses of a status report:

1. Get help (escalating) when you need help.
2. Keep stakeholders in the loop so there are no surprises.
3. Get visibility for the accomplishments of the people on your team.

Problems of a Status Report

There are also potential downsides of creating status reports.  This doesn’t mean you should avoid creating a status report.  It means you should avoid status report mistakes.

1. A bad status report takes a lot of energy (and time) to write, making it expensive.
2. A bad status report is difficult to read, causing it to fail to communicate.
3. A bad status report covers up problems or cries “Wolf!” when things are under control.

Elements of an Effective Status Report

The following is one example of an effective status report format.  Other formats can work.  This one does.  We’ve been using it for months on multiple projects, with great success.  On one of our projects, the first status report in this format was forwarded around by the project sponsor for people to “check this out!”  Ever hear of that happening to one of your status reports before?  In a good way?

There are five components in this status report format.

1. The scannable forecast.
2. Last week’s accomplishments.
3. This week’s planned accomplishments.
4. Issues and resolutions.
5. The legend.

The Legend

Normally, we run through a list in order.  In this case, we will show the last section first.  The legend explains how to read the first section, the scannable forecast.

You can define any number of different statuses for a project.  “Red, Yellow, Green” is the most common.  A couple years ago, we proposed this metaphor for status reporting:

A great way to do this is with a stoplight metaphor (at least in the US, where green = go, yellow = caution, red = stop). We can provide a little color in our reports to make the status details and rollup easy to scan. When someone is the audience of a status report, its because the reader needs to know what is going on, but isn’t involved – and likely is reading status reports from other teams. We need to present a document that gives a quick visual that guides the reader to pay attention to the most critical elements.

• Red. Immediate action (by the reader) is required to fix this.
• Yellow. We’re at risk of failing to meet expectations. There’s a plan in place, but we thought you should know. Want to know more?
• Green. Meeting or exceeding the plan. No need to spend cycles on this one.

[Update 28 Apr 2007: We have a much improved metaphor for tracking project status - weather forecasting.]

It works, but it isn’t great.  You’ve all seen it, because it is adequate.  However, using red, yellow, and green to provide a scannable status can be confusing – even if your readers aren’t colorblind.  Does red mean the project is delayed?  Yellow usually means a project is at risk.  But is it “at risk, help is needed” or “at risk, FYI, help is not needed.”  That’s part of why we recommended the weather forecasting metaphor.  Thanks again to Johanna Rothman for originally sharing the idea.

The Scannable Forecast

When you look at the above, even without knowing any details  you know:

1. The project is in worse shape this week than it was last week.
2. The project will get worse before it gets better.
3. The team has it under control, today, but might need help next week.

Last Week’s Accomplishments

The bulleted list is extremely effective for scannable details.  The secret – use three to five bullets.  More bullets means you’re sharing too much, and fewer than three is not enough.  You’re reporting to a project sponsor who has placed trust in you to manage the details.  Your sponsor, when things are sunny may not even read the details, just relying on you to say “everything is great.”  The only time that you need to share more details is when things are stormy.  And those details (1) will come up in the issues section, and (2) will come up in conversation.

When someone on your team does something noteworthy, dedicate one of your bullets to that accomplishment.  If you have a dozen of these, then refine your definition of noteworthy.  You should already be providing feedback to your team about their work.  Noteworthy accomplishments should be broadcast up the chain.  Its a reward for their hard work.  Don’t under-report, and don’t over-report.  The people who consistently do great things will begin to get a positive reputation where it counts.  As a bonus, you will get acknowledgment for being a good manager.

This Week’s Planned Accomplishments

This is what you intend to do in the next week.  When your project sponsor does want to get a little more insight, perhaps to make sure that she believes that you will resolve things, she will read these details.  Again – a three to five item bulleted list is appropriate.

Issues And Resolutions

You report issues when you are (or anticipate being) cloudy or stormy.  You don’t waste your sponsor’s time on trivial issues that you can resolve on your own.  These are issues that either definitely require escalation, or may require escalation.  Again, you’re working a three to five item list.  On your project, you will potentially manage ten times as many risks, and you could track them in a spreadsheet, etc.  Those are the issues you are working.  These are the issues you need help to resolve.  And only the issues you need help to resolve.

Note that this isn’t just an issues section – it is issues and resolutions.  When you inform a stakeholder that you need help with a problem, the first thing you need to do is propose a solution.  Imagine the following exchange:

“I need help” – “What do you need?” – “I need you to ….”

Much better than

“I need help” – “What do you need?” – “I don’t know.  I need help determining what I need.” – “I know what you need, you need help updating your resume.”

For every issue, propose a solution.

The issue section is also not meant to be a standalone document.  Here’s another bad exchange:

“I need help” – a couple days go by – “I solved your problem for you.  And I’m replacing you with someone I can rely on.”

Your project sponsor shouldn’t have to ask what you need her to do.  She should, however, want to know why you think the proposed solution is best – and you should talk to her about it, not present a rationale within your status report.

Practical Experience

I’ve created many status reports using this format.  They take anywhere from 15 minutes to 45 minutes, almost always under 30 minutes.  When they did take any significant time, almost all of that time was spent in thinking about the content to report in the “Planned Accomplishments” section.  And that is not time that I spent writing a status report – it is time I spent planning, on those occasions where I procrastinated in my planning, and the writing of the status report triggered a brief planning exercise.

Brevity in a report goes a long way.  As does regular face-to-face (or at least phone-to-phone) conversation.  A status report alone better not be the only way you communicate.  It should be a light-weight artifact that (1) starts the important conversations, (2) preempts the time-wasting conversations, and (3) provides an archive that you can review later, to see the full arc of the project, gain insights, and run your next project even more effectively.

Having trouble working through complex concepts?  Struggling to get a “simple” message across?  As human beings, we are all pre-wired to absorb visual communication.  You should take advantage of that to give yourself an edge when it comes to communicating.

Thinking in Pictures

Guy Kawasaki did an interview last week with Dan Roam, author of The Back of the Napkin: Solving Problems and Selling Ideas with Pictures.  There are eleven good questions with detailed answers, so it is definitely worth a read.

Whenever we hear a pitch or evaluate an idea, we go back to first principles and try and understand why something might work.  If we believe the explanation of why something might work, we’re much more open to the possibility that it will work.  Here’s part of Dan’s answer to Guy’s question about how and why using visuals to communicate can be effective.

Recent breakthroughs in vision science have indicated that there are multiple “vision pathways” along which the signals from our eyes travel into and through our brains. Each pathway keys off different visual cues in the environment–one pathway looking to identify the objects around us, another understanding where they are, another determining how many there are, another watching for changes over time, etc. This process takes place in parallel, breaking the entire visual world down into discrete elements that we initially process independently, and then only later “see” in our mind’s eye as a whole.

Dan Roam, interviewed by Guy Kawasaki

The basic idea is that we can perceive solutions to abstract and complex problems visually.  Visualization becomes a compelling vehicle for communication too.

Visceral Examples

Instead of writing a long string of words to describe the power of communicating visually, we’ll give you a couple examples.

One of Guy’s ventures is a company called Alltop, the goal of which is to find the valuable search results and present them to you.  Alltop is acknowledging a weakness in the search results created by algorithms – whatever the ranking mechanism, it is imperfect.  Alltop’s goal is to eliminate the pain of wading through useless search results to find the “nuggets” of useful results.  Does that explain the idea sufficiently?  What if you looked at this picture, from Guy’s recent blog article, showing a drawing by Dan of the concept described in this paragraph.

There’s a company called Slydial that allows you to make calls directly to someone’s voicemail.  A few minutes of poking around their website will give you an idea of what they do.  If you also read the FAQ and watch the videos, you can infer how it works too.  Or you can just look at the following drawing:

[click for larger version] * Note – depending on your age, the weird boxes are either obviously reel-to-reel recorders, or they are apparently happy robots that are excited to record your message for you.

Instead of calling someone in hopes of leaving them a message (because you don’t want to talk to them), you call Slydial, tell them the number you want to reach, and record a message.  Slydial then calls the voicemail of the person and replays your message directly into their voicemail.  In some cases, the person’s cell phone will even show a “missed call” from your number.

Whiteboards Rock

I’ve been heard to utter the phrase “I can’t think without a whiteboard.”  Whiteboards make for great visualization tools.  In my presentation at ProductCamp Austin, after a quick sojurn through my meager slide deck, we switched to the whiteboard.  With me at the whiteboard, the entire room was able to create an example Ishikawa diagram, first exploring an example problem with a concept map, and then building the associated ishikawa diagram.  The combination of collaborative teaching and visual expression and learning was very effective.

There’s an entire industry, now, built around electronic whiteboards.  Ten years ago, I was at a client using a copyboard – a whiteboard that would rotate the screen (like those old cloth-reel towels in restrooms) and a scanner built into the side of the whiteboard would copy what you had drawn, printing out a black and white copy of your diagram on thermal paper (the kind that used to be in fax machines, and that curls up after printing).  Five years ago, I was able to use an electronic whiteboard that detected the location of (and color of) the markers you were using.  It would detect when you were pressing down to write, triangulate the position of the pen, and create a digital copy on your connected computer.  Now those devices can be used interactively too – you can use a projector, pointed at the whiteboard, share the drawing real-time with remote viewers, and probably any number of other uses.

This matters, because you want a way to capture and share the drawings you create.  If you manage your information and communication well, it’s like slingbox + tivo for whiteboards.  View them any time, anywhere.  If you’re a product manager or business analyst, this gives you an easy way to embed drawings and diagrams within the traditional requirements artifacts.  Electronic copies of the drawings can be incorporated where they are needed most – leveraging context and providing clarity for your readers.  They dramatically help you when writing for an audience that does not have the context you have when creating the document.

Data Visualization

This is yet another incredibly valuable area of study – visual presentation of data.  Networks, connections, values, trends, everything can be visualized.  Check out this article from Smashing Magazine if you want to open pandora’s box into the current cutting edge(s) of data visualization.  If you’re a data-geek or a visualization-geek, my apologies.  This article will suck you into a black hole of great visualization ideas from which you may never recover.

Requirements Visualization

The only reason for documenting requirements is to communicate those requirements.  You can do it with text, or you can do it with analytically-saturated text, combined with gripping and clarifying visuals.  Make sure you have the following visualization techniques in your communication toolbox.

• Structured Requirements (or including interaction design) – this simple approach (and diagram) puts everything into perspective, from business goals to detailed specifications and to test plans and implementation.
• 
• Ishikawa Diagrams – demonstrate the cause-and-effect relationships that articulate why something is important to your stakeholders.
• 
• Class Diagrams – an explicit and expressive way to describe the business domain, providing context for your requirements.
• 
• Process Flows – there are many ways to do describe processes, from simple flow charts and sequence diagrams to BPMN process models (24-article tutorial & free visio template).
• and and
• Use Case Diagrams – no, not the UML use case diagrams, they are next to useless.  These are simple sketches that make a complex use case crystal clear.
• 
• State Transition Charts – show how objects can change their state over time (an order is placed, then paid, then filled or cancelled)
• 

What are your favorites (and why)?

The Cause and Effect diagram is also known as a fish bone diagram, because it resembles the skeleton of a fish. Using a cause and effect diagram can be the most effective way to define the problems that you intend to solve with your product. Get your stakeholders engaged in your program with this compelling visual!

Getting To The Root Of The Problem

In our recent article about writing good problem statements, we pointed out a common mistake people make with problem statements – they confuse the manifestation of a problem with a problem.

Problem manifestation [noun] – an example of a way in which a problem is exhibited, without appreciating the true nature of the problem. Ex: The problem manifestation is that the tires on my car are under-inflated. The problem is that my car is too expensive to maintain.

This distinction is relevant. The cost of operating the car is too high. That is the problem. It happens to be that one reason that the cost is too high is under-inflated tires. If you focus your energy on getting properly inflated tires, it will help (by improving fuel economy a little, and by reducing the frequency of tire replacement) with costs anecdotally. But you will not have solved the problem that costs are too high. Unless you get lucky. Costs can be high because the engine is inefficient or damaged, the aerodynamics of the car are bad, or any of a number of reasons. If you solve the problem by addressing a single manifestation of the problem, without understanding the whole problem, it is only because of luck.

Your Problem Statement is The Problem

In the comments on that article, The Demon points out that it is not always easy to identify the right level of abstraction for your problem. The cause and effect diagram makes it brilliantly simple not only to get to the root of the problem, but to communicate this cause-and-effect hierarchy of problem decomposition.

Cause And Effect Diagram Example

The cause and effect diagram is so visceral that the easiest way to communicate how it works is to show an example. Here’s what the cause and effect diagram would look like for the example problem above, where the cost of operating the car is too high.

[larger image]

The main problem is that the cost of operation is too high. This is the far-right, or fish-head part of the diagram (it is sometimes called a fish bone diagram).

The problem can be decomposed into three separate problems: spending too much on fuel, maintenance, and payments. Each of those problems can be further decomposed. Note that “under-inflated tires” appears twice – once as a cause of low miles per gallon (MPG) and once as an excess maintenance cost.

Alternately, you could recognize that spending too much on fuel could be due to lower fuel economy or excessively high prices. You could then choose to decompose the problem slightly differently:

[larger image]

Either approach results in crystal clarity that under-inflated tires is one root cause of low fuel economy, which is one cause of excessive spending on fuel, which is one cause of excessive operating costs. This visual approach helps significantly when trying to identify the right level of abstraction for expressing the problems in your problem statement.

Problem Abstraction Is A Side Benefit

The really cool part is that the help you get in finding the right level of abstraction for your problem is just icing on the cake. [Ed: No jokes about fish-bone cake. Ick!]

The real benefit comes in communicating and validating the problem decomposition with your stakeholders.

Someone questioned me once on the value of writing passionate requirements. Show one of these to your team, and you’ll get enthusiastic, passionate responses. You’ll get kudos from the business for demonstrating that you understand their needs. You’ll get praise from the implementation team for providing them with context.

Using Visio To Create A Cause And Effect Diagram

Creating a cause and effect diagram in Microsoft Visio is really easy, there’s a built in template, and it’s a good one. Create a new drawing and select the “Cause and Effect Diagram Shapes” template (under “Business Process”):

Visio will create a new drawing with a blank cause and effect diagram set up for you:

Fill in the boxes with the large problems. To get to the next level of detail (such as “Fuel Economy is Too low” in the last example), select the “Primary Cause” shape and drag it onto the diagram. Attach the arrowhead to one of the branches (the fish “ribs”) and start typing. For once, Visio’s default layout is where you want it.

To get a secondary cause shape (such as “Bad Aerodynamics” in the last example), select the “Secondary Cause” shape and drag it onto the diagram. Attach the arrowhead to the “primary cause” arrow you just created.

Conclusion

You already have a good justification for defining problems at the right level of abstraction. Now you know how to easily create a cause and effect diagram to find the right problem definition. As a bonus, communicating with stakeholders just got a lot easier – include this in your BRD.

When companies first start off-shoring, they usually send the “low level” implementation work overseas first, to work out the process kinks and manage risk. Over time, your valued, domain-aware developers will perceive a lack of career opportunities with this limited role. Naturally, you will want to consider sending design work offshore too. You can make it work. If you do it wrong, you’re toast.

Different Models for Offshore Development

There are many ways to organize software-creation teams (where creation includes product management, design, development and testing). When developing an organizational design that incorporates elements of off-shoring, there are four primary models for outsourced software creation.

1. No offshore development at all. Occasionally referred to as insourcing, this is the traditional “everyone in one place” model – or at least “everyone in similar time zones.”
2. Low-level outsourcing. The implementation teams (both coding and testing) are located offshore, with design and product management staying local.
3. High-level outsourcing. The focus of this article. Keeping product management “local” but moving design and development responsibilities offshore.
4. Complete technical outsourcing. Everyone except the product manager is offshore.

The models can be most easily compared when the same process is compared in each – just with different locations. Co-location of team members has an impact when comparing face-to-face communication with online / phone / remote communication. But this factor is not a primary one in influencing team-decisions – it is no different than having someone who works from home. The key element in team dynamics is a dramatic shift in timezones.

This timezone shift causes a latency in the communication process, illustrated by the following example:

Imagine the following expensive question and answer session:

• Person A asks person B a question.
• 12 hours later, person B responds with a request for a clarification.
• 12 hours later, Person A clarifies the question.
• 12 hours later, Person B responds with an answer.
• 12 hours later, Person A acknowledges the answer.

When this communication channel happens between an onshore person and an offshore person, it takes 48 hours instead of 48 minutes. The more this happens, the more expensive it is to outsource. The key to making low-level outsourcing work cost effectively is to minimize the impact of this communication latency, while realizing the benefits of lower salaries in the offshore location.

Making Offshore Development Work

This is why proper communication design is the make-or-break element of making collaborative teams work when using an outsourcing model that involves anyone being offshore.

High-Level Outsourcing

Consider the following software development process diagram (from Four Application Development Outsourcing Models):

In this off-shoring process flow diagram, the shaded areas represent the activities that happen offshore. Note that this is the exact same process flow that is used to describe the other outsourcing models. The difference from other models is primarily where resources are located, but also the relevant scope of responsibility. In comparison with low-level outsourcing, the only difference in the process flow is that responsibility for test design and solution design is transitioned to the offshore development team.

Artificial Boundary

This model creates a bit of an artificial boundary between the “interpret requirement” step and the “design solution” and “design tests” steps. This artificial boundary creates a potentially odd dynamic within the team.

To make reading easier, we’ll talk about the development side of the process flow only, but the same ideas apply on the testing side.

This model has one developer interpreting requirements, and a different developer doing the design work. In an insourcing model, those two developers are usually the same person. In large development teams, a common breakout here is architect versus senior designer. The architect (the figure on top) would be responsible for those design considerations that span the enterprise and the senior designer would be responsible for those design considerations that affect a single application. Here’s a good background article by Scott Ambler on approaching enterprise architecture.

Why have an artificial boundary? Because this model is an emergent design.

1. A company starts with low-level outsourcing.
2. The offshore developers complain about a lack of growth opportunities (both career and skill).
3. Executives are not prepared to completely outsource all technical work (risk aversion), or the team is not ready to succeed with that approach.

Splitting the “interpret requirements” task from the “design a solution” task is a compromise. It minimizes the risk associated with providing growth opportunities to offshore team members. That risk is minimized by avoiding the high-latency communication channel (from onshore to offshore) when communicating requirements. Instead, the interpretation of the requirements is done onshore, and that interpretation is communicated.

You can argue that this model is the offspring of a trust issue within the organization. A company can absolutely say “We want growth opportunities for our offshore team members” and at the same time say “We are not ready to relinquish complete technical control.” This is definitely a trust issue, and therefore a perceived risk mitigation strategy. The risk may be very real, or non-existent. In either case, it is emotionally present.

Vague Scope and Role Conflict

If, while reading this, the notion of splitting interpretation from design feels uncomfortable, that’s because it is. For many teams that are evolving their outsourcing model, it feels uncomfortable, but it feels less uncomfortable than releasing complete technical control.

One problem, which I completely grok as a former developer, is that it is almost impossible to interpret requirements without imagining designs. But this model has different people performing the different tasks. So should the interpreter just discard those designs? Presumably the interpreter is more experienced, certainly more knowledgeable about the domain. It would be a shame to discard those design insights.

Robbing Peter to Pay Paul

This approach has clear benefits for the offshore developers who are now presented with growth opportunities. Unfortunately, you run the risk of sucking the fun out of the role of the interpreter – a senior, experienced developer with domain knowledge. While proper requirements interpretation can be fun, it usually is not fun for a developer. Only requirements people will enjoy those nuances, generally.

You risk eliminating a career path and growth opportunities for your onshore resources with this model.

Division of Labor

One approach that keeps the growth opportunities open for your senior onshore technical resources is to have them play multi-product, or architectural roles. This presents an opportunity for these individuals to apply organizational insights across products, finding synergies between applications and driving consistency and consolidation among applications. You essentially split the responsibilities “broad and deep” where the onshore designer is looking across the portfolio and the offshore designer has ownership responsibilities for a single application or scope. This is similar to the division of responsibilities that works well for tackling enterprise product management.

Instead of preventing communication of requirements across the high-latency channel, it minimizes it. The onshore designer acts as the liaison between multiple offshore designers, fielding interpretation questions, and more effectively, preventing them. Developers have a language all their own. Through a shared perspective on common experiences, they can communicate very efficiently – by analogy, symbolically, and via design patterns. These communication opportunities (between like-minded individuals) can have very high information density. For example, one developer can say “MVC pattern” to another, and that serves more effectively to communicate an approach to designing a solution (and a context / interpretation of requirements) far more efficiently than a product manager describing requirements that multiple tools and platforms should expose the same set of capabilities or behaviors [and that is overly short, because I don't feel like typing a comprehensive explanation of the MVC pattern].

Another approach is to silo the developers vertically – having some applications (or modules) following a low-level outsourcing model, and others practicing complete technical outsourcing. Any given team is operating discretely with a clearly defined set of responsibilities. The teams may just be operating differently. Essentially, you’re saying that your “average” is high level outsourcing, even though it is really a mix of two models. This doesn’t really count, since none of your teams are addressing the communication challenges of this model – your company is leapfrogging over it, but choosing to mitigate risk by doing it a little bit at a time.

You can also take the approach of having the onshore designer be responsible for over-arching and high-complexity design issues, with offshore designers owning more straightforward and lower risk design activities.

The best approach for maximizing your team’s effectiveness (and your HR goals) will be overwhelmingly determined by the individuals involved. If you’re in a large company, you probably don’t get to maximize team effectiveness – you are likely to be forced into a particular model. If you’re doing the forcing, recognize that one size does not fit all.

High Latency Communication And Designing

When circling back to the main challenge of offshoring – communication – you need to look at the nature of the communication that is subject to the high-latency of temporal displacement within the team. The key to making this model work is to leverage the efficiency of cross-talk between developers. That means having experienced people on both the offshore and onshore teams who share common design backgrounds (patterns, analogies, examples) and deep domain understanding (reducing the provision and clarification of context across the communication channel).

Design reviews are also very effective at eliminating the impact of this latency on communication. Design reviews typically happen as follows:

1. Designer A spends time creating design based on an interpretation of requirements.
2. Designers A & B get together and review the design in a relatively short meeting (or Designer B reviews a design document). Feedback is delivered in a burst.
3. Designer A spends time updating the design based on feedback from step 2.
4. Return to step 2 as many times as is needed.

There is a big chunk of work involved in incorporating feedback from a design review. This can be folded into the “white space” between communications. In other words, while designer B is sleeping for the night, designer A is making updates. This looks like, but is not the follow-the-sun pattern.

The follow-the-sun pattern is one where someone is always working. I’ve made this work on a project where there were two teams working 12 hour shifts with a 4 hour overlap (and a 4 hour “blackout”). Note – that isn’t sustainable, just anecdotal. I think the linked article is right, commonly, follow-the-sun implementation does not work, for the reasons cited in that article.

What makes this very different is that we are synchronizing the naturally-occurring time lag between design reviews with the geographically-induced time lag in communication.

Conclusion

The strategy for successfully utilizing offshore resources for both implementation and design starts and ends with communication. It also requires attention to your specific people and their career aspirations.

• Utilize design reviews to take advantage of serendipitous time-lags in the communication cycle.
• Assure that your role definitions are clear, and aligned with the aspirations of the people on your team.
• Follow the tips for effective offshore development – this strategy builds on that one, it does not replace it.

Economic pressures are driving most companies in high-developer-salary markets to explore using offshore development teams as part of their approach to developing software. Developing software with a global team presents new challenges as well as new benefits. If you do it right, you can have a more cost-effective team. If you do it wrong, you can have a disaster.

Different Models for Offshore Development

There are essentially four different models for managing a software development team, with respect to onshore and offshore roles.

1. No offshore development, also known as insourcing.
2. Low-level outsourcing, having the implementation (but not design) team members offshore.
3. High-level outsourcing, having the implementation and design team members offshore.
4. Complete technical outsourcing, having all technical implementation team members offshore.

Each different model has the same set of people involved in the process, with the same channels of communication. The differences are in which communications happen across geographic and temporal boundaries, and which communications happen in the same time zone.

For this article, we are focusing specifically on low-level outsourcing, where the communication channel most affected by different timezones is the one between design and implementation.

Low-Level Outsourcing

Consider the following software development process diagram (from Four Application Development Outsourcing Models):

Each area surrounded by a dashed line represents a different type of work, or a different required dominant skill set. Every stage in the development process requires a different set of dominant skills, and all areas share a set of common skills. When exploring different offshoring models, teams are most effective when they identify the distinctions in dominant skill set requirements, and divide responsibilities along those boundaries. When you create an artificial (or arbitrary) boundary within one of the regions in the diagram, you create opportunities for misunderstanding. With those misunderstandings, you can have people redundantly working on the same thing, or even worse, you can have tasks that don’t get accomplished. You also introduce the possibility of discord within your team as people either proclaim “that’s my job” or “that’s not my job.” You can split a team within the areas shown above (and we’ll talk about that in a future article), but it is harder to do successfully.

Low level outsourcing is an approach where the implementation team members who write the code and tests are offshore. The requirements work is done onshore (where salaries are expensive). Interpretation of the requirements is also done onshore. The design of the testing plan is done onshore, and the design of the solution is also done onshore. The creation of tests and the implementation of the code is done offshore.

In the diagram above, testing of requirements happens on the left, and testing of the implementation happens implicitly on the right. If you haven’t been reading Tyner Blain for a couple years, that may not make much sense. Testing of requirements and implementation are different, and you need to do both.

Testing: Isolation of Variables Reduces Costs

Testing is something that can be approached from a few different perspectives, and the word “testing” means different things to different people. In this process flow, we are focusing on two main areas of testing – testing the requirements and testing the implementation. When you test the requirements, you are asking the question “does this solution do what the product manager intended?” When you test the implementation, you are asking the question “does my solution behave as designer intended?” This is a nuanced difference, and non-technical people may say “what is the difference?” The designer intends exactly the same thing that the product manager intends.

If you think back to your high school science class, you’ll remember the concept of “control of experiments.” This is the field of practical application of logic to scientific experimentation. By taking a logically rigorous approach to designing a science experiment, you can isolate variables, and test each of them independently. This prevents you from drawing false conclusions from your data. The same process leads you to test both the requirements and the implementation. If you’ve ever submitted a bug and had the implementation team close it out with the statement “working as designed”, you already know the benefit of testing both. Just because something is designed to do X does not mean it is not supposed to do Y. By introducing a designer between the product manager and the testing, you introduce the possibility that the designer is the source of the bug – by misinterpreting the requirements.

It is possible to “test” the design and then test the implementation – this will isolate the design from the implementation. Unfortunately, the only way to “test” a design (without also testing the implementation) is conceptually, with a thought experiment. And that’s exactly what the designer does as part of designing. No one else is really going to understand the design well enough to do that. And if the designer is doing the thought-testing, there is no way to isolate if the designer misinterpreted the requirements in the first place. That same misinterpretation will influence his testing in the same way that it influenced his design (See error source E3 in Where Bugs Come From for more details). This is critical to designing, but it does not work for testing a design.

It is possible to test just the requirements. You create tests based solely on the documented requirements. You run those tests against the implemented solution. When the test passes, every step in the process worked. These are known as black-box tests, because you can run the tests without any insight into how the software is written (it is a “black box”). The problem comes when a test fails – you know something is wrong, but you have to do (expensive) research to figure out the source of the problem. It could be that the implementation failed to do what was designed. Or it could be that the software design failed to meet the objectives of the requirements. There is a way to reduce the cost of this analysis – by testing both the requirements and the implementation.

You can easily test the implementation. An implementation test, commonly known as a white-box test, and usually implemented as a unit-test, inspects the effectiveness of a particular implementation at doing what the designer intended. When you combine implementation testing with requirements testing, you isolate the designer variable. If a requirements test fails but the implementation tests pass, the problem is with the design (or with the design of the test). When both requirements and implementation tests fail, you know that at least the implementation is wrong.

In the diagram above, the testing on the left side represents testing of requirements. The right side of the diagram implicitly includes testing of the implementation as part of implementing. You need to ingrain your implementation testing into your development philosophy. Would you deliver code without compiling it? Why, as a developer, would you consider delivering it without testing it? Compilation is not just a build step, it is also an implicit test of compilability. You should also include the implicit test of “does what I intended it to do.”

Combining the discipline of continuous integration with test driven development is the most effective way to accomplish this. Note: remember this part, as it is a critical component to making low-level offshore development work. Without this, you may as well give up – you certainly aren’t going to be more cost-effective.

Communication Across Time And Space

The key to making offshoring effective, as with any development process, is to make the communication work. For communication that happens between people in the same location (or at least roughly the same time zone), the problems and solutions are no different than when you have an insourcing model. What’s different is the communication that happens between members of the onshore team and the offshore team. This communication is not just remote (technology helps us solve these problems with instant messaging, phone calls, and other real-time (or near-real-time) techniques), but also phase-shifted in time. When you have team members working while other team members are sleeping, you slow down the collaborative process. You introduce a near-crippling latency into the communication channel.

Imagine the following expensive question and answer session:

• Person A asks person B a question.
• 12 hours later, person B responds with a request for a clarification.
• 12 hours later, Person A clarifies the question.
• 12 hours later, Person B responds with an answer.
• 12 hours later, Person A acknowledges the answer.

When this communication channel happens between an onshore person and an offshore person, it takes 48 hours instead of 48 minutes. The more this happens, the more expensive it is to outsource. The key to making low-level outsourcing work cost effectively is to minimize the impact of this communication latency, while realizing the benefits of lower salaries in the offshore location.

Communications On Which To Focus

The “happy path” communication channels (shown with blue arrows in the diagram) are the transfer from “test design” to test, and from “implementation design” to implementation. You have to communicate the designs in such a way as to minimize misinterpretation of the design. Never prevent needed communication. Your goal is NOT to stop communication, but to preempt it by eliminating the need. The only thing worse than taking too long because you have a lot of communication is failing to communicate enough. Your goal is NOT to prevent communication, but to minimize the need for it.

The “trust but verify” communication involves making sure that the implementation meets the design. In (requirements) testing, it means reviewing that the tests exhaustively cover everything identified in the test design. It also means reviewing that each test (implementation) actually (effectively) tests what it is designed to test. As team members demonstrate their capabilities, they require less oversight – which is true of any mentoring relationship. In implementation, it means verifying that the code does what the design requires. You could read the code and make a determination, but that is a manual inspection of the code, and manual inspections have been shown to be at best 80% effective as a testing method. What you need to do is create a unit test suite, run it continuously, and only allow developers to check-in their code (to the trunk) when the entire suite passes. Then all you have to do is review the test suite to assure that it will test the design effectively. It wouldn’t hurt to also run the test suite locally (onshore) as a verification, but fundamentally, you are trusting that your developers will follow this continuous integration process.

You are using testing and test design as a mechanism to validate effective communication. You can think of it as a form of active listening. When you (or more appropriately, your design document) says “X”, you can review the test design to confirm that your listener designed tests that assure “X” will happen. Do not just rely on informal communication and acknowledgement. Cross-cultural communication introduces a lot of complexity and misinterpretation. People who do not share a common language or culture also tend to interpret symbols very differently, and will rarely have the same connotations for given interpretable words.

Definition of tests and validation of testing is important beyond the immediate communication of design. There are also the feedback loops that come from the “unhappy path” when something goes wrong (and a bug is introduced). Each of these “where was the bug introduced, and how do we fix it?” cycles is also affected by the latency of cross-shore communication. Good testing reduces the number of these otherwise unwarranted communication cycles.

Developing good design docs is also critical to the success of this communication. The definition of “good” for a design doc is so dependent on the exact circumstances that it is impractical to try and define what that is (at least within this article). A design doc needs to be written with the reader in mind, not the author. Beyond that, we won’t try and make any statements of truth.

Conclusion

The strategy to successful utilization of offshore resources for development and test implementation work starts with communication. The strategy also ends with communication.

• Create artifacts (good design docs) that minimize the clarification cycle across the onshore-offshore time boundary.
• Review implementation tests as an active-listening mechanism to confirm that communication of design intent was effective.
• Practice continuous integration (both as an offshore developer and as an onshore designer or development manager) to assure that your solution stays true to the design and the requirements.

And, as always, have great people – because people trump process.

A rose by any other name…

When we’re learning how to write in high school and college, we’re taught that synonyms make our writing more exciting. In fact, not using synonyms can make our prose clumsy and awkward.

When it comes to requirements, the last thing you want to do is use synonyms. Except sometimes.

Writing Stylish Requirements

One of the lesser appreciated rules of writing good requirements is to write requirements with good style.

Your writing style needs to take into account the fact that not all of the readers of your requirements will have English (or whatever language you write in) as their primary language. The readers may have as a primary language one that does not have the same idioms, constructs, and “common” terms as the language of the requirements. Those readers are already at a disadvantage, having to reverse-engineer colloquialisms, decode complex sentence structures, and look up the definitions of terms that they don’t know.

Even readers who share a common language [Great joke from Eddie Izzard: "Britain and America are two countries separated by a common language"] probably will not share the same idioms and colloquialisms.

Writing clearly and unambiguously requires that you use more formal language when writing requirements. Synonyms may make for better style when writing prose, however, they can confound your readers and increase the risk of misunderstanding when used in requirements documents

Avoid Synonyms

Synonyms introduce ambiguity into your requirements. Consider the following examples:

• The user will have added items to her shopping cart while browsing the website. When she is ready to purchase the items in her cart, she will click on the “cart” icon. All of the items in the basket must be priced with the most recent pricing rules.

Are you pricing the items in the basket, the cart, or the shopping cart? That may seem obvious to you, since most of us are familiar with the shopping cart metaphor in e-commerce transactions. What about the following?

• A round bit must not rotate within the head when the vice is adequately tightened.
• The vice will be tightened with a key measuring no more less than two inches in diameter.
• A moment of 10 inch-lbs applied to the chuck will be considered adequate for tightening.

If you don’t know that chuck and key are synonyms, you’re in trouble. If you don’t realize that the vice and the head can also be considered synonyms in this context, you are in more trouble. You should use the same terms throughout your requirements document, when referring to the same object or concept.

Except when you should use different terms for the same objects.

Embrace Synonyms

There are times, however, when synonyms can bring clarity to an otherwise confusing document. This effect is less powerful than introducing confusion, so when in doubt, don’t use synonyms.

Synonyms provide clarity when used in a particular context. If you sell cars, then you have a customer. Imagine you also provide financing (products) for your customers. In the context of negotiating a price for the car, the customer is a customer. In the context of negotiating an interest rate, the customer is also a borrower.

Validating the requirements for the lending process may be much easier when using the word “borrower” instead of “customer.” What you are striving for is clarity of language, and when interacting with stakeholders who have always used the term borrower, you can use that term in your documentation.

The key is to identify the synonym in the glossary of terms. You have to identify the synonym as being associated with both the equivalent term, and the context in which the synonym applies.

The customer at the car dealership can be the purchaser, the borrower, and the driver. It all depends on context. When you manage the synonyms within your glossary you can use the different terms. But you should only use them when they reduce ambiguity – not when they introduce it. Even with our example, the customer and the borrower might be different people – so make sure that the synonymous terms represent the same object, and not potentially different ones.

Separation of business rules from requirements is a good thing. Not because of semantic distinctions, but because it allows you to write better software, write it faster, and change it more easily. This article is a response to an excellent comment on our recent article about hidden business rules. Thanks for challenging the idea – it either eliminates it from discourse or makes it stronger, and we all benefit. Here’s an attempt to make it stronger.

Goals of Separating Rules from Requirements

Writing software ultimately involves coding up an implementation that both satisfies the goals of the customers and enforces the rules by which that customer chooses to achieve the goals. This is the traditional way to write software – define the goals, and all of the enhancing, constraining, and clarifying details, then implement it. There are some inefficiencies to this approach, but they are in the “getting great at writing software” bucket, not the “avoiding failure at writing software” bucket. Consider this the medium priority goal of separating rules from requirements. In a Kano analysis, this is a more-is-better benefit.

When we set out to write software, it is with intent. That intent encompasses processes, rules, and requirements. The combination of all of these could be described as a summation of intent.

Maintaining software is expensive. When you design an implementation, you (should) think about what is likely to change when making your design decisions. The greater the probability or frequency of change, the easier it should be to make those changes.

Intent changes. Agile processes start with a premise that even if the true intent were fixed, our understanding of intent would change, as soon as we get what we asked for. In practice, both our understanding of intent, and the actual intent change over time. To make the language less cumbersome, for the rest of this article, when I refer to intent it is our understanding of intent – and changes to intent represent both changes in the true intent, and changes in our understanding of it.

When developers think about software maintenance, they often think about it in terms of bugs and features. What needs to be fixed, and what needs to be added (or removed)? To make a significant impact on the cost of maintenance, we have to take that perspective to the next level. Set aside fixing bugs (where bugs are “does not work per the requirements”), and think about the new features. The new features truly represent new intent. Or in an agile process, it may be the recently revalidated, previously identified, next most valuable intent.

In both cases, intent is a moving target, and changes in intent drive changes to the existing software. To minimize the cost of making those changes, our implementation should be structured such that the most common changes are trivial to implement – ideally, they won’t even require changes to the code. When you can change the behavior of an application without recompiling the application, you significantly reduce the effort required to define,develop,test and deploy an update to the application. And you can also dramatically reduce the time required to make the change.

This is the high priority goal of separating rules from requirements: increase the speed, and decrease the cost of changing software to match changes in intent. I’ll say it again in bold.

The primary goal of separating rules from requirements is to increase the speed and decrease the cost of updating software to match changes in intent.

While the cost reduction part of it is nice, it is the speed element that can be the most compelling. James Taylor and Neil Raden wrote about this in their book, Smart Enough Systems. We accept the premise that abstracting the implementation of volatile rules from the rest of the software provides benefits in speed of delivery on an ongoing basis. And that is the primary driver for the separation of rules from requirements. If you don’t accept that premise, then the only benefit comes from improved documentation style, structure, and standardization – all somewhat subjective benefits.

Visualizing The Benefits

Here’s a timeline showing the benefit of agility – being able to deploy and update faster.

The maroon curve represents “traditional” deployment – where the implementation of volatile rules is no different than the implementation required to support requirements. It will take longer to deploy initially (but not necessarily much longer), and it will take longer to make changes (when the rules have been changed). The upward sloping line starts displaying accumulated value as soon as the software is released. When the next iteration is released, the rate of value accumulation will go up. There is one iteration displayed in the timeline.

The green curve represents deployment with volatile rules abstracted in the implementation. This could be as low-tech as implementing field-level validations in a properties file (that is interpreted by the application), or as high-tech as integration with a rules-processing engine or service. This implementation begins accumulating value a little bit earlier, but at the same rate (keeping prioritization and other factors equivalent). The first iteration happens more quickly, so the slope of the curve increases earlier. The length of iteration has been shortened enough that a second iteration can also happen. This further increases the relative rate of accumulation of value. The longer this pattern goes on, the greater the disparity.

Encouraging This Behavior

Abstracting the rules from the requirements will make it easier for developers to absorb and design for those rules. Further, once the rules have been separated from the requirements, it is easier to identify which rules are the volatile rules. And that enables developers to make smart decisions about when to abstract the implementation, and when to embed it.

You could abstract only the volatile rules from the requirements, and leave other rules embedded within the requirements. There are three good reasons for separating all of the rules from the requirements.

The first reason is one of consistency of documentation, and arguably style. Your communication will be more effective when consumers of the documents know that all rules are treated in the same way. If developers have to look in the requirements for some rules, and a table of rules for others, they are more likely to miss something. Subject matter experts who are validating the rules will also be able to do that job more effectively when they are documented similarly.

The second reason is that by separating all of the rules, you will better be able to identify the ones that are volatile. You can more easily evaluate the rules as a whole, and formally or informally characterize their frequency and likelihood of change. The rules for management of available products and the calculation of risk in a portfolio are likely to change frequently. The rules that represent FAA regulations are likely to change infrequently. You can better assess this data when dealing with a cohesive set of rules.

The third reason is that separation of the rules will imply to developers that they should at least consider separation of the implementation. Especially if, in your documentation approach, you identify which rules are volatile.

Conclusion

There are differences in rules and requirements. While the content of how they are used when developing software may be only semantic, there are practical benefits to separating them. Separation of rules and requirements in a documentation approach will make it easier for your development team to implement solutions that separate volatile rules from the rest of the code.

And this separation will make the software more valuable, more quickly.

Measuring the return on investments in design may be the hardest ROI calculation you can do. It certainly is one of the rarest. To measure ROI, you have to be able to determine what would happen without the investment, and what happens with the investment. The difference between them is what happened because of the investment.

Fast Company Interview

Bill Breen posted an interview with Rob Wallace on the Fast Company blog about proving the value of design. The start of Bill’s article lets us know that measuring the ROI of design (ROD) is so rare that it may be impossible or impractical to do. He points to a Whirlpool survey of 15 design-focused companies – most of whom were “clueless” about the return on their design investments.

Rob explains that the reason for measuring the ROI of design investments is that ROI is the language of executives. “If you can’t measure it you can’t manage it. Businesspeople operate in a world of numbers.” Simply put, if you want to make someone invest in design, you have to show them why they should invest in design. One way to get a company to invest in design is to convince the benevolent dictator in charge of the product (or company) of the subjective merits of having good design. Apple is a great example of a company with a leader who is passionate about design. And you can argue that the Zune (from Microsoft) has had meager success against Apple’s iPod due to shortcomings in design. But can you objectively argue the point?

Argument by Extension

After Rob mentions that there is a dearth of measurement of design ROI, Bill challenges Rob’s premise – why should we expect that there is an ROI for design? Rob cites a series of studies done on Fortune 500 companies:

On average, based on two dozen case studies with Fortune 500 companies, for every dollar invested in advertising, packaging and promotion, and visual communication at the point of sale, companies realized a $7.21 ROI. But when the advertising didn’t change (or there was no advertising)—and packaging design was the only thing that did change—there was a $15.17 average ROI on every dollar invested.

Based on this data, Rob argues, it is easy to extend that if packaging (design) changes can yield ROI, then so to will product design changes.

Insights from Adaptive Path

Peter Merholz, President and founding partner of Adaptive Path wrote on communicating the value of design in Aug. 2002. In his article, based on a breakout session, the AIGA’s 5th Advance for Design Summit, he shares a series of internal benefits that they found to be more significant (or at least more measurable) than external benefits.

As we continued listing the value of our user experience design work, a more intriguing realization emerged — the bulk of our value comes from the efficiency that we can create in a company’s operations.

Some of the areas they identified are:

• Smarter Product Development Processes
• Lowered Maintenance Costs
• Less Internal Documentation
• Maximized IT Investments
• Scalability

Our Concerns

One challenge for each of these sources of ROI is that you can’t truly isolate the benefits – you would never have two teams design products for the same market, with differing levels of design investment, with a resultant analysis of project costs. Even if you did, you wouldn’t be able to isolate the impact that the team members had. You have to look at historical data, which introduces enough variables to question the validity of any quantitative conclusion.

Further, we will show that each of these is either a weak proposition, or potentially very false one.

Smarter Product Development Processes. No one has concretely identified a design-centric, purely agile, or structured requirements approach as being the best one. At least where best is defined as most profitable. Even the debate between Alan Cooper and Kent Beck highlighted more “stylistic differences” than quantified differences. There are elements of genius in each approach. Incorporating the needs of users is key to an effective design. Incremental delivery and incorporation of feedback is incredibly efficient. Tracing decisions, designs and requirements to the ultimate goals for the software is key to building the right software. If there is a “perfect process”, it is one that incorporates elements from all three disciplines. And as such – there is value to incorporating design into the process. We can’t quantify it, but we are convinced that it is there. And based on the economics of when software problems are fixed, we believe that investments in design early in the cycle will yield positive returns.

Lowered Maintenance Costs. There are a couple ways this benefit might be inferred. First, better design yields easier to maintain code. This is primarily a premise of agile development (where the design decisions are what Cooper calls program design), but perhaps the benefits also apply to interface design. Often, good interfaces simplify the complexity of, or at least obscure the means of implementation. Those interfaces are not necessarily easier to maintain. One reason complexity leaks through to users in a lot of software is that it is easier to code it that way. This value-prop probably doesn’t hold water.

Less Internal Documentation. The better the design of the interface, the less you need to teach someone how to use it. There is definitely potential for reduced external documentation, or producing the same amount of documentation may cost less, as it is easier to understand the product. It isn’t clear how internal documentation needs can be reduced by good design. Except perhaps that a picture is worth a thousand words. But a great picture may take as long to draw as it does to write a thousand words.

Maximized IT Investments. This is simply self-referential. Maximizing investments yields higher ROI. But in what way?

Scalability. Better design, from a user perspective does not imply that software will be more scalable. And often in an implementation, when user-tasks are simplified (by automating steps in the process), those decisions don’t disappear. By removing the burden from the users, you often add it to the software. However, Peter may have been talking about scalability of the team – the ability to leverage design investments across products (sharing branding, metaphors and workflow paradigms). In other words, design re-use. In that case, there is definitely a benefit, but re-usable design, while cheaper than green field design, is more expensive than no design.

Support Costs. One external benefit that Peter does identify is the reduced burden for training and support. Many software companies actually have profitable businesses built on support and training. Unfortunately, reducing the demand for those would reduce the profitability along that dimension.

Where We See Value

Fundamentally, we don’t perceive design investments as being significant cost reductions – we see them as significant revenue enhancers. Better design yields increased usage, more efficient usage, increased satisfaction, and increased word of mouth marketing.

Increased Usage. ROI forecasts are often built upon estimations (or suppositions) of levels of user adoption. As an example, consider the “Buy it now” button on eBay auctions. When people click on the “Buy it now” button, the auction is closed, and the transaction occurs at a fixed price. People are more likely to sell an auctioned item (generating a commission) by encouraging an impulse shopper. The seller risks getting less than they otherwise would, in exchange for the buyer knowing that they can get the item they want. Fewer auctions will expire unexecuted. More commissions are generated for eBay. Comparisons of final selling prices (and commissions to eBay) of equivalent items with and without the button can be done to measure the return.

More Efficient Usage. Better designs make it easier for users to do what they want to do. Easier often equates to faster. A call-center application that simplifies data access for the operator will allow them to process calls more quickly. The employer ends up with higher throughput from the call center. This throughput can be used to reduce costs, or increase customer satisfaction (with reduced “time per call” stats, or better experiences for the callers), or some of each. Comparing the results of operators using the new system versus the old system will yield measurable data.

Peter mentioned reduced training costs – and we see that as an external benefit that comes from accelerating a user’s growth from new user to proficient or even expert user. Bridging the canyon of pain to get to higher usage rates and more efficient usage faster. This also leads to increased satisfaction by creating more satisfied users more quickly.

Increased Satisfaction. Customer or user satisfaction surveys may be the only way to approximate (not really measuring) this benefit. And it isn’t clear that X% increase in satisfaction leads to Y% increase in sales. But it is likely to lead to increased sales, and may also lead to increases in sales of other products by the same company. Apple leverages this affect across its family of synergistic products. Perhaps a Bayesian analysis of survey results and sales stats could identify the strength of a correlation between satisfaction and sales. That would be expensive to do, but would lead to quantified estimates of the return.

Ultimately, you raise the utility of the software for the user. By increasing the value to the user, you increase their satisfaction, and thereby increase the likelihood that they will encourage other people to buy and use your products.

Increased Word of Mouth Marketing. When your customers become your sales people, you get more sales than you would have without those recommendations. Perhaps comparisons of growth curves for products with varying degrees of customer satisfaction (or varying degrees of “free publicity” – like reviews, blog articles, etc) would yield some predictive insight. Web 2.0 successes have been predominantly built on word-of-mouth. And their growth curves are exponential (as would be the propogation of good words from satisfied mouths). Does anyone know of analyses that validate this?

Conclusion

Design investments yield benefits. The way to measure those benefits is still up for debate. Some folks believe the benefits are primarily internal – we believe that the benefits are external

But sometimes, it happens anyway.

The Cranky PM started a great thread of conversation asking how product managers deal with the job of telling customers (and sales folks) that a feature is not going to be available in the promised release.

CPMs Question

1) What’s your favorite PM breakdancing move for telling (or avoiding telling) an important customer that his favorite feature is not planned for any of the next 3 releases?

2) What about for telling the same thing to a sales droid who claims a multi-gazillion dollar deal is going down the toilet because you don’t have Feature X?

Cranky PM, in Share Your Secret Moves

Several Answers

The readers of that article really stepped up with nine responses. Check out CPM’s article for the details – but here is a summary of the answers. Some of these are bad ideas, and some are good. Usually, the bad ones were written as “I used to…” Our thoughts about each are also included in the list.

• [Bad] Wait until the last minute, then deliver the bad news. We agree – about the only way to lose credibility faster would be to not admit the feature was missing until after the release, when the customer calls to ask.
• [Good] Tell the customer that the scope and priorities have been updated, as soon as the decision has been made. This builds on, or at least sustains a cooperative trust-based relationship.
• [Other] When a customer has multiple features slated for a release, ask them to prioritize them, and try and include them in priority order. This should be happening anyway, before finalizing the schedule – but if it hasn’t already happened, it definitely should happen when the realization occurs.
• [Other] Think outside the box – outsource to get the to-be-missed features included anyway. Deal with the integration hassles internally. This can be good or bad, depending on both your team and the partner.
• [Bad] Re-characterize the release as a “get the basics in place” release, explaining that the to-be-missed features need to come after the basics. There is some validity to the logic behind this (that you can’t really know what you need in detail until you start using the application). But to suddenly discover this after having already committed to a schedule is not good.
• [Good] Restructure the release schedule and add a “next” release to include the to-be-missed features. This is one of the tactics we identify when over-filling a time box.
• [Good] Don’t make promises you aren’t sure you can keep. This is a preventative solution – set expectations appropriately, don’t make promises of content until you near the release. If you’re using iterative development, for example, you might be creating a build every month. You may only be releasing once a quarter to your customer. If you are using continuous integration, and testing effectively, you know you can avoid regression bugs – so you know you can release all of the features from the previous interim builds. Let the customer know that those features have been completed. You’re reducing (perceived) risk for the customer – only the last (and ideally, lowest value) features are still undecided.
• [Funny] If the feature is for sales bigwigs, you’re fired. If the sales person has less clout, make them follow procedure (justify the business value and document it, etc…).
• [Good] Challenge the premise that a sale is dependent upon feature X. Push back on or work with the sales folks to identify the true requirements – not the proposed solution. From what I’ve seen of enterprise software, sales are made based on relationships, not features – and not even price.
• [Other] Distract the customer by emphasizing all of the stuff that is important to them that will be in the release. Softens the blow. Done well, this can really work. If you are implementing the most important stuff (to the market) first, the odds are that it is also the most important to this customer. And by the reverse, the better aligned this customer is to your market, the less effort you are spending on “one-off” customizations. So this redirection technique, when you’re doing everything else right, could also be classified as “put it in perspective for the customer.” When you do that – this is definitely good. If, on the other hand, your priorities are messed up, this can be a bad thing.
• [Bad] Make the excuse that the feature slipped because of “security enhancements” (or other ’sounds more important’) taking priority at the last minute. If this is true, then this is just an example of ‘more important stuff is slipping’ – if it is false, it is lying. Again – the ‘rabbit out of a hat’ thing should not happen in a positive relationship. Maybe this is an ethical gray area for some folks, but we choose not to take this approach.
• [Good] Share the product road map regularly with customers. Use the road map as an artifact to set delivery expectations. That practice is a good one, and is effective in working with sales droids. It doesn’t help with to-be-missed features, however.
• [Good] De-value the feature request and focus on the benefit request. Another good one for the feature-X request. Work with sales to identify the reason why behind the feature. Then incorporate a solution into the product plan.

Really some great answers. How do we mix these into a recipe for success?

Success Recipe

Unfortunately, fire-fighting seems to get more attention than fire-prevention. We tend to get rewarded more for fixing problems than preventing them. This of course leads us to get better at extinguishing fires than avoiding them. But a good software product success strategy is built on fire-prevention, with some contingency plans.

Do the following to prevent problems:

• Prioritize goals (aka needs or problems) based on market value. This is the strategic, multi-customer view of your product.
• Communicate release schedules based on the use cases that enable your customers to achieve those goals. Note that you may be scheduling improving versions of the same use case.
• Share that schedule with your customers. Since you should be continuously refining this plan, you should also be continuously sharing it. Use this road map in discussions with sales folks.
• Make sure that the release dates are not arbitrary. If you’re releasing regularly (monthly, for example) – this is less of an issue.
• Establish expectations that your sales-support activities are market-focused, multi-customer activities.
• When a sales person approaches you with feature X, work to uncover problem X and then assess and prioritize it for the market relative to everything else. There are limits to how quickly you can include it in the development schedule without being disruptive. If you need to be disruptive, make sure it is justified.

And when you do have to slip something from the current release:

• Let the customer(s) who are really dependent upon it know as soon as you suspect.
• Keep them appraised as you make progress (or lose ground). Think of the status report you might give to your manager about a project’s status. Well, you really work for the customers, right? Let them know.
• Put things in context. When you slip something, it better be the lowest priority item. And if your customer’s individual needs are aligned with the overall market needs, this is easier to deal with. When the customer does not represent the market, you have to determine what expenses you are willing to absorb to service the customer. Not every sale is a good one – especially if one customer detracts from your ability to sell to multiple customers, or pulls you away from your strategy.

Another form of slippage is when you re-prioritize future features. Now you’re saying “here are the changes to the roadmap.” The same tell people right away, focus on strategic value, and put things in context ideas still work the best here.

Jonathan Babcock has written a couple interesting articles on preparing for a review meeting. He touches on a couple generic “good ideas” and explores one critical idea in more detail. We focus on that detail – helping participants be prepared to participate – in this article. His articles, and this topic in general are useful to anyone who runs meetings that require participation from attendees – business analysts, product managers, and project managers, for example.

Meeting Planning Articles

We’ve created a bundle of articles at nexus about how to plan and run effective meetings. The bundle includes both of Jonathan’s articles, as well as one of our own on making meetings more effective and a Business Week article on how Google runs meetings.

The bundle is open for collaboration, so other nexus users may add other articles on the topic. You don’t have to be a registered user at nexus to read the articles, so click on over and check them out. Then take a couple minutes to register and rate or review the articles – because the seconds you spend vetting these articles will save others minutes when they are researching in the future.

Summarizing the Main Prep-Points

Jonathan’s main prep points include

• Distributing the material early enough for participants to review and provide feedback
• Circulating an agenda in advance
• Reserve the meeting room & equipment
• Request confirmation of attendance or delegation where appropriate

The other articles include the following prep points

• Defining the goals and deliverables of the meeting up front to set expectations
• Assigning a note-taker or scribe for the meeting

Unprepared Participants

Jonathan raises an interesting issue – when, in spite of your prep work, people fail to prepare for the meeting, what should you do? This is a tough one. If you start with the assumption that only people who need to be in the meeting are actually invited to the meeting, this issue becomes critically important. In many organizations, too many people attend meetings. They are certainly wasting their own time, and often end up wasting everyone’s time. If you are culturally obligated to invite superfluous people to the meetings, that’s unfortunate, but don’t worry about making sure they are prepared. Focus on the people who need to be there and be prepared.

Jonathan writes his advice specifically for requirements specification review meetings – where people’s input is critically important. The issues and advice apply to any of a number of collaborative or approval meetings. They can be generally described as meetings where multiple people need the information, should provide input, and ultimately must agree on the outcome of the meeting.

Don’t Do This

Sometimes you, and everyone else in the meeting needs to take the efficiency hit of dragging along the folks who didn’t do their homework. If you have to, you have to. After the meeting, talk privately with the person who let everyone down, and work together to prevent it from happening in the future.

Don’t attack the person publicly in the meeting. Don’t slam your notebook closed and declare the meeting to be over because someone had something more important to do. That would be just as unprofessional as it was to discover that people were unprepared for the meeting. Maybe that person did have something more important to do. The problem truly isn’t that they were unprepared, the problem is that you didn’t know about it in advance, and couldn’t respond appropriately.

That’s the crux of the issue, and the reason that Jonathan’s advice is good.

Do This Instead

Touch base with the attendees before the meeting. Make sure that everyone who needs to be prepared is prepared. If someone needs to bring materials, make sure they have them ready to go. Work with them to get them completed if you need to. Reschedule the meeting if you need to. Carry on with the meeting, and deal with the missing contributions if that is what is appropriate. You can’t do everyone’s job for them – but you can do your job for everyone. The meeting attendees are implicitly relying upon you to not waste their time. And since it is your meeting, if someone you are relying upon is failing to deliver, it is your responsibility to adapt.

Jonathan offers a couple suggestions to get attendees to prepare for the meeting. His first suggestion is to get their inputs so that you can incorporate them into the agenda. This is a good approach, because it helps attendees develop a sense of ownership in the agenda. Even if they don’t modify the agenda, they are taking some ownership in what you have put together by acknowledging and accepting it.

Jonathan also suggests letting attendees know that you will cancel or reschedule the meeting if you don’t have their inputs a day or two in advance of the meeting. We would approach this with a slightly lighter touch, but we like the base idea. When there are inputs that would crater the meeting if they were absent, work with the contributors to assure that they will have those inputs ready. If they can’t get them done in time, work with them to reschedule the meeting (before the meeting begins) so that you can carry out the meeting with their inputs.

Often, meetings get derailed when people who are “too busy” are simply not conversant with the material to be covered. They don’t have the background they need, or a deep enough understanding to be effective in the meeting. The classic example is a decision maker who needs to know the context for making decisions. When everyone else in the meeting has the context, you’re wasting their time getting the decision maker up to speed during the meeting. Work with that attendee to find a time to help them review before the meeting, or reschedule the meeting, or ask them not to attend it at all. If you have a one hour meeting with seven people, you’re wasting six hours (across the team) by going over the material again to get the laggard up to speed. Wouldn’t it be better to spend two hours in a one-on-one with that person before the group gets together?

To quote Jonathan:

Worst of all, whether it’s completely fair or not, the productivity of a Business Analyst’s meetings are seen as a direct reflection on the his/her organizational and interpersonal skills.

Other Approaches

Craig Brown offers a couple tips in the comments on Jonathan’s second article. He suggests meeting with the leaders in advance of the meeting, and also providing them with printed versions of the materials before the meeting. Craig suggests letting the leaders know that you will collect their “marked up” versions of the documents [before] the meeting. I’ve seen this be very effective with upper managers and decision makers. There’s something about marking up a print-out that engages these folks.

Maybe they are less comfortable with electronic documents (although that is becoming less true every day, and varies from company to company). I suspect that marking up a paper copy allows someone to “scan” more effectively, cross-reference with other documents, and put things in context better. Often the “decision makers” are in a unique position of having fewer details and more context. Giving them an alternative medium for reviewing the docs may help them to put things in perspective more effectively.

What approaches would you suggest?

The material in the presentation is off-topic, but the presentation is so good that you just have to watch it. I found this when researching about openID (mine is http://tynerblain.com/scott.sehlhorst/ – check out myOpenID to set up yours). Consider the open ID thing to be a tangent you might be interested in pursuing today, and will be interested in pursuing soon.

Regardless, you should watch this presentation. The delivery will knock your socks off. The topic is interesting, or perhaps not interesting at all – but delivered so well that you’ll be interested.

This is your third link to it. Last chance.

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 acknowledgment 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.

What is Active Listening?

McGraw-Hill’s accurate yet insufficient definition of active listening is “Giving undivided attention to a speaker in a genuine effort to understand the speaker’s point of view.” That’s fine, but it doesn’t tell you why you give undivided attention, and it doesn’t tell you how. And active listening is much more that paying attention really well. That implies a one-directional communication. Active listening is bidirectional. This definition doesn’t tell you what you’re giving to the speaker and that’s the most important part.

Why Practice Active Listening Skills?

There are plenty of generic reasons to be an active listener. Dale Carnegie swears that active listening is the key to making a great first impression (he’s right). Dr. John Gray promises to improve your cross-gender relationships with active listening that gets to the heart of the unimaginable motivations of the opposite sex [tongue in cheek].

As a business analyst or product manager, you have some very specific goals and challenges. Joy at Seilevel recently wrote about the challenge of convincing people that documenting requirements is important. She looks at the motivation of the naysayers, and recognizes that the reasons may not be logical, or they may not have the data. This is a great example of the kinds of situations, beyond gathering requirements, where active listening skills can help.

The Center for Rural Studies [yeah, I know, it is odd] provides a great list of ten active listening skills. We’re re-purposing that list here to

• Make you more successful.
• Make your products better.
• Make your customers happier.

Ten Active Listening Skills

1. Acknowledging. You send cues to the speaker that acknowledge that you are hearing them. You have to demonstrate that you understand the ideas. Make eye contact and dilate your pupils, raise your eyebrows, nod your head. This is more than just acknowledging that you here the words (and be aware of different cues in different cultures). You have to acknowledge the ideas to be effective. When you don’t understand something, you can make the “I don’t get it” face.
2. Restating. The best way to overcome missed signals in the non-verbal attends that represent acknowledgment is by restating what you just heard. The key to restatement is not reiteration, but paraphrasing. You demonstrate that you’ve absorbed a concept by rewording it. If you missed a key concept, your reworded restatement should make it obvious to the speaker that you missed the idea. In an ideal world, she will be practicing active listening skills too – and will restate your restatement, providing another means for you to grasp the idea.
3. Reflecting. Imitation is the most sincere form of flattery. Subliminal imitation is sort of what reflecting does. You pick up on the body language and emotions of the speaker, and reflect them back at her. Several “how to get ahead” management books will tell you to emulate your boss. This is because we are all pre-wired for a little bit of xenophobia. We tend to like people who are “like us.” More importantly – by demonstrating that you are developing the same reactions as the speaker, you are affirming that you have reached the same understanding.
4. Interpreting. Ah, the psychiatrist’s trick. “I see from your uncontrollable twitch that this has upset you. Tell me why…” This is generally focused on being empathetic, and encouraging people to talk more. However, this is also where you can ask for clarifications, to make sure you understand what your speaker means. “Are you saying you need ‘drag and drop’ because you need an easy to use interface, or because people will be using a tablet pc with no keyboard?
5. Summarizing. When you ask a good open ended question, you will get a relatively long response. When applying active listening skills to requirements gathering, you often want to let your speaker go off-topic a little bit, as it helps identify other requirements. Make notes of those other topics for followup, then summarize the parts of the answer that addressed your initial question. You’re reinforcing for the speaker that you understood why they said what they said, and that you didn’t muddy the waters with the other information they gave you.
6. Probing. People often summarize in order to communicate effectively. Developers will use design patterns to allow them to describe detailed software implementations in a word or two. People in general will use symbols as replacements for compound ideas. Ask a clarifying question or two to assure the speaker (and yourself) that you understood what they intended you to understand. This can also help you with credibility with the speaker, as it demonstrates some knowledge of or comfort in their domain.
7. Giving Feedback. By sharing your opinions about particular ideas, you create a collaborative bond with the speaker. You should focus on affirmation of their insights or ideas, instead of criticisms. If you tell someone that their question is stupid, you encourage them to shut down and shut up. Listen to speakers or panelists in a Q&A session – they regularly start their answer with “That’s a great question.” The really good ones will say “That’s a great question, because…” Without the because, the feedback can start to sound like a pre-programmed platitude. Quickly snap off half a dozen “Great Question. Here’s my answer.” answers without the rationalization, and people will tune it out as noise. If you’re struggling for responses, use anecdotes. “That’s a great question, I had a client who never asked it – and here’s how the disaster unfolded…”
8. Supporting. Validation of the speaker’s ideas and concerns is important. By supporting their worries as being valid, and ultimately resolving those worries, you create loyal customers. Dell recently launched their Idea Storm website to elicit exactly this kind of feedback (among others). If they add their voices to the mix, providing support for the ideas that people present, they will get more and better ideas. If they follow-up, they can demonstrate a clear cause-and-effect for their customers. “You said it. We did it.” That would generate some loyalty!
9. Checking Perceptions. When you’re actively listening to someone, in addition to getting data, you are forming impressions and perceptions. You need to check the validity of those perceptions with the speaker. When gathering requirements, this often leads to identification of the true requirements, and even implicit requirements. You’re also letting the speaker know that you “get it.” This is a great opportunity to double up on the supporting and feedback active listening skills with responses like “I think that is a great requirement, because it will prevent incorrect orders from being shipped, and that will reduce field-servicing costs. Or was there a different benefit you had in mind?”
10. Being Quiet. Interviewers use this technique all the time. Silence can make people uncomfortable, so they tend to fill the void – the only way they can, by talking more. While this is effective for confrontational interviews, there are more positive and enabling reason to do be quite. First, you need to temper your exuberance to provide feedback, support and summaries, so that you appear to be listening and not talking. You’re meeting with someone so that you can understand their perspective – not so that they can understand yours. Second, you want to give people time to think. If you are creating a “take all the time you need,” positive, supporting silence, they will use that time effectively. The attends and emotional affirmations you’re providing are what make it supporting and not interrogative.
11. [Bonus] Extension. This is a variation on the restating technique. Many people you interview will be providing you with data from a discrete perspective. When gathering requirements, you have to find a way to abstract that information into market requirements. People also often talk in terms of their existing tools and processes. You may be getting great information, but it may be overwhelmed in implementation details, either about how they do their job, or how they envision the future system to be. A great way to validate that you’re generalizing the salient parts of their ideas is to extend the ideas. “I need to be able to sort the accounts receivable list by name, even though Joan sorts them by outstanding amount” can be combined with other requirements and extended to “Each user shall be able to organize outputs by field in the UI.” And you just discovered that Joan is a stakeholder who uses the same functionality for a completely different purpose.

Conclusion

Active listening skills are critical to communication, and more importantly, collaboration. Requirements gathering – for product managers AND business analysts, is the essence of collaboration. It isn’t input only. Use your active listening skills to make the conversation bi-directional, and you will get better information. You’ll also have better products, and happier customers.

The first step of gathering requirements is to identify who can give you the requirements. Business processes include communication between different people inside the organization. Communication also includes people outside the organization. When gathering requirements, it can be easy to overlook the people who don’t use the software directly. Those people may still be stakeholders. Read on to see how to approach stakeholder analysis.

Requirements Models

One of the things that differentiates Seilevel at requirements gathering is their application of different requirements models to solve specific elicitation problems. Joy recently posted an article about onion diagrams, a tool for visualizing the stakeholders of a system. At the accidental business analyst, Ryan provides a concrete example of using an onion diagram to visualize an insurance system.

Thanks Ryan and Joy for the great articles!

The Onion Diagram

The onion diagram is named because of the way it presents a view of a system (or product). It presents the layers of interaction with the system using concentric circles. The innermost circle is the system, and around that circle are the users of that system. Additional layers are added to describe the organization and its ecosystem.

The System

This is a very simple diagram. In our example, BugBGone is developing software to manage their business. This diagram provides a visualization of the users of the system. It is sufficient for identifying the use cases of the system. However, we risk creating incomplete requirements, or overlooking business rules.

The Organization

[larger image]

This larger view represents the organization as a whole (the next layer in the onion). The service technician is an important stakeholder of the system, even if he does not interact with it. This view provides a compelling way to visualize that there are people in the organization that get benefit from the system, even if they are not users.

The innermost circle represents the system, the next circle captures all of the users of the system. The outer circle captures all of the other employees within the organization who rely upon the system.

The Wider Environment

[larger image]

This larger diagram shows that there are stakeholders outside of the organization. In BugBGone’s case, there are several stakeholders outside of the organization:

• A regulatory agency provides MSDS (material safety data sheets) on the pesticides, and has compliance rules surrounding documentation and handling of substances.
• Suppliers need to receive orders for pesticides, invoice BugBGone, and receive payments for shipments.
• Customers need to schedule treatments, and receive and pay invoices.
• An accountant takes care of payroll, taxes, and other accounting needs for BugBGone (they’ve outsourced).

Visualizing Interactions

The diagram above shows the stakeholders. It is clean and easy to review. What makes this a powerful tool for a business analyst (or product manager) is that you can overlay the interactions between the stakeholders onto this diagram.

[larger image]

In this view, it is easy to visualize that there is reliance on the regulatory agency, and interactions between different stakeholders in the system. For example, it is easy to see how a service technician communicates with the administrator to get his schedules. The manager and the owner both interact with the accountant.

This view provides a great way to assure completeness of the requirements.

Conclusion

Analysis of a business, or software system is hard. It can appear to be easy, but the challenge is in discovering what you don’t realize you need to do. Different models provide different views of the company or system – making it easier to discover what needs to be done.

Communication is easy. Effective communication is hard. Models like the onion diagram allow for very targeted communication of often complex ideas.