A couple weeks ago, our article on writing design-free requirements triggered some great discussion around requirements and design (also known as “reqs and specs”).  What happens when you’re dealing with a website?  There are many stakeholders, who are clear about their own goals.  Who then turns them into requirements?

A Website Requirements Scenario

Consider the following situation.  Your company has a website, and through that website you sell hats- it is an eCommerce haberdashery.  You have at least three stakeholders that are important in this scenario:

• Customers (or prospective customers) who interact with the website and purchase products from your company.
• A Merchandiser who is responsible for the content (images and text) that is presented on your website, designed to sell products to customers.
• A product manager who is responsible for sales of a line of products, including through your website.
• A host of others, including SEO experts (responsible for getting traffic to the website), user experience teams responsible for how customers interact with the site, and implementation teams responsible for building different elements (such as the CMS or the customer-data master or the product catalog).

The Customer

The customer has a straightforward requirement: having a great shopping experience while getting great deals on the perfect products.  This is an infinitely deep area for discussion, but to keep this article short(er), the focus will be on the internal players at your haberdashery.

The Product Manager

The product manager is responsible for his product line.  In this scenario, he makes high-end, retro-styled hats.  The two most important products are the bowler hat and the top hat.  The product manager is responsible for the profitability of this retro-chic hat line.  The bowler hat sells for $175 with a $75 profit margin, and the top hat sells for $250 with a $125 profit margin.  The product manager has a strategic requirement.  We’ll use a user story to describe his requirement.

• As a product manager, I need to increase the profits for my retro-chic hats product line, which already dominates the market, so that our stock price will rise.

This requirement is too ambiguous and abstract to be actionable.  The product manager can’t really give this to anyone else.  What he can do is create an Ishikawa diagram that helps him identify the components of product line profitability, so that he can choose one to focus on.  Our haberdashed product manager decides (for this example) that the strategic lever he wants to pull is to change the product mix.  He feels that growing the total number of hats sold is not a good strategy – his market is saturated.

Instead, his goal is to convince his customers to buy more top hats – at the expense of buying fewer bowler hats.  Each customer who switches from the bowler to the top hat will generate an additional $50 in profit.  He further needs to make sure that he doesn’t lose sales to customers who really wouldn’t be happy with anything but a bowler hat.  Being measurable is also important.  To meet his performance objectives, the product manager realizes he needs to shift the mix from 50/50 to 60/40 (60 of every 100 retro-chic hats sold need to be top hats).  His requirement can be rewritten.

• As the retro-chic hats product manager, I need to increase the percentage of top hats sold to 60%, without reducing the total number of hat sales, so that I can increase the profitability of my product line.

OK, that’s measurable.  Whatever someone does, you’ll know if it succeeded.  But is it actionable?  No – it is still ambiguous.

The Merchandiser

The merchandiser is responsible for finding the best photos, writing the best ad-copy, and determining the marketing messages that are displayed to customers on the website.  The merchandiser is held accountable for conversion – the percentage of visitors who come to the site, view the content, and ultimately decide to purchase.  Since your company is not dis-functional, the merchandiser has aligned her goals with the product manager.

• As the retro-chic hats merchandiser, I need to convince online customers who would have bought the bowler hat to buy the top hat instead, so that the percentage of top-hats sold is at least 60% of all retro-chic hats.

There’s an implicit choice here – a specification.  Here’s another user story that would achieve the same goal.

• As the retro-chic hats merchandiser, I need to increase the conversion rate for customers that view the top hat page from 2% to 3%, so that the percentage of top-hats sold is at least 60% of all retro-chic hats.

Since they are both actionable, but both very different, that works as a good litmus test that the product manager’s requirement, while measurable, was still ambiguous.

There could also be an SEO expert, for whom the story would be “…increase traffic to the top-hats page without decreasing conversion…”  A member of the the site design (or user experience) team, could try and improve conversion by creating a more efficient flow (like “one click ordering”) that increases conversion rates – but only enable it for the top hat product.

There are just too many cooks in the kitchen.  Every one wants to feed the hungry people, but each specializes in a different dish.

You have at least four viable ways to approach solving the product manager’s goal.  You need to pick one before you get the development team involved.

A Matter of Perspective

The merchandiser, SEO expert, and site design teams all have the same goal – support the product manager and achieve a 60/40 mix in retro-chic hat sales.  Each of them can develop a reasonable requirement, within their own domain.

To a man with a hammer, every job looks like a nail.  The merchandiser is not going to focus on purchase-path redesigns, nor is the SEO expert going to suggest changing from a boring photo of a manikin to a photo of an attractive man laughing with friends over an expensive meal.

The product manager, however, should not be telling the cooks how to make the stew.  The product manager (of the product being sold) is not responsible for, and should not be driving the decisions about how to achieve his 60/40 mix goal.  The product manager could think of the people in each area as vendors, “selling” alternate solutions to his problem.  Each solution has a cost, so the product manager probably can’t just “do them all.”  Unfortunately, the product manager is not qualified to pick the right vendor – only to evaluate the promised benefits (from each) at the projected costs (from each) and hope he chose wisely.

A Website Product Manager

The critical need to product managing your website is more visible than ever.  Without it, you won’t make good decisions about how to address your real business goals.  You need someone who understands the risks, trade-offs, and possibilities inherent in each of the four solution approaches.  If your website is large, you may have a portfolio manager for your website, with individual product managers owning areas of the site.

Recognize that not only are your (company’s) customers your customers – but so are your other stakeholders.  As a website, you create commerce, you don’t just sell products.  You have to help (external) customers have great shopping experiences, while helping (internal) customers meet their goals.

The website product manager works with the retro-chic product manager to understand his goal of achieving a 60/40 mix in sales.  Taking into account the big picture from a website perspective (who are our customers, who is the competition, what is our vision), the website product manager has to make a “design decision” and choose one of the solution approaches.

The website product manager is constraining the solution space by selecting one of the hammers.  Is this bad?  The retro-chic product manager constrained the solution space too (when deciding that a shift in mix was the “right” answer).

Then the how would we solve it, if constrained to solving it this way, user stories have to be developed and given to the implementation team.

Conclusion

You need to have someone acting as a product manager for your website.  That person is in the ideal position to constrain the solution approaches to addressing any given stakeholder.  Those constraints do limit your options – so you better have a good product manager.  It really is no different, however than saying you better have a good general manager, so that the strategy you are supporting is a good one.

What are your interactions like with the folks that own your website?  Or are you already a website product manager?

SEO, Search Engine Optimization, is an area that every online website needs to think about.  The idea is that the more traffic you can get to your website, the more products you’ll sell.  Just because you can lead a horse to water doesn’t mean you can make him drink.  What a great opportunity to product manage your website and ask why about SEO.

SEO

When you’re building a website, you have four primary channels by which you get traffic (visitors) to your site:

1. Direct Traffic – people who type in the URL (address) of a page on your website directly into their browser.
2. Referral Traffic – people who are sent to a URL on your website from another website (usually by clicking on a link).
3. Paid Search Traffic – people who click on an advertisement that you run (on other websites) to reach a URL on your site.
4. Organic Search Traffic – people who use a search engine (like Bing or Google) to try and find an answer to a question, who then click on a link to a URL on your website within the search engine results.

[Note that the graph above combines #3 and #4 into one channel of traffic, as the source of about 1/3 of the traffic for this website.]

Search Engine Optimization, or SEO, is collectively the set of activities you do to increase (”optimize”) the amount of traffic you get from organic search (#4 above).  SEO has at best a second-order effect on the other three channels from which you may get traffic – they are effectively unaffected by your SEO activities.

There are entire companies, in fact an entire industry, built to help companies increase the traffic they get from “organic” search.  It is called “organic” search based on the premise that search engine algorithms will determine (through their own proprietary algorithms) the “best” results for any given search.  Like nature, this can be influenced by you, but is out of your control – hence “organic.”  This is in contrast to paid search, where you are directly controlling when someone comes to your site (by clicking on an advertisement that you paid for).

Since SEO is such a large topic, even though this is a longer article, it only scratches the surface.  This article focuses on the decision making you would do (and the measurements needed to support those decisions).  It does not attempt to be a one-stop-shop for all of your SEO needs.

SEO Has ROI (or Does It?)

People who promote their SEO services will tell you – build it, and they will come.  What you do with the traffic once it arrives is up to you – SEO just gets people to show up.  Makes for a good movie, but it doesn’t always work that way.  This is where product management can help.

You want the right people to show up, not just anyone.  In keeping with the baseball analogy, applied to the web: your website is the stadium.  The games are free.  Your SEO efforts get people to show up at the stadium.  But you’re not selling tickets.  The only way you make money is if people buy hot dogs or pennants or peanuts.  You have products for sale at the stadium and you want people who will buy them to show up.  You don’t get any value from just filling the seats.

If the people who show up don’t buy anything, it’s as worthless as if no one ever came in the first place.

I’ve worked with a client in the past who had a project that successfully increased the number of visitors to one of their websites by over 30% for several months, resulting in almost no change in the amount of products they sold during that period.  An SEO-only person would say “hey, the people showed up, I did my job,” but a product manager is acutely aware that this was an exercise in futility.

Perhaps the people who showed up had no intention of buying anything.  That would be consistent with the data my client collected.  Perhaps something intrinsic to the website prevented the new visitors from purchasing (while allowing a consistent percentage of the previous visitors to continue making purchases).  To the best of my knowledge, the data needed to perform that root cause analysis was not available.

When you’re product managing your website, you are responsible not only for getting people to your website, but also for getting them to convert their presence into purchases.

Measuring SEO – Easy Versus Important

The challenge in any measurement activity is determining what to measure.  There always seem to be a bunch of things that are easy to measure, and a handful of things that are important to measure.  When you’re lucky, there’s some overlap.  The challenge is to resist the urge to measure stuff just because it is easy – you’re making work for yourself – both in taking the measurements and in reviewing the measurements.

To select the right measurements for your website, you first have to understand your goals.  Assume that your goal is to sell products, profitably.  This is the driver for your “bottom line measurements” – at the end of the day, how is your product (website) performing?  If you aren’t measuring revenue and profits, you won’t know if you’ve filled your stadium with “empty chairs” who don’t buy any peanuts.

You also have to understand the buying processes that users (website visitors) use to make purchases from you.  One way to characterize the buying process is to look at the process from the perspective of the user, who goes through the following stages of activity:

1. Identify a need to solve a problem (possibly by purchasing a product).
2. Discover possible solutions to the identified problem (possibly products that solve the problem).
3. Compare solutions (products) and decide which to implement (purchase).
4. Solve the problem (purchase and use the product).
5. Re-evaluate the solution (product).

Step 2, discover possible solutions, is where SEO can help.  One way people can discover solutions (and there are many others) is by using a search engine to discover solutions.  Those people may search for phrases that describe their problem (”webcam not working with Skype”) or ask questions as if the search engine could solve their problem directly (”how do I make my webcam work with Skype?”).  Some people will determine (or assume) that the problem is with their webcam, and that they need a new one.  Those people will search for the solution they’ve already envisioned (”best webcam”), or combine steps 2 and 3, and search for comparison data (”webcam reviews”) or pricing data (”webcam deals”).

In addition to the goal-measurements (step 4), you’ll also want to include search-effectiveness measurements (step 2).  Keep in mind that there are other factors at play in your website – not every visitor who searches has a propensity to buy, visitors who arrive may abandon your site because they don’t like your pricing, etc.

Measuring SEO Effectiveness

Keep in mind that you’re trying to sell products (profitably), and this particular effort is focused on improving organic search as a mechanism by which you attract customers to which to sell products (profitably).  Your measurements should focus on these two aspects.  Here are some things that are interesting to measure [note: the screenshots below are of Tyner Blain traffic - I won't share any client data - so these values are low compared to a successful eCommerce site - but they are illustrative.]:

Organic Search Engine Traffic

• How many visitors come to your site from search engines (and from which search engines?)?
• 
• What are the keywords / phrases that visitors used to find your website?
• 
• To which pages did the search engines direct the most traffic?
• 
• What search terms sent traffic to which pages?
• 
• SERP Ranking (Search Engine Results Page Ranking) – How high up is your result for one of your targeted keywords?  Is it on the front page?
• 

All of those measures, while easy to do (the screenshots above are from the free Google Analytics program), only tell you about how many people came to your stadium, they don’t give you any insight into peanut sales.  You can use these measurements to provide feedback as you make changes in your SEO implementation – to determine if each change increases or reduces traffic (or fills seats).

You also need to know about the peanuts.

The specific financial measurements you make will depend on your strategy for how you engage your market.  Are you a discounter, trying to maximize sales in the short term, with a transactional focus?  Are you focused on the long term, building relationships, and maximizing the lifetime value of customers (better to sell more, later, than less, now)?  Are you trying to gain market share, or maximize profits in a mature market?  The specific ways you measure will vary, but some common measurements are:

• Conversion Percentage – how many of the people who come to your site end up purchasing (during that visit)?
• Number of Purchases – how many orders were placed?
• Average Order Value (AOV) – how much is each order “worth” in both revenue and profit?
• Lifetime Customer Value - how much is each customer “worth” in both revenue and profit?

The way you get real insights from these measurements is by combining them.  Utilize the “SEO mechanics” measurements (above the peanuts) to slice or segment the financial measurements.  Ask questions like “How many orders were placed by people who came to the site and landed on the webcam page?” or “What is the conversion percentage for people who came to the site by searching for best webcam?” or “How much revenue do we get from each keyword that sends organic traffic to our site?”

SEO Goals – Getting Actionable

Combining the results of the two forms of measurement (mechanics vs. revenue) will identify for you where you are getting the most value, and where you have the most opportunity to increase value.  You’ll have to do analyses of “do I make one thing (page, keyword, etc) better, or do I try and make all things better?”

One technique that can help you reach those decisions is by noticing that most of the metrics you see follow power law (long tail) curves.  Roughly speaking, 80% of your traffic will come from 20% of your keywords.  80% of your sales may be to 20% of your customers.  20% of your pages may generate 80% of your visits (or 80% of your revenue).  You’ll have to “do the math” for each project to estimate the impact of those projects – and determine if your best bet is to improve a single page (a lot), or make a change to your site that improves all of the pages (a little).

You may find that your website is not sufficiently instrumented to make the measurements you need.  My suggestion is to instrument your website first, and then try and improve it second.  If you can’t measure it, it didn’t happen.

The current “state of the industry” for SEO has a hint of product management influence in it already – there’s some awareness that these sorts of aggregate statistics are limited in their ability to give you insight about your customers.  Where SEO seems to be pushing today is in being able to segment the above data views against personas or market segments.  This looks to me like an industry that is maturing beyond the elastic user problem that software development and user experience teams have been addressing for years.  This approach will allow you to target your website development initiatives with an eye on the uniqueness of customers in different market segments.

SEO Product Management Conclusion

Search engine optimization is important.  Focusing your efforts to improve your business, as it relates to search engines, is what is really important – and search engine optimization is how you get there.  Discover the factors that have a bottom line impact, and then execute to address them.  Don’t just assume that more traffic is better traffic.

Design-Free requirements are important for two reasons, and hard for two other reasons.

Design-free requirements are hard because you “know what you want” when you should be documenting “why you want it.”  Writing design-free requirements can be hard when you don’t trust your development team to “do the right thing” even though it is not your job to design the solution.

Design-Free Requirements – Revisiting

It has been three years since I wrote Writing Design-Free Requirements as part of The Big Ten Rules of Writing Requirements.  In that time, agile development practices have moved from being an esoteric development methodology to being the topic on the tips of everyone’s tongues as executives and organizations try to either (1) get the benefits of the state of the art in software-development process or (2) do something shiny and fashionable.

The previous article centered on elements of designs within MRD, PRD, and SRS artifacts.  A regular alphabet soup of artifacts.  Honoring the values behind the agile manifesto encourages us to emphasize working software over comprehensive documentation.  In that light, we’ll take a “what is needed” approach to talking about how requirements, design, and implementation are all needed – rather than issue an edict about where that information should be captured.

Agile Development Inputs

When creating software, someone needs to know:

• What problems are being solved, and how important (valuable) they are to be solved.
• Who has the problems and who is using the software to (help) solve those problems.
• What constraints limit the space that defines the universe of possible viable solutions.
• What acceptance criteria define if the delivered solution will be acceptable.

Subject to those inputs, someone needs to make design decisions:

• User experience design - what interactions will a user of our solution love?
• Program design – how (in a nuts and bolts way) will our solution function?

When talking about agile and talking about design, we should take a look at how Kent Beck and Alan Cooper, as respective though leaders in each space, view this.

Cooper doesn’t talk much about creating the requirements to support the daily use scenarios – he proposes moving directly into design of the solution. This differs from the more traditional technique of writing functional requirements to support use cases. Cooper also breaks down design into two components – program design and interaction design. Program design is everything you don’t see. Interaction design is everything you do see.

[...]

Cooper argues that designing the interaction should happen before any code is written. He uses a construction analogy to drive home his perspective – you can’t pour the concrete before you build the forms. Kent Beck, founder of the XP programming philosophy disagrees with the premise. Beck believes that the cost of changing software is low, and the imagery Cooper uses is hyperbole. We touch on, and link to that debate in this post.

Interaction Design Process Overview

I don’t believe that Beck is arguing for “don’t do design” – I believe he is arguing for “don’t do big upfront design that would delay implementation.”  He’s championing the agile values that emphasize creating working software and responding to change.  I can imagine him saying “no one will buy a design, they want a solution.”  Cooper’s point is that create a solution without first understanding how someone will use it, you can’t create a great product.

Program design has many hidden impacts – cost of maintenance, cost to change, and the performance of the solution.  You can have a design (or architecture) that makes everything easier to do in the future – at the cost of delaying the delivery of anything.  Or you can have a design that minimizes the time to deliver the first thing, while increasing the cost to deliver any particular next thing.  Or you can design a solution that falls somewhere between those extremes.

If you say “we don’t do design” you’re lying.  Every solution includes design.  Your team’s design process may be “big and upfront” or it could be a couple sketches on a whiteboard, or some email exchanges.  You may create storyboards and wireframes.  Or design may be the thing that happens right before the programmer’s fingers strike the keys.  Design may be explicit or it may be implicit – but it never “doesn’t happen.”

In the movie Amadeus, Salieri is astounded that there are no rough drafts of Mozart’s compositions.  That’s because Mozart did the design in his head, not because he didn’t do design.  I’ve worked with programmers who’s “implicit designs” were great, but that is the exception, not the rule.

Who Owns Design?

Since design happens sometime before fingers strike the keyboard, the real question is – “who owns the design?”

• You have a product manager developing an understanding of market problems, and prioritizing the problems that should be solved with your product.
• You may have a product owner managing the backlog and clarifying those requirements (problems) for the development team.
• You may have an interface (or interaction) designer or team of designers who are broadly responsible for “how users interact with our products.”
• You may have an architect or lead engineer who is responsible for the “big picture design” of how your product works.
• You have developers and testers who are responsible for delivering your product. [Note: coding without testing is like typing code without compiling - maybe it works, but probably not.]

You may not have distinct individuals with each of these titles – every small team I’ve worked with has people wearing multiple hats.  This is especially true when you have an agile team full of specializing generalists – any given story (or task) may have a different architect and different implementer.  I’ve only worked with one company where the architects are NOT part of the development team.  If your team is set up that way, please comment below – I had never seen that before, and I’m not convinced that it is the best way to organize – what have your experiences been?

Generally, “program design” is clearly owned by the development team – and product managers (and product owners) know better than to specify program design in their requirements.  Neither the lead engineer nor the product manager believes that the product manager is a better programmer – so the product manager better not be specifying program design and mislabeling it as requirements.  Coincidentally, Steve Johnson, at Pragmatic Marketing has a post running right now with a bit of a quiz – is this a req(uirment) or a spec (design)?

Where the line is more blurred is around interface and/or interaction design.  Some development teams have interface designers as part of the team.  Some companies organize with interface design as a “shared service” within the company.  Either approach can be the “right one” – it depends on too many details to make a sweeping generalization.  When the designers are members of the development team, the solution (from a product management perspective) is the same – the “team” is responsible for all design.  When the designers are not part of the development team, the developers have to consume two sets of guidance – “solve this problem” from product management, and “the solution needs to look like / act like this” from the designers.

Collaboration between product management and user experience people is the ideal solution.  The “requirements” and “design” inputs to the development team are comprehensive and consistent.

Design-Free Requirements

There are benefits – especially when being agile and minimizing documentation – to delivering requirements and design at the same time.  Just don’t do it by embedding design constraints within the requirements.

• When people on your team misinterpret design as requirements, they are unnecessarily constrained.
• As a product manager – are you the best designer on your team?  If you’re busy designing, who’s product managing?

This is trickiest when writing use cases – sequencing a set of interactions is interaction design.  That is one benefit of writing a user story instead of a use case.  An approach that has worked well for me with multiple teams is to deliver user stories (requirements) combined with storyboards (interaction design) and wireframes (interface design).  When details are needed (usually when “changing” versus “creating” an interface), screenshots can replace wireframes.  When business processes are complicated, process flows can replace storyboards.

Just don’t embed the designs within the requirements.

You have an eCommerce site.  You sell products online.  Do you cross-sell additional products?  Do you upsell to better products?  This article explains the difference between cross-sell and upsell, and looks at some real-world data about the effectiveness of both.

Cross-Sell and Upsell – What Are They?

Cross-selling and upselling are marketing techniques that are applied during the sales process to increase the value of the transaction to both the buyer and the seller.  Technically, they only increase the value to the seller – but they should also be increasing the value to the buyer.

The key idea behind both cross-selling and upselling is that you are changing a transaction that is already in process.  You might think that marketing ends once buying begins.  Not so.  Marketing is about getting the right message (buy something from us) to the right person (someone who needs our products) at the right time (when they are ready to buy).

• What better time to market than when someone is in the process of buying already?
• Who better to market to than someone who is in the process of buying from us?

The trick then, is in sending the right marketing message.

Cross-selling and upselling only make sense in the context of an ongoing sales process.  For an eCommerce retailer (a company that sells a product online), that means that the customer (technically, the prospective customer, also known as a prospect) is in the process of making a purchase – either looking for the right product, evaluating a specific product, or having selected (but not yet purchased) a product.

• Cross-selling is defined as selling an additional product when the customer is purchasing the original product.
• Upselling is defined as selling a more expensive product instead of the product that the customer was originally purchasing.

As a retailer, you have to know when to attempt to cross-sell, and when to propose an upsell – and when to do both.  To decide when to try and modify (and risk losing) a sale, you have to look at the economic impact on your business of trying to change an ongoing sale.  Cross-selling does not help you make a sale that you wouldn’t already have made – although an upsell suggestion may help a customer discover a “better” product for their needs, and close a sale that would have been abandoned otherwise.

Note – to keep the language of this article easier to read, the word “product” is being used to represent (traditional) products and services – anything a business would sell.

Economics of Selling

To evaluate the economics of cross-selling, you have to first establish the economic measures of selling.  When you sell something you have the following:

• Price - the price the customer pays for the product being purchased.  This is also known as revenue.
• Cost - the cost to the merchant to acquire or create the product being purchased.  Also known as “COGS” – an acronym for cost of goods sold.
• Gross Profit – the price paid by the customer minus the cost of the product.
• Cost of Sale – the cost the merchant incurs to make the sale.  For an individual transaction, this is called “cost per quote” or “cost per order” or “cost per sale.”
• Net Profit – the gross profit minus the cost per sale.  This is also known as operating income.

As an online retailer, you will likely track all of the above.  Your Cost of Sale is potentially difficult to measure – you will probably have a mixture of variable costs and fixed costs that can be allocated to the cost of sales.

• If you pay $1,000 per month to host your eCommerce website (making sales possible) and you make 1,000 sales per month, you could allocate $1 per sale as a cost per sale.
• If you pay 2.5% of the price collected to a credit card processing service, and you sold a product for $100, you would incur a $2.50 cost per sale for that transaction.

A financial analysis of your business will involve aggregating all of the revenue and costs, and calculating the total operating income (all revenue minus all costs) for a period of time.  Since you sell different products (with different costs) at different prices, any given transaction will have a different net profit.  As part of managing your sales and pricing, you may also measure

• Average Revenue per Order - 100 orders for a total $1,500 in revenue would yield and average revenue per order of $15.  Calculated as Revenue / Number of Orders – in this example $1,500/100 = $15.
• Average Gross Profit per Order – 100 orders at $1,500 in revenue with $1,100 in COGS would yield an average gross profit of $4 per order.  Calculated as (Total Revenue – Total COGS)/Number of Orders – in this example ($1,500 – $1,100)/100 = $4.
• Gross Profit Margin (Percentage)- a product purchased for $100 for which the retailer paid $60 to acquire the product has a gross profit margin of 40%.  Calculated as (Revenue – COGS)/Revenue – in this example ($100 – $60)/$100 = 40%.

Economics of Cross-Selling

Cross-selling is when you convince a customer (who is in the process of buying something) to buy an additional product.  When you successfully cross-sell a product, you are increasing the revenue for the order.  This results in an increase in average revenue per order.  The sale of the additional product will also increase the average gross profit per order.  The cross-sell may increase the gross profit margin of the order, or it may not.  When the product originally being purchased is less profitable than the additional product being cross-sold, the margin is increased.  When the original product is more profitable than the additional product, the margin is decreased.

If your current operations strategy involves increasing your profit margins, you need to make sure your cross-sell activities only recommend additional products with higher margins than the products against which they are being cross-sold.  When your strategy is prioritizing growth over profitability, your cross-sell activities should focus on conversion – increasing the percentage of the time are you successfully cross-selling additional products.

Economics of UpSelling

Upselling is when you convince a customer (who is in the process of buying something) to buy something else – specifically, something more expensive.  This replacement of the original item with a new item is known in economics as product substitution.  Since the products are not identical (one is more expensive and presumably “better” than the other), the products are by definition imperfect substitutes.  A perfect substitute is one that would be identical to the product it replaced.

Successfully upselling a product results in an increase in revenue, and ideally an increase in profits.  It may also result in an increase in profit margin (but may not).  Consider a customer who intends to purchase a 200GB hard drive for $100 (at a cost of $45).  This purchase would yield $100 is revenue, and $55 dollars in profit at a 55% profit margin.  If you successfully upsold the customer to purchase a 500GB hard drive for $200 (at a cost of $100), the purchase would yield $200 in revenue, and $100 in profit at a 50% profit margin.

You have to understand if your strategy is prioritizing an increase in revenue, profits, or profit margins.  This will determine which upselling recommendations you want to make to customers.

Measuring Cross-Selling and Upselling

In addition to measuring your sales you want to specifically measure the impact that cross-selling and upselling has on your measurements.  Those measurements are described above.  You may be breaking those measurements down by product category, product price levels, market segments, or any other decomposition that helps guide future decisions.  You also want to measure the effectiveness of your cross-selling and upselling solutions.  You do that by measuring conversion – the percentage of customers that change their purchases in response to your cross-sell and upsell marketing.

Get Elastic, the eCommerce blog, shares some 2009 survey data provided by the e-tailing group on cross-sell and upsell conversion statistics.  Two-thirds of retailers that measure cross-sell and upsell conversion rates reported less than 5% conversion rates.  At the same time, Get Elastic reports that Amazon reported 35% of their 2006 revenue came from cross-sells.

If you’re adding cross-selling and upselling capabilities to your eCommerce website, you should set your initial expectations of effectiveness low, and your aspirations high.  You won’t start out with results like Amazon’s – no more than 98% of retailers that measure conversion see results far lower than Amazon’s.  In fact, most of them see results an order of magnitude smaller.

Your company is building out a toolkit to support third-party developers.  You’ll need a bunch of different types of widgets – combo-boxes, text entry fields, domain-specific controls, etc.  You’ve got a long list of desired controls from your customers.  You’re agile.  What do you build first?

Agile In A Soundbite

Being agile is about delivering incremental value, quickly, getting feedback, and then delivering more incremental value.  Repeat until “done.”  Good agile adds a qualifier – do the most valuable thing quickly, get feedback, do the most valuable thing (that has not already been done) quickly. Better agile optimizes the rate at which you deliver value by taking into account both benefit and cost.  Great agile overlays a focus on getting better at doing all of these things while you do them – becoming a learning organization.

Boiling the Ocean

A product manager I was coaching was faced with a challenge commonly referred to as boiling the ocean. His team was tasked with solving a market problem, and they were constrained to doing it with a service-oriented architecture that exposed a set of widgets (user interface controls) that customers could easily integrate into their products.  This approach was designed to provide competitive differentiation by reducing the time and cost to deploy solutions that allowed customers to integrate his product into their existing platforms.

In initial conversations with customers, technologists, and architects, this product manager quickly amassed a list of desired widgets (controls) and scenarios (stories) in which they could be used.  The product manager’s team had recently switched to an agile development methodology.  The internal stakeholders, not yet accustomed to agile development, wanted “all of the widgets,” now.

This product manager was able to convince them that the team would deliver the widgets incrementally, following agile principles.

His question was – How do I sequence the widgets in the backlog?

Defining Widget Priority

The product manager had a list of widgets, combo-boxes, data-grids, text fields, radio buttons, etc., and for each widget, he had a real-world scenario showing how the widget could be used.  Most of the scenarios involved customers using multiple widgets.  He wondered if he should do some sort of analysis that detailed the frequency of use of each widget.  ”This widget is used in 7 scenarios, so it should be done first; this widget is used in 5 scenarios…”

There was a strong temptation to add several “Create a widget” tasks to his backlog.  It would be easy for his development team to estimate the effort required to deliver each widget.  His team wanted to deliver incrementally, and “one widget at a time” felt like logical, discrete chunks of work to them.  They could easily sink their teeth into estimating, building, and testing each widget.

A quick reminder of a main tenet of agile, delivering incremental value, illuminated the flaw in this approach.  This approach would have been an inside-out prioritization, when value delivery requires an outside-in perspective. (See the ‘recommended reading’ suggestions on this page to check out Kessler and Sweitzer’s great book.)

If the team used this approach, after the first widget was complete, they would be able to deliver exactly 1 task, and 0 stories.  Development teams don’t deliver tasks, however.  The team’s customers would not be able to get incremental value from having a single widget.  The team would have delivered seven incomplete stories – so they would have delivered no stories at all!

We reworked his approach as follows:

1. Assess a value for each story, making sure that each story would enable his customers to accomplish something valuable.
2. Engage their user interface / user experience designer to design a solution for the most valuable story.  This design was constrained to use widgets in the user interface.  The suggested way to communicate this design was with a storyboard and low-fidelity wireframes.
3. Identify the widgets needed to be built to deliver that story, using the designer’s design.
4. Deliver the story to the development team, including the storyboard, wireframes, and list of widgets to be used as acceptance criteria.
5. Get the development team to size (estimate) the effort to complete each story.
6. Where stories were too big (epics), collaborate to identify good ways to break up the stories into manageable chunks.
7. Repeat steps 2 through 6 until the amount of identified effort was likely to fill the release (keep the dev team busy delivering value).
8. As the team delivers each story, get feedback from the market, revisit the prioritization, and revise the “next” story.

What we discovered was that a scenario like the following (modified for this article) played out:

• The first story required two widgets.  As no widgets existed, both had to be built.
• The second story required three widgets, but two of them had been built to support the first story – only one incremental widget had to be created.
• The third story used one of the widgets from the first story, but required additional behaviors.  The original widget was modified to provide incremental capabilities (and value).

A Note On Team Structure

Astute readers will notice that there was a design step “inside the requirements process” – before the stories were delivered to the development team.  Technically, that is true, for the way this particular company was organized.  The user experience designer was not a member of the scrum team, but rather, an external consultant who supported multiple teams.  The product manager engaged the designer prior to engaging the development teams.

This just as easily could have happened as follows:

1. Product manager identifies, values, and prioritizes stories to be added to the backlog.
2. Development team, as part of sizing the stories, engages their user experience designer to select the appropriate widgets, and those design decisions inform the estimation process.
3. Everything else is the same.

This procedural variation does not have design “inside the requirements process.”  The same people do the same things, in the same sequence in this scenario.  The only difference is that the interface / interaction designer is a member of the development team.  That would be ideal, but that was not how the company was organized.

In this particular example, having the product manager collaborate with the UX designer made the most sense.  It introduced less complexity for the product manager to accept responsibility for this activity than it would have for the development team (who was still new to using an agile delivery cadence) to do it.

Conclusion

The key ideas at play here:

• Focus on realizable value to the customer (outside-in development), not tractable tasks (inside-out development).
• Collaboration with a UX professional is key to driving “interface requirements.”
• Deliver frequently and valuably, get feedback (learn), and incorporate that knowledge into whatever is next.

Perpetually intermediate (competent) users.  Users who briefly exist as novice users and never become experts. Most of your users are competent, and you should design for them.  Competent users have different needs and different expectations than novice or expert users.  How do you know your user’s competency levels, so you can design for them?

User Competency

User competency is a concept I first read about in Alan Cooper’s The Inmates Are Running The Asylum.  Cooper’s contention is that the level of expertise of your users follows a bell curve, or normal distribution.

When we’re designing software we need to keep in mind that most of our users will be competent – neither experts nor beginners. Alan Cooper’s studies tell us that user skill levels follow a bell curve. He talks about competent users as perpetual intermediates. Some users drop out of the bell curve when they stop using our software. The rare user becomes an expert. Most users only learn enough to get their real job done.
Competent Users and Software Requirements

Cooper contends that the combination of learning curves and natural user tendencies to stop learning or abandon a software application are the sources of this distribution of user competency.

Experience Curves

Experience curves represent the diminishing costs over time of manufacturing something repeatedly.  The process of manufacturing something gets more efficient as you get smarter about the process.  The process of using software is at least analogous to, if not a specific example of a manufacturing process.  If you’re using an email application, you are manufacturing email messages.  In a CRM system, you are manufacturing contacts, or contact reports, etc.

By treating any “using the software to do something” interactions as a process, you can measure the cost (how long it takes) of the user’s interactions.  Applying the math behind experience curves, you can predict the reduction in cost (to your users) over time, for any set of interactions.  Experience curves take into account that some processes are inherently more learnable than others.  This property of learnability is reflected as an efficiency coefficient – how efficiently someone can learn ways to reduce the cost (time) needed to perform the interactions.

This gives us an approach to quantitatively model user competency.  Having a definition allows us to model competence.  And measuring competence allows us to manage product design in the context of user competency - designing for competent users.

Defining Competence

The first step to measuring competency is to define the model.  I am proposing a definition in this article that I suspect will yield insights (to help us manage our products). I was unable to find any quantified definitions of competence, when researching it as part of a client engagement.  If you have, or know of a model, please share it in the discussion below this article.

• A competent user is someone who learns to perform a task in half the time it initially took them.
• An expert user is someone who can complete a task in 10% of the initial time.

This definition is guided by an expectation that Alan Cooper’s premise about perpetually intermediate users is true.  Being a novice user is a very transient state, and becoming an expert is very infrequent.  The goal of the definition is to be able to segment your users and make well-informed design decisions.

A Proposal, Not a Doctrine

This is a proposal that doubling performance reflects competence, and achieving a ten-times improvement represents expertise.  It may be that some different measure of performance improvement more accurately reflects competence and expertise.  We have to test it to know.

The experience curve is defined mathematically by Henderson’s Law.  It states that the time to complete a task is a function of the number of times you have previously done that task, adjusted by the “elasticity” of the cost of that task.  In other words, some tasks are easier to improve than others.  If you populate a table with the results of applying Henderson’s Law, you get the following:

[larger image]

• Each row in the table represents the Nth repetition of a task.
• Each column represents how easy that task is to learn – progressing from “hard to improve” on the left, to “easy to improve” on the right.
• Each cell in the table represents how long it would take to perform the Nth repetition of the task, as a function of how easy it is to improve your performance at the task.

The above definitions represent what experience curves predict mathematically, when the task initially takes 60 seconds.  The following definitions reflect the proposed user competency model:

• A user is a novice user until she has learned enough to cut the time-on-task in half.  These cells have a white background (and are in the upper left area of the table).
• A user is a competent user when the time needed to complete the task is between one half and one tenth of the initial time.  These cells are shown with a yellow background (and are in the central area of the table).
• A user is an expert user when she can complete the task in less than one tenth of the time required to initially complete the task.  Theses cells are shown with a red background (and are in the lower right area of the table).

In the absence of empirical data, I used my intuition to suggest that a representative experience curve for a typical task performed in software would be one with an “elasticity” of 50%.  For a task with those learning characteristics:

• A novice user would cut the needed time in half on the 4th repetition of the task, and would be considered to be a competent user.
• A competent user would further reduce the time needed to one tenth of the initial time on the 100th repetition of the task, and would be considered an expert user.
• The 50% elasticity column is surrounded by a black border, and the number of repetitions required to advance to competent or expert status is also highlighted with a black border.

Inferring Competence

Since different processes have different learning characteristics, you have to figure out how easy it is for your users to improve at your processes.  To do that, you have to study (or at least measure) your users’ interactions with your software.  In the 50% curve highlighted above, a user is capable of cutting their time-on-task in half by the fourth time they perform the task.

If data from your initial testing (or measurement) reveals this to be true, then you have selected the correct curve (the correct column in the table).  If it takes more or less time to reach this level of improvement, shift to the left or right to find the appropriate curve.  If software-interactions are reasonable analogs to manufacturing processes, then the experience curve projects an expected rate of improvement on task.

The following graph isolates the time-on-task data for a user who is learning to improve when repeating a task (process) that matches the 50% elasticity curve.

[larger image]

Note that the number of repetitions of the task (the X axis) is represented as a logarithmic scale.  The data points along the curve correspond to the cell values in the table above (for the 50% column).

Shades of Gray

One nice thing about this quantitative approach to inferring competency by measuring usage is that your measurements are per-process.  Users are not “purely novice” or “purely expert” – they can be experts at some processes, while remaining neophytes at other.  There is also awareness, for any particular process, of “how much competency” a user has.  This allows you to refine your assumptions of the steepness of the learning curve, and of the thresholds (doubled performance and ten-times performance improvements).

Improvement Over Time

Any particular learning curve can be considered relative to calendar time, to see how quickly a user will progress along the curve (as a function of frequency of use).  This can be useful for determining the ROI of improvement in a particular process.

The following graph shows how an 80% learning curve overlays a calendar for tasks that happen daily, weekly, and hourly.

[larger image]

The graph shows that for a weekly frequency, after 16 weeks, the task time has reduced from 300 seconds to 100 seconds. With a daily frequency, the task time is even lower – about 60 seconds. This graph shows nothing other than converting the academic learning curve graph into one that incorporates calendar time and frequency of occurrence.

Software Usability and Learning Curves

One approach to inferring user competency would be to measure how long a user has been using your software.  The variation in how frequently different users perform the same task will introduce an error into that inference.  You can avoid introducing that error into your modeling by counting the number of times a user has performed a task.

Applying the User Competency Model

The advice in previous articles, and from Cooper’s book, and from this great article on the  Coding Horror site, encourages us to focus on the competent users.

I’m working with a client who needs to prioritize a set of capabilities and establish design principles for a product.  We will incorporate this user competency model as part of our analysis.

Hopefully we’ll have an opportunity to collect data to validate and / or refine the model.  I’m proposing that we first gain some insight into the which users (novice, competent, expert) drive the most revenue and profit from use of the product – to establish the importance of each category of user.

For this product, I suspect that we will find many more novice users than a normal distribution would predict.  If that is true, the next question will be to understand if we are dealing with a normal behavioral dynamic, or if characteristics of the current product “force” novice users to abandon it before they achieve competence.

Either way, we will have a framework for prioritizing the goals of the novice, competent, and expert users.

How would you apply a model like this to improving your product?

Steven Haines, author of The Product Manager’s Desk Reference, recently gave a webinar on effectively using product roadmaps for the Technology Product Management Council at Forrester Research.  You should check it out.

Strategy First, Roadmap Second

Steven Haines (@Steven_Haines on Twitter), also founder of Sequent Learning Networks, presented at the most recent productcamp Austin, and one of his topics was about getting “past” the product roadmap to broaden your perspective.  Steven presented the ultimate why for product managers, why add stuff to a roadmap.  He presented some great insights and suggestions for thinking about your company’s strategy, measuring where you’ve been, where you are, and where you want to be – as a company.  Given that perspective, decisions about where to focus your product roadmap become easier.

Steven addressed some of this in his recent webinar for Forrester. Scroll down on this Sequent page to the Webcasts and Podcasts section to download the audio and the slides.

One of several interesting topics Steven touched on was Marketing Myopia.

Market Myopia

One of the things Steven talked about in both presentations was the failure of the railroad industry (slides 6 &7).  He references a quote from Ted Levitt’s Marketing Myopia (first published in 1959!) to make his point.  The railroad companies thought of themselves as being in the transporting goods by railroad business, not the transporting goods business.  Imagine how things might have been different if they had taken a less narrow view.

I see another industry out there right now trying to avoid the same fate.  The companies that connect us to the internet created that capability by building on their previous businesses.  They provided scheduled, managed television programming to us over cable.  The internet required some two-way communication, so they adapted their delivery technology to be bidirectional (although asymmetric).  Competitors entered the space, and we now have an internet service provider “industry.”  You can pay for internet connection services from cable companies and satellite providers (who added “upstream” communication to their existing large bandwidth) and from telecommunication companies (who augmented two-directional communication with increased bandwidth) via DSL and wireless technologies.

Several dynamics are at play disrupting these industries – primarily as companies introduce solutions to customer delight problems.  Tivo decoupled the viewing schedule from the broadcast schedule of television, resetting expectations for everyone.  On-demand solutions from cable providers allow you to watch some content when you want (while Tivo and other time-shifting recorders) allow you to watch anything* on your schedule.

*Broadcasters can prevent content from being watched on-demand (even with Tivo).

Cordless phones allowed us all to detach ourselves from the wall-mounted phone (no more curling trip-wires stretching from the kitchen phone to the nearest closet) and talk “anywhere” close to the phone.  Cell phones allow us today to talk “anywhere” there is coverage, as long as we pay for the service.  Voice-over-IP telephony allows us to talk to people anywhere on the planet without paying the excessive fees that telephone companies charge for international calls.  Add a video-camera, and you can have a video-conference without expensive dedicated hardware.  Add software for collaborating, and you can have a meeting without travelling.  Instant messaging and SMS and chat rooms and Google Wave allow us to have “instantaneous” communication without the overhead of audio or video.  Social networks like Twitter, Ning, and Facebook are allowing us to form and enhance relationships and communities without the “co-location constraints” that have limited them in the past.

Companies like Leo Laporte’s This Week in Tech Network, are allowing us to engage and interact with our content by viewing live “television” shows, joining chat rooms (and soon, joining Google waves), or watching any of the previously recorded shows, when we want – all over “the internet.”  Leo just announced that you’ll be able to engage this community with a Roku box (e.g. watch on you television, not just your computer).

From the perspective of the internet service providers, all of these enriched experiences are “just dumb data” and represent a commodity product.  It jeopardizes their business models.

I see this as strongly analogous to the railroad industry becoming irrelevant because they didn’t adapt to their changing markets.  The railroad industry relied on barriers-to-entry to prevent competition.  Until highway travel became competitive, this worked.  The railroads offered better value than shipping by canal – you could ship to places without water, as long as you acquired a right-of-way and built tracks to that place first.  Trucks allowed you to ship anywhere, without having to build railroads first.

Cable companies allow you to watch content that they select, at the time that they choose.  That content is “produced” with large upfront costs, and everything predetermined.  The “dumb data” internet shows have a much lower barrier to entry.  Take Enzoology for example, Enzo is a nine-year-old boy who hosts “Animal Planet for Kids.”  Enzo (@Enzomonfre on Twitter).  He and his dad produce the show – Enzo is the talent and creator.  You should check out the most recent episode about Capybaras – surprisingly good.  Old Media is discovering him now, as he recently made appearances on Ellen and The Today Show.  The point is, that high barrier to entry is gone.  Shows like Enzoology will pull more and more viewers away from cable tv and to the internet to watch content (and to engage!).

Telephone companies allow you to have a real-time audio conversation with anyone, and pay prices that are decoupled from the cost of providing the services.  You can use Skype to have the same conversation over the internet for a fraction of the cost of using a telephone.  And with Skype, you can use video too.  The current barrier to entry for people is “talking from your computer” – and is reminiscent of being tied to that red phone on the kitchen wall with the stretched-out cord.  But that barrier will evaporate just like the stretched cord did.

Thinking Strategically

Both of these examples (railroads and internet service providers) cause us to think – what is happening to our industries, and what will be happening?  There is certainly value in becoming immersed in your market, understanding and solving today’s problems.  What Steven points out is that today’s problems are just a snapshot in time.  Yesterday there were problems (I have to talk in the kitchen where my mom can hear me).  Today there are problems (I have to sit by my computer to get the content I really want, when I want it).  Tomorrow there will be problems too.  And they will be different, because someone will disrupt your market (railroads killed canal boats, trucks killed trains, …).

What could disrupt your market, and more specifically, your value proposition?  What will?  OK, why don’t you be the one disrupting everyone else’s market?  Now – what’s in your roadmap to make this happen?

So, check out Steve’s presentation, and start thinking about the future of your market, not just the present!

Kano Analysis, while initially created to understand customer satisfaction with features, can be used by product managers to better understand customer problems.  I gave a presentation last week for the Product Management View webinar series on Kano Analysis for product managers.

Kano Analysis – The Webinar

You can watch (flash) or listen to (mp3) the webinar (just under an hour) at the Product Management View webinar page for the Kano Analysis presentation.  I delivered the webinar on Sep 23rd, 2009.  Thanks Val Workman for inviting me to join the group and share an hour with a bunch of great folks.  Also, thanks to the people who asked questions, tweeted, and commented on the presentation.  I really appreciate it.

Kano Analysis – The Slides

If you want to flip through the slides to get a feel for the treatment I gave to Kano Analysis before committing an hour to the webinar, you can do so right here (or view the Kano Analysis slides on slideshare.net).

Thanks again to everyone, and if you have any feedback, include it below or on the PMV site.  Several links to other articles about Kano Analysis are in the comments on the PMV page, if you want to do further research.

In the previous article on the Conversation Ecosystem, I introduced a hierarchy of increasingly valuable conversations.   Some great feedback from you inspired a better visualization.

The Conversation Hierarchy

In The Conversation Ecosystem, I presented a perspective on the conversations around you, your company, and your product.  The conversation ecosystem is building on ideas introduced in The Conversation Economy, which build on several great ideas from some great thinkers.

That presentation of the conversation showed a hierarchy representing conversations of increasing value to you.  For example, following someone is more valuable (to you) than being followed by them – because it gives you an opportunity to gain market insights.  Being friends with that person is significantly more valuable than that – because it gives you permission to explore your market, try new ideas, fail quickly (with reduced penalties for failures), and discover and validate important trends, problems, and ideas.

[larger image]

Each of the elements above was presented separately, but the above view is what it added up to.  April Dunford pointed out that you don’t always move from one level in the hierarchy to the next (up or down).  An ecosystem is the environment around you.  Combining the two ideas led to an improved visualization of the conversations around you.

[larger image]

Adding all of the possible transitions within (and entry points into) the conversation circle would just make the diagram a mess.  Viewing the conversations as a circle around you instead of in a stack helps expose another key element of conversation, and why managing it can help you grow your conversations.

The Growing Conversation Hierarchy

Imagine what the circle above would look like for anyone else in your conversation ecosystem.  That person would be in the center, and you would be in orbit around them.  When you acknowledge that your conversations are just a part of other people’s conversations, you immediately jump to the following visualization:

[larger image]

Conversations Lead to Conversations

Conversations lead to introductions, which can then lead to new conversations.  When you are conversing with a friend, that friend may introduce you to some of the people he is having conversations with.  When you are conversing with someone who is promoting you, she is explicitly making other people aware of you, and encouraging them to have conversations with you.  You’re even more likely to have conversations with them.

Someone who is followed by you is conversing with their friends, and you can see some of those conversations – but it is analogous to eavesdropping at a party.  You won’t get introductions to those people.  This is still a valid avenue to growing the size of your conversational circle, but you’re starting the conversation by saying “I overheard you talking to Jimmy, and you mentioned you were a horticulturist – that must be fascinating…”  Awkward.

Conversation, certainly in the conversation economy, is built on trust.  You won’t engender much trust by saying “Hey – I was stalking this friend of yours, and by going through her trash, I found your phone number.”  That’s why you don’t get access to that circle of people.

What Do You Think?

I’d love your feedback on this view of conversations.  What ideas come to mind when you look at things this way?

The previous article, The Conversation Economy, lays out a perspective of approaching the success of your business, and of your product, in light of the conversations that flow around them.  You can view the ecology that defines your market in terms of the kinds of conversations you’re having with your customers, users, and prospects.  This article explores that ecosystem in more depth – categorizing the types of conversations that are critical to the success of your product.

The Conversation Ecology

I identified quiet, conversing, and promoting customers in the conversation economy article, with a focus on the paying-customers for your product in a freemium business model (check out the extended remix in the latest The Pragmatic Marketer). In reality, the conversations are important not only with the paying customers, but with all active users.  In other words, the diagram above is useful for an introduction to the conversation, but it is not a useful model for managing the conversation.  And you have to manage it, if you want it to influence the success of your product. In preparation for managing the conversation, we need a more robust, better defined model.

David Armano introduced the Marketing Spiral as a visualization of this user-ecosystem 2007, with a focus on the social-psychology of how people develop increasingly engaged relationships with a company.  The following image is from David’s article – a larger version is available on his blog.

As the diagram shows, Armano was keying in on the same dynamics of participation and engagement, and he had the insight that affinity (for a product / problem / domain) is a source of spontaneous community around a product or business.  What Armano doesn’t touch on is the criticality of managing this ecosystem for your business to succeed, but the spiral does inherently capture the notion that engaging your community is an ongoing affair.  So that model still doesn’t quite work for this use.

The three terms I previously defined - quiet, conversing, and promoting; really need to be split into five categories to effectively describe the different forms of engagement you have with your customers.

At the top of the heap are the people who most impact your business – the promoters.  At the bottom are the quiet users and customers.  The conversationalists still occupy the middle, but now are broken out into some distinctive (and meaningful) categories.

• Quiet customers – these are the users and customers most at risk of being lost.  While probably representing the majority of your customers, you really don’t know how they are doing.
• Conversing customers, following you - the first level of engagement you can get in social media is having your users listen to you.  In Twitter-speak, these are your followers.
• Conversing customers, followed by you – the next level of engagement, and one you can proactively drive, is finding users and listening to them.  On Twitter, these are the people you follow.  Products like Buzz Manager are designed to give you insight into what these folks are saying about you – helping you discover the conversations that are already happening.
• Conversing customers, friends with you – these are the people you interact with.  They talk about you, you hear what they say, and you have a conversation.  On Facebook, they may be the fans of your product’s fan-page.  They comment on your blog posts, you comment on theirs.  You respond to each other and retweet each other’s Twitter tweets.  You have dialogs in forums, email, or even in person.
• Promoting customers – these are the folks that explicitly encourage other people to use (and sometimes buy) your product.  Some of the people in your ecosystem will arrive by affinity, others will be roped in by their networks – thanks to your promoters.

How To Improve Your Conversation Ecosystem

There are many people writing about very specific things to do to improve your engagement, or social-media presence.  Instead of trying to reproduce all of those pieces of advice (if you have a favorite – add it to the comments below), I’m going to provide some simple pieces of guidance for moving people from one level to the next.  Providing a comprehensive, prescriptive approach is out of scope for this article (as a former developer, I never tire of that one).  My goal in laying out the following transitions is to think about the (local) goals you should be focused on as part of each transition.  For example, in the first transition (below), one goal is to establish thought leadership.  Technically, that is a “design decision” and not a requirement, but it is slightly more abstract than “create a podcast and interview industry mavens” – a perfectly valid “implementation approach.”

Getting Quiet Customers to Follow You

You have to start by asking why one of your customers (from here on out, “customer” equals “customer and / or user”) would want to listen to you.  Personally, I believe the most effective way to do that is to provide relevant information and insights to them.  If you’re targeting customers in the health care market, write about the impacts of HIPAA, or the potential industry impacts of health-care-related legislation.  Whatever their domain is, identify important topics, develop insights, demonstrate relevance, and provide guidance.  Over time, you’ll develop recognition as a thought leader.  As a bonus, you’ll form relationships that help you get even better market insights.  As a tip – make sure those messages are going out consistently.  Not everyone uses RSS – some people will habitually look for your latest article every week – as long as there is one.

If you think that your customers aren’t out there talking, take a look at Forrester’s recent study, The Broad Reach of Social Technologies, which shows that the number of Quiet customers (United States online adults) has dropped from 44% in 2007 to 25% in 2008 to 18% in 2009.  Your customers are participating socially.  They are having conversations.  Probably about your products and companies.  You should make sure that your customers are hearing your voice in that mix.  But that isn’t enough – if they only hear you, and you don’t hear them, that’s not a conversation, it’s a monologue (or maybe even a soliloquy).

Following Customers

“Followed by” is tricky (I’m open to a better descriptor, if you have one), because it is a passive activity for your customer.  For one of your customers to be followed by you, the action is entirely yours – start listening.  I chose not to combine this with Following, because there is a distinct benefit to you – developing market insight.  A customer who is listening to you is valuable, but a customer to whom you are listening is even more valuable.

Starting a Dialog With Your Customers

One-directional communication is so not-any-more (insert your preferred definition of “a long time ago”).  Once you’re following a customer, the next step is to engage them in conversation.  If they’re posting product reviews about your product, respond – with thanks or with apologies and resolutions.  Respond to people, join in on conversations.  Not just the conversations about your products, but the ones about your customer’s problems.  If you can, instead of joining an existing community, host one.  It may be that your customers haven’t found a place where they can congregate and talk about their market – give them one.  Bazaarvoice has a new product called Bazaarvoice Stories, that gives companies a place to host the conversations with their customers.

Converting Customers into Promoters

In The Freemium Business Model and Viral Product Management in the current issue of The Pragmatic Marketer (and thanks again to them for publishing my article!), I wrote about the notions of altruism and implicit or explicit rewards for getting someone to promote your product.

To activate the altruistic mechanism of getting people to promote your product, you have to exceed the viral tipping point.  The viral tipping point works like the suck-threshold, only instead of being just good enough that your product doesn’t suck, your product is just good enough to reach the tipping point (ala Malcolm Gladwell) that inspires people to promote your product simply because it is good, and they want to share that goodness.

You can also use an incentive to get people to promote your product.  Explicit incentives are things like affiliate programs, or “refer a friend and save 20% on your subscription for as long as you both subscribe.”  Implicit incentives are the brass-ring of viral product management.  Create a product that becomes better for a customer when they get more people involved.  Facebook has that – because a social-network is more valuable to you when it includes your friends.

How to Make Your Conversation Ecosystem Crumble

What goes up can come down, but it doesn’t have to.  There are things you can do (really, things you should avoid doing) that will weaken the quality and nature of your engagement with your customers.

Losing Promoting Customers

The surest way to lose the help of your promoting customers is to violate their trust.  You can sell their email address, “change” your terms of service in a bad way (like suddenly announcing that all of their data is now your data), reneg on your promises, etc.  Almost as bad – fail to notice when their needs change.  When you provide a great solution to someone’s problem, they are likely to tell folks about it (she’s a great baby-sitter, and even cleaned our kitchen; or you have to try Rally – the burndown charts are perfect for our exec reviews).  But eventually, those problems either go away, or stop being perceived as big problems (sure, the kids were fine, but she ate all our ice-cream; or yeah, the tracking is nice, but you sure do have to click a lot).

Breaking Up With Customer Friends

The obvious one – don’t attack people, reminds me of an article from last year at On Product Management about bad customer service.  Definitely an easy way to get someone to stop interacting with you.  When someone is complaining about your product or company, don’t attack them, don’t be defensive, and don’t ignore them.  Help them out.  When this happens, you have an opportunity to make them a huge fan, or you have an opportunity to lose permission to have a two-way conversation with them.  Instead of ignoring, try acknowledging.

Stop Paying Attention to Your Customers

You have people you’re following.  As long as you don’t start ignoring them, you won’t slip backwards.

Losing Customer Interest

When your messages lose relevance – either because you’ve changed, or because your customers changed and you didn’t – they will stop listening.  If you stop sharing consistently, you’ll lose some followers.  And if you stop saying anything, you lose all of them.

Conclusion

One way to approach strategy is to ask “where am I, where have I been, and where do I want to go?”  In a conversation economy, to do that, you have to know how to measure where you are and where you’ve been, in terms of a conversational model like the one outlined above.  With those insights you can define where you want to be (and you’ll know how to determine if you’ve made it).  Then you can form your plan for getting there.

The Conversation Economy and Conversation Ecosystem articles are components of an approach to measuring and managing the conversations that affect your product and your company.  Future articles will look at how this conversation approach maps to your product’s success, and propose important measures of your conversation.  Any feedback, corrections, or suggestions is definitely very appreciated.  I believe there is some powerful stuff here, and some straightforward techniques to harness that power to improve the success of your products.  Let me know what you think.

And while you’re at it – try the handy “tweet this” button right below this sentance – especially if some of your followers would benefit from or could contribute to this discussion.  Thanks!

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!

• You website is not just a tool, it is a service, and therefore a product.
• Your prospects make buying decisions based on your website.
• Your customers make repeat-buying decisions based on your website.
• You risk losing future customers because of your website.

You Already Have Product Managers

You focus on a market, and based on the buyer personas and user personas in that market, you decide what products to create and what they will do.  If your product doesn’t match your buyer’s perceptions, you won’t sell it.  If your product doesn’t match your user’s expectations, you won’t sell them anything else, or sell anything to their friends.  As product managers, we do innumerable tasks to assure that we have the right products for our prospects and customers.  Why don’t our companies put the same effort into our websites?

Retailers Get it

Retailers get it.  They know that their website is the product that allows them to sell other products.  Amazon has product managers for its website, as well as other products (like Kindle and Video on Demand).  Newegg has product managers too, and their only product is the service of selling other products.  Why do many companies not get it?

I’ve worked with several larger clients in the past who viewed their website as a tool, as overhead.  A critical tool, yes, but a tool.  A mechanism for sales, just like a CRM system or an inventory management tool – it has to work, period.  It is all of those things, but it is a lot more.  When you sell products online, your website is how your customers see you, and how they see your products.  Your website shouldn’t just be a collection of technologies that grew out of engineering, supporting processes that have been “engineered for efficiency.”  Your website, assuming online presence is strategic for you (and if you’re reading this, and online isn’t strategic for you, please let me know, I’ll be shocked), should be developed with a strategy in mind.

Even Large Companies Can Change

I was recently working with a larger company who was changing their approach to their website (also known as their “online presence” and “online solutions”), re-aligning parts of their organization to allow them to product-manage their website.  There is a ton of work involved in changing how a large organization approaches this.  Changing how development of the website is prioritized, funded, managed, and executed.  Creating an explicit focus on markets and customers and partners, where before the focus was on features or capabilities.  Gaining insights into how competitors are serving those markets, and how the company needs to change – instead of telling the “other” product teams what choices they have for leveraging the tool.  Understanding the goals of your users – buyers, customers, prospects, and partners.  Incorporating the strategies of your business – the same strategies that drive your other products – into how you approach developing your website.

Here’s a litmus test.  When your company introduces a new product, or launches a new campaign, or enters a new market, does the team managing your website ask “what can we do?”  Or does that team say “here’s where you put the whitepapers; here’s what we need for product data; put your sku list and pricing rules in that system; your images must be this size.”

This isn’t directed at companies who’s product is their website like software-as-a-service companies.  This is focused on the companies who have other products, and treat their website like a tool or an asset.

By treating your website as an asset instead of a product, you create a liability instead of an opportunity.

I’ll be writing more in future articles about elements of product managing your website.  Some topics I may address:

• Understand your markets.
• Understand your buyers, customers, and prospects (and partners and internal users).
• Understand your competitors.
• Manage your internal stakeholders and their expectations.
• Understand your distinctive competencies – what makes you better?
• Understand your positioning – are there opportunities for thought leadership?
• Understand technology – are there opportunities for technological advantage?
• Assess your website as an element of a distribution strategy.

Concise requirements give your team a useful, easy to read and easy to change understanding of what must be done.  Great requirements exist to do three things:

1. Identify the problems that need to be solved.
2. Explain why those problems are worth solving.
3. Define when those problems are solved.

Concise Requirements – Revisiting

In the three years since we last looked at Writing Concise Requirements from the Big Ten Rules of Writing Requirements, the iPod evolved to give us a better experience.  Let’s see if we can do the same with the topic of brevity in requirements.  The size of our community here has grown ten-fold, and the people who were here back then have grown just as much.  It makes sense to look at this again.

Writing concise requirements is not just minimizing the number of words you use.  Writing concise requirements is presenting the most important information in the easiest format for your audience to consume.

Concise Requirements Identify the Problems That Need to be Solved

Ultimately, requirements are the problems that we choose to solve.  A concise requirements artifact (formal document, index card, photo of a whiteboard, whatever) is one that has the highest signal-to-noise ratio possible.  You’re maximizing the amount of communication, and minimizing the cost of communicating.

You want your requirements document to read like the lines, not the points.  If the line (the signal) is what you really want, and you communicate a big pile of points (the signal, hidden in the noise), you run the very real risk that your audience will misinterpret the signal.

User stories provide the best example of clarity that comes from conciseness.  The format you should use, based on Mike Cohn’s great book, User Stories Applied, is

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal]

The user story is not always the right communication format – it depends on what problems you’re solving, and who is on your team.  Sometimes, use cases work better than user stories.  Conciseness is important for use cases too.  Start with a good use case name.

Concise Requirements Explain Why Those Problems Are Worth Solving

Last week’s article on Valuable Requirements focused on why particular problems should be solved.  Your focus should be on value, and that article discussed five ways to assure that your requirements are valuable.  One of the techniques, the use of an Ishikawa diagram, provides a method for identifying the root causes of problems.

[larger image]

Imagine that you have a collection of user stories, representing problems to be solved for your users.  You need a way to demonstrate why this user story should be implemented and why that one shouldn’t.  You can often use the Ishikawa diagram in the same way.  A particular goal is achieved when a user is able to do something.  Perhaps several somethings are required.  The point is that you can use the Ishikawa to drive home the point – if this set of user stories are all implemented, then this goal will be achieved.

There are two reasons this is important – first, you’re providing context for your team.  They understand why they are doing something.  Second, you can make changes easily, because you can see the impact of those changes.  By understanding the cause-and-effect relationships between problems and their values (user stories and their goals), you can see the impact of changing one or the other.

Concise Requirements Define When Those Problems Are Solved

Clarity is the goal of conciseness.  It isn’t enough to say “work on this.”  It’s important to know why you’re working on it, but that still isn’t enough.  You have to know when you’re done.  When you’re defining problems to be solved (and therefore solutions), you must also define the measures by which the solution will be judged.

A measurement of success for “Cost of Operation is Too High” might be “reduce costs of operation by 10%.”  This gives you a testable criteria for knowing when that problem has been sufficiently solved.  Sticking with the Ishikawa, you can also map out the strategy for achieving that lofty goal.  You can say that the goal is to reduce fuel expenses by 20%, reduce cost of maintenance by 5%, and reduce payments by 15%.  This process continues – a 20% reduction in fuel spend requires that you operate with your tires within 5% of nominal pressure, and that you reduce the aerodynamic drag coefficient by 7% (or whatever).

This gives you clarity in your objectives.

User stories, when combined with user acceptance criteria, provide that last connection of testability that lets your team know when they are done.

There aren’t many things more frustrating to a development team than having them solve the wrong problems.  One of those things might be having their solution be rejected because it isn’t enough.  Writing acceptance criteria clearly and concisely lets the team know exactly when they can move on to the next problem.

Providing a crisp understanding of acceptance criteria also facilitates iterative development.  One challenge teams always face is making improvements that fit within the timebox of a given iteration.  Imagine a user story with 4 acceptance criteria, where the story is too big to complete in one sprint.  When talking with your development team, you may find that the story is too big because satisfying all of the acceptance criteria is too big.  This is where many teams miss an opportunity – by defining all of the acceptance criteria that are believed to be needed eventually and requiring that they all be implemented now.  One of those criteria is going to be more important than the others.  Implement the story such that is satisfies the most important criteria (timeboxing) now, and rewrite or enhance it to meet the additional criteria later.

Conclusion

Software Product Success depends not only on identifying the “right stuff” to build, but on making sure the team builds it and builds it right.

Concise requirements improve your ability to communicate with your team, thereby improving their ability to build the right stuff right.

Writing valuable requirements is important.  It doesn’t matter how well your teams execute if they are off building the wrong products / capabilities / features.  The right products and capabilities are the ones that have relevant value.

• Valuable requirements solve problems in your market.
• Valuable requirements support your business strategy.
• Valuable requirements solve problems for your users.
• Valuable requirements meet your buyers’ criteria.
• Valuable requirements don’t over-solve the problems.

Valuable Requirements – Revisiting

A little over three years ago, I compiled the Big Ten Rules of Writing Good Requirements, which ended up with an even dozen “rules.”  The first rule was writing valuable requirements.  Three years is a long time.  Our environment has changed.  Many great insights have come into our neck of the software development woods from many inspired voices.  I’ve personally learned a lot.  My focus has changed from being more focused on product specification (back then) to being more engaged in business strategy (today).  Our audience here has grown ~ 10x since the original rules were published.  My dog has tripled in size.  Perhaps my writing has even improved.

Given that, it makes sense to revisit the topic now.

Valuable Requirements Solve Problems in your Market

I struggled a little about starting with “strategy” or starting with “the market.”  Pragmatic Marketing’s Framework (recently updated) starts with the market.  When I first watched the great video, where Jim Foxworthy introduces the updates to the grid, I was a little concerned about that.  Market first, strategy second.  Why not strategy first and market second?  I decided that I was happy with their presentation, since the framework is a tool for product managers.  Product managers usually have responsibility for a market, as a component of their company’s strategy – so the sequencing makes sense for a product manager audience.  Jim also puts it in perspective – their framework is focused on the company’s strategy for attacking a particular market.  I’ll stick with that here too.

To understand what problems are valuable for a particular market (or market segment) you have to approach it from your customer’s perspective.  What are the problems they are trying to solve?

Your customers might be distributors of retail products, who’s business it is to acquire, store, and redistribute small products.  They are in a business where their customers value accuracy, timeliness, and low cost of delivery.  Your customers may value solutions that allow them to more accurately redistribute products (they receive pallets full of items, and then redistribute them a case at a time).  They may value solutions that allow them to adapt to changes in orders with minimal turn-around time.  Or they may get the most value out of cost reductions.  Talk with your customers, listen to them talk about their problems.  When I was working for an enterprise software company years ago, our CEO stressed that he wanted to be solving the problems that keep our customer CEOs up at night.  Find out what those problems are.

The next challenge is in breaking those problems down into something actionable.  If your customers’ biggest problem is cost reduction, how do you solve it?  The first step is to understand where the costs are.  One way to visualize and decompose the problems your customers face is with an Ishikawa diagram (check this out to learn how to use an Ishikawa).

The following diagram shows a decomposition of “The cost of driving is too high” problem:

[larger image]

Now you’ve identified a set of problems that are valuable to your customers.  The Ishikawa can help you make sure you’re identifying problems, not the manifestations of problems.

You also have to understand what solutions are already available to your customers.  If you have a competitor that already offers a very good solution to one of the identified problems, your customers will find less value in a solution from you.

Valuable Requirements Support Your Business Strategy

With a set of problems in hand that are worth solving, you have to figure out which ones are aligned with your company’s strategy.

In the Ishikawa above, one of the problems that car owners face is excessively high payments (on their car loan).  Another problem is that the cost of maintenance is too high.  If your company provides financing products (loans and leases), trying to solve the cost of maintenance problem for your customers is probably out of alignment with your strategy.  Making the financing of a vehicle more affordable (while still profitable for your company) is probably a well-aligned problem.

Your company will also have a strategy for engaging the market – target market share levels, target market segments to penetrate, etc.  You may be trying to become a visionary company with your finger on the pulse of your market – or you may be trying to get mass adoption of your product by solving a very common problem, but solving it better than your competitors.  Your strategy for winning in this market may be to differentiate your offerings by solving different problems than your competitors, or defining a unique market.

Another way to think about alignment with your business strategy is to think about the owners of your company’s strategic goals – your internal stakeholders.  Most projects will fail (or be killed) without internal champions who believe in the ideas.

When you’re aligned with a part of your company strategy,  you’re aligned with whoever is the owner of that component of the strategy, and you’re providing value to that stakeholder.  Sometimes there are many components and stakeholders.  You can adapt some process-improvement prioritization techniques that Roger Burlton teaches to get an understanding of which goals are important to whom.

Valuable Requirements Solve Problems for Your Users

Products are used by people.  People use those products to accomplish goals.  They may be using your product for their employers, in which case they have “practical goals” (finish quickly) that represent how their company’s goals (lowered costs) are realized.  And those people usually interact with other people.  You can quickly build a visualization of who are the users (and indirect users).

[larger image]

You can think of this as an ecosystem of users of your product.  Develop personas and their goals to represent these users.  You can apply the same Ishikawa-based problem-decomposition technique when needed to make sure you’re uncovering the real problems (too many people abandon the sign-up process) and not the manifestations of those problems (users have to click too much).

When your users are not your customers, your users have personal and practical goals that represent their individual contributions to achieving your customer’s goals.  And your users achieve those goals by doing stuff.  You can represent that stuff with user stories or use cases.  The key element is to make sure that you’ve identified the valuable activities, the ones that are required to achieve goals.

[larger version]

The above diagram is used when assessing the completeness of requirements, which is an element of assuring valuable requirements.  If a goal has value, you have to identify the set of user stories required to achieve the goal.  Those user stories therefore have value.  User stories that don’t support a goal don’t have value.

Valuable Requirements Meet Your Buyer’s Criteria

The people who buy your products are sometimes not the people who use your products.  Even when the same person is both buyer and user, that person’s mental model for buying is different from their model for using a product.  If you can’t convince someone to buy your product, it doesn’t matter how great it would have been had they bought it.

Here are the opening soundbites from an earlier article on buyer personas.

• Buyer Persona: If you build what he thinks he wants, he’ll come.
• User Persona: If you build what he actually needs, he’ll come back.

And the closing summary points (it’s a long article):

• Buyer personas make purchases when products appear to address their internal view of what the problems are.
• User personas love products when those products solve the real problems.
• Don’t confuse buyers (who need to buy products to solve user problems) with users (who need to solve their own problems).
• When buyers and users are the same people, acknowledge the buyer-goals distinctly from the user-goals.

There are also several really great insights in the discussion thread – including great comments from Shaun Connolly, Edele Revella, and David Meerman Scott!

Valuable Requirements Don’t Over-Solve the Problems

More is better, right?  Not always.  Sometimes, “more” is a waste.  There are really two ways to think about how much is too much.

The ROI of Incremental Improvements

Because of the law of diminishing returns, the next “more” is always worth less than the previous “more.”  Think of it in terms of improving fuel-economy.  If you have a car that gets 10 mpg, and you drive 100 miles a day, you have to buy 10 gallons of gas a day.  If you improve the mpg by 10 mpg (to 20 mpg), you’ll save 5 gallons of gas per day.  Huge value.  If you improve the mpg by another 10 mpg (to 30 mpg), you’ll save an additional 1.3 gallons of gas per day.  Some value.  Another 10 mpg buys you 0.8 gallons per day.  Diminishing returns.

The cost of achieving “more” is also a factor.  The simplified diagram above shows a linear representation of cost as a black line.  The diminishing returns of value are represented as the red curve.  The optimal investment point is where the two curves are tangent (have the same slope) – marked with the blue circle.  Less investment leaves money on the table – additional investment is done at a loss.

Good Enough is Enough

You don’t need to super-solve the problem.  How much more would you pay for a car that got 10,000 mpg than one that got 1,000 mpg?  If you drove 100 miles a day, the difference between the two (from a value standpoint) is trivial.  Over the course of 100 days, you would save 9 gallons total with the car that had ten times the fuel efficiency.

Why haven’t microwave ovens been getting faster every year? Because the move from a 1-hr baked potato to a 5-minute baked potato is good enough.  You don’t need to get it under 4 minutes.

This is known as satisficing - stopping when something is good, not trying to make it “perfect.”  Additional “goodness” will not result in enough additional sales to justify the investment.

Conclusion

The tagline for Tyner Blain is Software Product Success.  On an elevator, I explain that you have to not only “build stuff right” but you have to “build the right stuff.”  And the right stuff is the valuable stuff.

Define valuable requirements to make sure you’re building the right stuff.

Austin’s 3rd UnConference for product managers and product marketing managers is coming up on August 15t.  If you’re in Austin or can come to Austin, you should definitely plan on participating – it’s free, and a great opportunity to network, share, and learn.

ProductCamp – What Is It?

The first ProductCamp was started in the San Francisco Bay Area by Rich Mironov and the folks at Enthiosys in March 2008.  The largest one so far had 375 participants in the Bay Area, and the most recent one was last weekend in New York City.  As I type this, the ProductCamp Austin has 217 signups and 26 proposed sessions – less than a week after the announcement.

ProductCamp is a free, collaborative, unconference about product marketing and management.  ProductCamp is a bunch of smart, passionate people coming together to discuss, debate, and collaborate on the issues they face every day.  Everyone brings different experiences and leveraging that collective knowledge is what makes ProductCamp special – and something you can’t get anywhere else.

There are ProductCamps happening in more locations every day: San Francisco Bay, Austin, Toronto, New York City, Research Triange Park, Atlanta, Seattle, Boston, and maybe some more that I’m missing.  Someone created a web page that lists upcoming product camps (although it doesn’t provide any other information yet [if you're the owner of that site, comment below and let folks know how we can help connect the other city-specific sites to yours]).  There’s also a list of “all” past product camps on the barcamp.org wiki.  I know it is currently missing some of the events, but hopefully will emerge as the canonical list.  There’s also a newly created facebook fan page for all of the ProductCamps. It has a link to the Toronto ProductCamp fan page, and to the Austin ProductCamp fan page and hopefully soon, to any others that have been created.

If you know of a past ProductCamp that is missing, please update that wiki page (or contact me and I will update it).

Check out Paul Young’s recent article about Product Camp Austin and what to expect (if you haven’t attended one in the past).  Paul also gave a webinar yesterday about ProductCamp – with an introduction for new-to-ProductCamp people, and guidance for how to start a ProductCamp in your area.  You can download his slides and listen to the 40-minute audio track at the link.  Thanks to Ryma and Val Workman for hosting the webinar!

ProductCamp – How Does It Work?

Volunteers in each city put a lot of time into organizing the events, finding venues, soliciting donations to cover costs, encouraging people to participate, creating awareness of the events, setting up, tearing down, etc.  The event is free for people who attend – all that is asked is that people who attend help out.  Ideally, that means hosting a session (a presentation, roundtable, panel, workshop, etc) or participating in one; or it could mean helping out before, during, or after the session.

ProductCamp – What’s Going On?

There isn’t quite critical mass for any one site that aggregates all of the ProductCamp information.  This is an emergent phenomenon – and if you’re reading this after Jul 23rd 2009, the links above may not be the best ones.  For now, Twitter has emerged as the best way to see what’s going on with product camps.  The way to keep up is to search for hash-tags that the different product camps are using, find people who are tweeting about the product camps, and do some discovery leg-work.  Try searching Twitter for any of the following: productcamp, #pcamp, #pca09, #pct2, #pcampnyc, and certainly some others [add to the comments below].

ProductCamp Austin – How’s It Shaping Up?

As of this morning, for ProductCamp Austin Summer 2009 (main wiki page, facebook page, twitter search term, registration page, session-proposal page), we have 219 people registered, and 26 sessions proposed.  One thing we’re doing this year is capturing a demand signal from people as they register – specifically, what topic areas would they be interested in seeing presentations about.

We asked (are asking) people to select the three topic areas of most interest to them, from the list:

• Marketing
• Agile
• Requirements
• Product Strategy
• Career
• Other

Here’s a snapshot of the data at the moment:

Larger (and current) images of both graphs are maintained on the session-proposal page of the ProductCamp Austin Summer 2009 wiki.  This information is intended to inform the people who are proposing sessions – it is a demand signal.  There are no quotas by topic area, no requirement that sessions be in a particular area, etc.  Just information to help presenters pick a topic area (when they are undecided).

ProductCamp Austin – Finding Presenters

We’re driving participation “top down” because we’re creatures of habit.  However, what I personally believe will be more effective is for you to get people to host sessions at ProductCamp Austin.

• Do you know someone who is a great presenter with something to say about product management or product marketing?  Beg them to present.
• Do you work with people who have great insights about a particular area?  Bully them into participating in a panel (and volunteer to run the panel).
• Have you met someone who is facing a particular challenge and is looking for answers?  Convince them to organize a roundtable on the topic (and convince people with experiences to attend).
• Have you learned from someone who is a great teacher?  Cajole them into running a 50 minute workshop where people can learn something valuable and tangible.

Or of course, when you fit into any of these categories, volunter :).  And when asked by someone else, be flattered.  And say yes!

Paul Young (ptyoung on Twitter, Author of Product Beautiful) is the driving force behind organizing Austin’s product camps – thanks Paul!

User stories can make requirements management a lot easier.  They shift some of the communication from up-front documentation to ongoing dialog.  That’s the main reason they work so well for agile teams.  And agile teams focus on “what’s next?” instead of an ever-changing “what’s everything?”   The problem is, when those conversations are working well, it is easy to forget to make sure that what you’ve done is actually enough.  Add a small dose of traceability, and you can easily validate the completeness of your user stories.

Three Big User Story Problems

Over the last few years, Alistair Cockburn surveyed a range of teams and identified that they all were facing a similar set of problems.  Alistair proposed using use cases to solve those problems.  The following list of problems is Alistair’s:

1. Designers lack the context of the goal that the user is trying to achieve.
2. The team does not get a early indication of the scope of the project.
3. Alternate user-behaviors are not identified in advance of the commitment to deliver.

We agreed then (and still do) that well developed use cases can be used to address these issues.  Since then, however, we’ve done more analysis of how and when to create use cases and when to create user stories.  The primary drivers of the use case versus user story decision still apply, and should still sometimes point you to creating user stories.

Without the context of goals, and without a notion of completeness, your team just has a haphazhard stack of stories.  Not only will this reduce their motivation, but it will introduce frustration both for the implementation team and the stakeholders – no one will really know when the job is done.  Validating the completness of user stories will allow you to know (and regularly revisit) when you should be done.

When you are creating user stories, you need to be able to address the issues Cockburn identified.  You can do that with traceability, and a very small amount of additional documentation.

User Story Metadata

The cool thing about a well-written user story is that it already has metadata within it that makes tracing very easy.  A well-written user story, using a format based on the work of Mike Cohn (in User Stories Applied), would read:

As a [role], I want to [do something] [with some frequency] so that I can/will [achieve some goal].

If you were to build a UML Class Diagram to show the relationships that are implicit in a user story, you would get something that looks like the following:

[larger version]

• The [role] that starts a user story is the persona (lower right corner of the diagram).  For products with simple market strategies, identification of personas alone is sufficient.  Larger companies and larger products are often trying to address the needs of users in multiple markets or market segments.  Each persona you develop is in a single market segment.  You may organize your segments regionally or by vertical industry or any other strategy that helps you position your product.  You can manage your personas not only as members of market segments, but with a hierarchy of roles.
• The [do something] you identify is the meat of the user story (top center of the diagram) – what the persona is going to do.
• The [with some frequency] element tells your team how often a particular user story will happen.  This can be represented as an attribute of the user story.
• The [achieve some goal] component of the user story provides the context (center of diagram) for why a user will be performing an action.  The user will be performing the action either to achieve a user goal or a corporate goal.  If it is a corporate goal, it will have an internal stakeholder.  Ultimately, there should be an internal stakeholder who is not only the beneficiary of that goal, but also the person who “owns” the market segment in which the persona is defined.  Sometimes, there will be conflicts in goals, commonly between user and corporate goals.  These can also result in conflicting goals between internal stakeholders.

This is what makes things pretty exciting – all of that information is already there, and in your user story.  All you have to do now is leverage it.

Goals and User Stories

The following diagram shows how a use case exists to enable the achievement of a goal.

A user story can exist in the same way, just replacing the use case.  If you want to do a deeper dive into how interaction design and structured requirements work together, you can use the following model instead:

Note that the diagram above introduces a couple additional concepts.  The first additional concept is the practical goal – what the persona is attempting to do because it is the manifestation of a corporate goal.  ”Take an order quickly” is the practical goal that manifests the corporate goal of “Reduce time required to take orders.”  The second concept is that of a scenario.  A scenario is an amalgam of user stories (or use cases) that collectively allow the persona to achieve the practical goal.  We already represent this without introducing the scenario concept by acknowledging that a single goal is mapped to multiple user stories.

The common element in both approaches is a strong tie between goals and user stories.  Focusing on this aspect, you can visualize the relationship as follows:

[larger version]

Note that the acceptance criteria for each user story are called out (so that you can confirm that a user story is “done” and “done well”).  Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.  This is the crux of it, so I’ll write it again, but in bold for the busy people who scan this article.

Each goal is achieved by enabling one or more user stories, such that the acceptance criteria are met.

Note also that multiple goals can be supported by the same user story.

Validating Completeness

The important question that many developers (agile or otherwise) can not answer about their project is “If we do [everything we've been asked to do] will we meet our goals?”  This is either a failure in communication of context, or a failure to validate completeness of the requirements.  You have to flip things around and ask “If only these user stories are implemented, will the goal(s) be achieved?”  This is the same process used to validate completeness of use cases – just applied to user stories [Ed: that completeness-validation article was written 3 years ago today.  That's 28 years ago in internet time].

Incremental Overhead

Each user story already identifies the goal(s) it is supporting.  The incremental overhead is to recognize that this is “a backwards view” of goal satisfaction and create a simple table that shows the “forward view.”

You are creating traceability from each goal to each of its supporting user stories – but you’re doing it with a simple table (or list, or tree, or whatever).  You don’t have to manage your requirements in some big messy repository.  If you’re using index cards, consider getting some brightly colored sticky-dots, number them for each goal, and stick them on the index cards to show the relationship.

Then ask the question, for each goal, “Will this goal be achieved if all of the traced user stories (and no other stories) are completed, such that the acceptance criteria are met?”

An added benefit of this simple document is that it markedly improves your engagement with internal stakeholders.  You’ve created another opportunity for them to influence the scope of delivery.  These stakeholders can identify user stories that don’t map to any goals (you can drop those stories), and by identifying incomplete support, you can collaborate to make sure the missing user stories are identified.

The task of updating stakeholders about progress and managing stakeholder expectations just got much easier – because you can report progress in the context of completed user stories (and therefore manifested goals).

Reviewing Cockburn’s Issues

Does this approach address Cockburn’s issues (listed at the start of this article)?

1. Lacking the context of goals.  This approach explicitly emphasizes that context.
2. No early indication of scope.  The combination of completeness analysis and acceptance criteria provides concrete insight about scope.  Note that scope can still change, but this approach is just as effective as documenting requirements with use cases.
3. Alternate behaviors not identified early.  Completeness analysis will highlight when the “happy path” (a.k.a. the normal course in a use case) is not sufficient to achieve the goal.  This is really just a variation of the second issue (not understanding scope), but along a variation dimension instead of a coverage dimension.

Conclusion

There is value in being able to document requirements with either user stories or use cases as circumstances dictate.  Cockburn identified issues that teams face when dealing with decoupled user stories.  His approach of leveraging use cases to solve the issues is perfectly valid.  The approach outlined above, tracing user stories, also addresses the issues.  As a product manager or business analyst, you need to be able to address the very real issues with either documentation approach.

The maturity model approach to describing organizations and processes comes and goes out of fashion.  It is a repeating framework de jour.  In the game of agile jargon whack-a-mole, the agile maturity model is poking its head up again.

Agile Maturity Model

Ellen Gottesdeiner, author of Requirements by Collaboration, tweeted (@ellengott) a few hours ago with a link to an article proposing a set of maturity models.  She graciously passed on the opportunity to comment about the “agile maturity model” when pointing out her like of the collaboration maturity model.  The article proposed the following as an agile maturity model:

Agile Maturity Model (AMM)

0 – Dormant

1 – Speed: Focusing on being expeditious.

2 – Reactive: Focusing on acting relative to change from the perspective of the moment rather than a longer timeframe.

3 – Responsive: Focusing on acting relative to change from the perspective of the moment balanced with a longer timeframe.

I didn’t find it to be a particularly useful model.  Although descriptive, it won’t help your organization improve.

What Does Maturity Mean?

I wrote a series of articles a couple years ago that explored the CMMI and RMM – the capability maturity model and the requirements maturity model.  These are two different models that use maturity as a concept for articulating different levels, or grades (or enlightenment, or rigor), with respect to organizational behaviors.  At the time, there was both momentum and confusion around the notion of a requirements maturity model.  CMMI is a description of an organization’s rigor in “saying what it does, and doing what it says.”  RMM is an assessment of the level of critical thinking incorporated into the ways an organization is using requirements to develop products.

The problem is that people were incorrectly assuming that an organization “at level 4 CMMI” would approach requirements management at a comparably enlightened level.  The problem is that they are putting entirely unrelated concepts into similarly named classifications.  An organization could be at CMMI 1 and RMM 4 or RMM 2 and CMMI 3.  That series of articles explored what it would mean to be in any of the combinations of “maturity” for those two models.  Check out all the articles in the series if you want to put it all in perspective:

• Foundation Series: CMMI Levels Explained
• What CMMI Level Should We Use?
• CMMI Levels and RMM Introduction
• CMMI Levels and RMM Level 1 – Written Requirements
• CMMI Levels and RMM Level 2 – Organized Requirements
• CMMI Levels and RMM Level 3 – Structured Requirements
• CMMI Levels and RMM Level 4 – Traced Requirements
• CMMI Levels and RMM Level 5 – Integrated Requirements
• Don’t forget to take our One Minute Survey on CMMI and RMM.

Making a Maturity Model Useful

Why bother with a maturity model?  Not so you can “keep score” relative to others – rather, so that you can improve your own organization.  For a maturity model to be useful, you have to be able to do two things.

1. You must be able to determine where your organization is in the model.
2. You must be able to identify actions you can take to “improve” your organization relative to the model.

If you can’t measure maturity, and the model does not provide guidance about how to improve, it’s useless.  One challenge with maturity models is that they risk becoming contextually narrow in their application.  The more concrete a measurement or suggestion becomes, the less extensible it is likely to be.  Ideally, your model would be broadly applicable to many organizations.

With an agile manifesto that emphasizes people over process, it is ironic to consider applying a metric that measures your agile process.  So – goal #1 is immediately undermined.  Goal #2 – improving your organization, is, however, very valuable.

Improving An Agile Process

I’ve worked in several agile environments, both as a practicioner and as someone helping to transform organizations to become agile (or better at agile).  I’ve worked in enterprise software, helping large teams adopt agile processes; with a SaaS consumer product team, and in large IT departments with collections of teams adopting agile processes at varying paces.  I’ve played on both sides of the fence (delivery/QA & product management/ownership).

Going from zero to sixty on agile is a big task.  You can’t solve all of the organizational, practical, and interpersonal challenges at the same time.  Or at least you would be more effective tackling and resolving each issue in sequence.  In fact, you should solve the most important / largest problem first – then move on to the next, and so on.  You can call it agile agile adoption, or you can call it eating the elephant.

One powerful use of a maturity model is highlighting the next-biggest hurdle you have to overcome.  Unfortunately, most communication about maturity models is “look which hurdle we just overcame” – but the focus should be on “what’s next?”

When helping organizations be effective with agile processes, there are some clear “you have to overcome this first” challenges, that if unresolved, make other challenges irrelevant.

If you’re a software developer, I’m sure you’ve experienced the following scenario:

• A bug is reported.
• You fix the bug, and write some tests to prevent it from reoccuring.
• While testing, you discover another bug that was hidden by the first bug.

Fixing that second bug doesn’t do any good until you’ve fixed the first one.

If you’re a product manager or business analyst, think about it in terms of capability enhancements.  Is a faster search important if the current search algorithm is not returning the right results?  Get good results first, then make it faster.

You have to solve the biggest/closest/roadblockiest issue first.  Then move on to the next issue.  That’s how you should use a maturity model – as guidance about “what’s next?”

When assessing / improving your organization’s ability to be agile, you need to be addressing whatever is next.

What’s Next?

Let’s discard the “maturity model” notion and focus on “what’s next?” instead.  And that of course starts with “what’s first?”  Here’s how I’ve presented an agile hierarchy of needs to in the past:

1. Staffing the engineering team correctly.  People over process is the right emphasis.  If you can’t find people that are “good enough” you might as well go home.  Doesn’t matter how agile you are if you don’t have the horsepower.  You also need people who are excited to “do agile” – they like to communicate, they enjoy the project and team dynamics of an agile process.  You’re also better off with specializing generalists – ideally, every member of the team can do any work that is needed.  This is an efficiency play – you risk introducing bottlenecks when you have a specialist who is the “only one” who can do particular types of work – because you will not have a consistent mix of types of work from release to release.
2. Assuring Quality is in your team’s DNA.  Arguably, this is part of what’s first, but there are a lot of teams that get cood at cranking out code, before they get good at cranking out good code.  Continuous integration is the approach you must have.  Test-driven development, spec-driven development, and other testing-integration approaches are extremely important, but are really reflective of different flavors of agile and quality, not different degrees.
3. Reducing overhead in the release process.  There’s a cost associated with releasing a product.  Once you get good at releasing, and are releasing good product, your next focus is on finding the right release cadence.  There are three factors that essentially dictate your release frequency.  The size of atomic deliverables (user stories and use cases, non-functional requirements, etc) your team is creating, the overhead (time and cost) of releasing, and your customer’s capacity to consume the releases.  My anecdotal experience is that teams are usually constrained initially by the cost of releasing – dedicated hours to creating a build, code freezes, etc.  Automating the build process (to reduce both costs and errors introduced while building) is first.  Integrating automated build and automated test processes together is next.
4. Feeding the beast.  Once you have an engineering / delivery team that is operating efficiently, you run into the problem of making sure they have enough important work to do.  There’s pressure on product owners and  product managers to schedule something because it is easy to define, not because it is important.  It is also important that the team understand the context and importance of what they are doing.  So you have to focus on making sure your product management team has enough capacity to keep the engineering team busy on delivering really valuable stuff.  The “right” solution to this depends on how the problem manifests in your organization. Is your product manager spread too thin across multiple products?  Too junior?  Too bogged down in sales support or trade show attendance or or or?
5. Managing stakeholder expectations.  A big challenge in changing an organization to become agile is in resetting and managing the expectations of stakeholders.  Execs are used to having an annual budget exercise where they dedicate X dollars in the pursuit of Y objectives.  We’ll set aside the reality that they’ll only achieve 1/3 of the objectives, at 2X the cost, much later than originally forecasted.  We aren’t looking at the failings of waterfall, we’re looking at the risks of agile.  There’s a ton of stuff here, from doing damage control to reverse perceptions that “people who want to do agile just don’t want to be accountable” or addressing the “we can’t tell you what X dollars gets you” message.  Again – the particular solution is a function of how the problem manifests in your organization.  Once your team is delivering valuable stuff efficiently, you have to make sure your management team is happy and engaged and knows what to expect.
6. Continuously learning from your markets.  This is really what differentiates an agile organization from an organization with an agile development team.  Agile processes do enable you to develop code more efficiently.  If you aren’t taking advantage of the faster development, feedback loops, and ability to change that agile enables, you’re leaving money on the table.  And one of your competitors will pick it up.  There’s a whole community of MBAs that talk about business agility without once thinking about software development.  They’re talking about an organization’s capacity for rapid response to changing market conditions.  It’s what separates the winners from everybody else.  And agile development makes business agility possible.  As long as your team is able to identify and value industry trends, competitive threats, and market opportunities.  When you’re good at this, you have an agile organization.  And you win.

Conclusion

Any agile “maturity model”, irony aside, needs to be structured to help organizations progress through the stages of enlightened operations – continuously providing insights into “what’s next?” for those teams to grow.

I know there are many readers here with years of agile experience – how would you improve the list above, to better provide a framework for “what’s next?”  When that framework is solid, we can do some wordsmithing and repackage it as a maturity model.  Until then, just focus on “what’s next” – that’s all a maturity model should be used for anyway.

When defining requirements, you always start in the context of a goal – either a user goal or a corporate goal.  You need to be aware of both.  Having a positive user experience is important, and requires a user-centered understanding.  Achieving your corporate goals might be in conflict with some user goals.

User Goals

A user centered, or user-centric approach to developing software is one where you start by identifying the key persona in your target market.  For each of those personas, you identify their most important goals.  You then identify the user stories or use cases that represent the things these people do in order to achieve their goals.  These “things” are manifested as practical goals.  For these activities, you design user interfaces (process, layout, architecture, look and feel, etc) that create customer delight for those users, doing those things.  This is how your product exceeds the suck-threshold (good enough that it doesn’t suck to use your product).

Corporate Goals

There’s a reason your company is creating or improving a product.  It may be to gain market share, or improve profitability, or increase sales.  Whatever it is, there’s a corporate goal that your decisions should be supporting.  The (subset of) corporate goals that are relevant to your product could be communicated in a vision and scope document, that constrains the domain of problems to be solved, and provides nuanced insights into viable approaches to solving them (example vision and scope).

Corporate goals are achieved when customers do things with the products.  These “things” are manifested as practical goals.  For those activities, you document what should be accomplishable and why.

Alignment and Conflict of Goals

Notice that both the user goals and corporate goals manifest in terms of people doing things.  When the person (user) wants to do the same things that your company wants them to do, you’re in alignment.  When the user goals and corporate goals suggest different activities, you’re in conflict.

You can see visually that these worlds collide at the “practical goals” stage  in the following diagram, from an article on combining interaction design and structured requirements principles.

It may be great – when the user and corporate goals are in alignment, the practical goal and associated scenario (activity) are easily defined.  What about when the goals are in conflict?

Vending Machine Example

Last Thursday morning, as I interacted with a vending machine, the idea for this article was dispensed along with my Diet Mountain Dew.  Yes, I know that’s odd.  Move on.

It occured to me that the process of buying a cold, caffeinated beverage can be both aligned and unaligned from the perspective of user and corporate goals.  If you imagine writing a use case for purchasing a beverage from the vending machine, your most important scenario is the one where a person wants to purchase a beverage that is available in the machine.

• User Goal: Get refreshed and vitalized.
• Corporate Goal: Sell a beverage.

I want to buy a Diet Mountain Dew, as a means to realize my personal goal.  The owner of the vending machine wants to realize her corporate goal of selling me the beverage I want to buy.  We’re in alignment.  Our requirements definitions and design decisions will be pretty easy – everything that increases the likelihood of and improves the experience of purchasing that beverage is good.  I put my money in the machine and push the button.

Then it occurs to me – there’s a situation where my personal goals are clearly not aligned with the corporate goals of the vending machine owner.  When there is no Diet Mountain Dew available to be purchased.

Consider the following procedure I’m forced to endure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I put my money in the machine.
3. I push the button for Diet Mountain Dew.
4. The tiny display on the machine presents a message in taunting, scrolling red LED lights: SOLD OUT.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

Consider an alternate procedure:

1. I view the available beverages that this machine dispenses – Diet Mountain Dew is one of them.
2. I view the ‘current availability’ of Diet Mountain Dew and see that this machine is currently sold out of Diet Mountain Dew.

At this point, I’m faced with a choice – select a less desireable beverage, or request my money back and try to satisfy my user goal in some other way.

The differences in these two possible procedures indicate that there is a conflict between the corporate goal and the user goal.  With the first procedure, the “Sell a beverage” goal is given more importance, because it makes me more likely to purchase a beverage that I don’t particularly want.  My utility is potentially sacrificed, while the owner of the vending machine is just as satisfied.

By failing to tell me that I can’t get what I want, until I’m further invested in the process, I am more likely to purchase something else.  That purchase creates just as much value for the owner of the vending machine, but less value for me.

If the vending machine owner had allowed me to use the second procedure, it would demonstrate that the  owner believed the improved customer experience, while risking the loss of this sale, would encourage me to purchase more over time.  The owner would have been prioritizing the requirements and design that supported the user goal ahead of those supporting the corporate goal – in hopes that my user loyalty would result in better word of mouth (more business from other people) and more business from me over time.

Generalizing User and Corporate Goal Conflicts

In this vending machine example, the annoying procedure is probably the right one – I’m going to treat the “point of use vending of cold, caffeinated beverages” as a commodity product.  This market has a very low barrier to entry, and relatively small problem being solved.  I’m not going to tell my friends about how much I love the vending machines from Joey’s Vending and encourage them to go out of their way to find and use those machines.  Nor will I purchase more Diet Mountain Dew because the emotional cost of the occasional “sold out” scenario is trivially smaller with Joey’s machines.  I would, however, be more likely to buy a Diet Pepsi when I’ve already invested time in the process and put my money in the machine – especially when the alternative is to find a water fountain.  I’m emotionally invested at this point.

However, this experience did jump out at me as one that is worth explicit consideration when defining requirements and designing solutions.  It does come up regularly.

The new iPhone 3GS hardware allows tethering (using the phone as an internet-connection device for your laptop).  ATT (the exclusive carrier for iPhones in the USA) is indicating that they will charge customers an extra monthly fee for this capability, when they eventually allow it on their network.  The user already has a data plan, and the traffic that ATT would have to carry is just “data.”  The user just wants it to work.  ATT, however, may want more money, or may want to limit data traffic on its network – perhaps to improve the quality of service to all customers.  This could be ATT’s corporate goal of “provide better service quality” conflicting with the user’s “increase the flexibilty of how I use my data plan.”  The former would likely influence customer satisfaction (and abandonment) over time, while the latter would influence customer acquisition rates.  Another conflict in goals.

Think about how different goals can lead to conflicting solutions, requirements, and designs.  And tell me when you’re out of Diet Mountain Dew before I’m emotionally invested in the purchase.

Creating a PERT estimate for a single task is both easy and straightforward. Creating an estimate for a set of tasks is still easy, but requires a little bit of math. Combining PERT estimates for tasks is easy, but not as obvious. Roll up your sleeves and dive in.

PERT Estimate Refresher

When estimating how long it will take you to complete a task, you shouldn’t estimate with a single value like “four hours.” “Four hours” does not provide enough information. Estimates reflect that there is uncertainty, and that single value does not give you any insights into how uncertain your estimate is. Your estimate could be “four hours plus or minus one hour” or it could be “at least four hours, maybe as much as sixteen hours.”

A PERT estimate, as we showed in our earlier PERT estimation article represents a distribution of likely effort for a particular task. To create a PERT estimate, you create three values -

1. The “best case” (shortest) amount of time it will take to complete the task.
2. The most likely amount of time it will take to complete the task.
3. The “worst case” (longest) amount of time it will take to complete the task.

A PERT estimate is presented in the form “Best Case / Most Likely Case / Worst Case.” If your estimate is “four plus or minus two hours” you would write 2/4/6 as a PERT estimate. Sharing “2/4/6″ as an estimate still doesn’t tell anyone else what you mean. A PERT estimate embodies some probability around completion time. You are precisely saying (for a 2/4/6 PERT estimate):

1. There is a less than 1% chance that this task will take less than 2 hours.
2. There is a 50% chance that this task will take less than 4 hours.
3. There is a greater than 99% chance that this task will take less than 6 hours.

This explicit statement of probabilities represents a distribution of likely outcomes. Statisticians would phrase it in a confusing (but mathematically important) way. They would say “if we sampled a large population of people (like you) doing this task, no more than 1% of them would complete the task in under 2 hours, no more than 1% of them would spend more than 6 hours on this task, and half of the people would complete the task in under 4 hours.” For the purpose of estimation, you can ignore the statistic-speak and just look at the “odds” of how long it will take you to complete the task once.

[larger image]

If you were to create a histogram of thousands of executions of the task, it would look like the diagram above.  This is the traditional bell curve shape we are used to associating with a normal distribution, but it actually represents a PERT estimate.  A PERT estimate is a distribution of possible outcomes, based on a beta distribution.  Another way to look at a PERT estimate is in terms of cumulative probability of a task being completed.  The same data in the graph above, when presented as a cumulative distribution function (CDF) looks like the following:

[larger image]

Here’s the rub – you don’t really know if the beta distribution is the right one.  Primarily because you can’t precisely know the actual probabilities.  So, you have to pick a distribution function to represent those probabilities.  There is debate about the right distribution function to use for estimation – check out this great article for hard core stats guys.  Here’s a cautionary warning from their conclusions:

Although bias stemming from misspecified activity time probability models is rarely mentioned in introductory discussions, we have seen several instances of this bias in simple examples. First, and perhaps most important is the uncertainty as regards the underlying activity time probability models. The literature offers no less than five procedures for translating the subjective estimates (a,m,b) into specific β-distributions. As shown, the methods lead to distinct β-distributions, and the PERT approximation need not satisfactorily estimate any of them.

Essentially, they are saying “you can’t really know the right shape for a distribution curve of possible outcomes – so don’t get carried away.”  And they then go on to suggest using a simpler model than the beta distribution for estimation.  Their suggestion is to use a triangular distribution (looks like a triangle, instead of a bell curve), because the math is easy.  With spreadsheets, we can still do “easy” math with a better distribution

The beta distribution for a symmetrical PERT estimate looks very much like a normal distribution.  You can see this by comparing the cumulative distribution function of the PERT and normal models for this 2/4/6 example.

[larger image]

Based on this similarity in distribution, and the inherent uncertainty in what the shape of the distribution really looks like, there are some benefits to treating the PERT estimate (2/4/6) as a normal distribution where the high and low values represent +/- 3 sigma bounding.  This approximation provides us some benefits when aggregating individual task estimates into combined project estimates.

Continued on the next page…

For you product managers out there – here are a couple upcoming productcamp unconferences.  For you business analysts, here’s an excuse to do a little domain modeling and practice your UML class diagram skills.

Upcoming ProductCamps

There are at least four productcamp unconferences coming up in the near future.  I’ve been able to attend (and host sessions at) both of the productcamp Austin sessions, and they were great.  If you can make it to a session near you, you definitely should.  And if you go, you should help out – these are entirely free, and their quality directly relates to the amount of volunteer support that the attendees give.

1. ProductCampNYC – Jul 18th 2009 @ The Downtown Association, New York City, NY.  More info.
2. ProductCampAustin – Aug 2009 (exact day and venue TBD).  More info.
3. ProductCampToronto – (everything TBD).  More info.
4. ProductCampSeattle – Oct 10th 2009 @ Amdocs.  More info.

Check out the comments on this article too – as updates happen in different cities, I’m sure folks will post them here.

[Note: I updated the venue for the NYC product camp on 10 Jun 2009]

If you’re on twitter, you can search for #pcampnyc, #pca, for NYC and Austin productcamp info (respectively).  Or follow @ProductCampNYC.

Session Planning

One of the interesting things about productcamp is that it is a barcamp-style unconference.  That means it is free, and in theory, there is no centralized planning of sessions.  However, there’s a lot of planning that goes into having these unplanned sessions.

Roger Cauvin is one of the volunteers helping to organize the next productcamp Austin, with a focus on sessions.  He and I met over some seriously tasty Greek food at Tino’s Greek Cafe in Austin yesterday for lunch to begin planning for the sessions.  Our discussion focused around how the attendees will best benefit from the sessions, and what we can do to maximize that benefit.

One idea that came up was looking at addressing the frustration that people feel when there are two simultaneous sessions that they want to go see.  At previous productcamps, we used a very simple, on-the-fly scheduling approach:

1. We created index cards for each session and stuck them on the wall.
2. Each person had a few (3?) sticky notes, and stuck them under each session card.
3. The ones that got the most were lined up in the same room (to reduce conflicts in the popular sessions).
4. The rest of the sessions filled up the room/time slots without any particular optimization.
5. We did this sequencing in a couple minutes after everyone quickly “voted” with their post-it notes.

We learned, from “customer” feedback from the first two sessions that there is room to improve:

• People were still expressing frustration about “good session” conflicts.
• We also noticed a drop-off in attendance as people left before the end of the day – more attendees for earlier sessions.

So, if we’re going to improve session planning, one of the things we need to do is understand the details of sessions.  This is where domain modeling comes in.

We can create a UML class diagram that represents the domain of planning for (and attending) sessions.  This serves as an example of applying the business analysis techniques to gain insight into a problem domain before attempting to define a solution.

We know the following things about the domain:

• There are a limited number of rooms available for sessions.
• There are a limited number of time-slots available for sessions.
• Each session has a topic and presenter(s), and happens in a single room at a single time-slot.
• Each session has multiple attendees.
• Each attendee wants to attend multiple sessions.
• Each attendee has a prioritized list of sessions they expect will benefit them if attended.
• Each attendee can only attend one session per time-slot.
• Each attendee wants to maximize the benefit that they get from the productcamp.

[larger image]

The diagram above shows the relationships that will inform the design of any solutions.  For more on how to create UML class diagrams, check out our tutorial series on domain modeling.  One challenge of domain modeling is that there are often multiple ways to represent the same relationships.  With a goal of “understand the domain” – how would you model this differently?