The Laudi Group and Red Canary organized and shared a great set of questions for product managers and answers from a panel of product management leaders.  Steve Johnson, another leader in our space shared his answers to the same questions, and in this article, I share mine.

The Product Manager Questions

Hat tip to Steve Johnson at Pragmatic Marketing, for extending the discussion and providing his answers to the questions.  And thanks to the folks at Red Canary and the product managers who originally shared their answers.

I really enjoyed reading their answers – thanks to all of you!

Here are the questions that were put forth and answered:

1. Tell us about the best product you’ve ever encountered.  Why do you like it?
2. How do you know a great product manager when you meet one?
3. What’s your favorite interview question?
4. When is the best time for a start-up to hire a product manager?
5. What has been the defining moment in your career?
6. Mistakes.  What was your biggest?

I’ve personally enjoyed and grown from the great writing that many product managers have shared with us over the last few years.  I’d love it if they would share their answers.  So, either share your answers, or pester your favorite writers to share theirs.

Without further ado, here are my answers to the same questions.

Why Do You Like the Best Product You’ve Ever Encountered?

I love when products solve obvious (in hindsight) problems with elegant designs.  The products where, once they exist, you say “well, duh” or slap your head and ask “why didn’t I think of that?”  These innovative products tend to be disruptive, redefining markets.  Some of the products are rather mundane – like the ketchup bottle where the lid doubles as the base (reducing waste and preventing countless red-water-stained buns).  Other products are more technology-dependent – like Tesla’s radio, xerographic photocopying, solid-fuel rockets.

I think my favorite for elegant design might be Velcro – if you don’t know how it works, or just want to know how it was invented, check out the wikipedia article.  The time that parents save tying tiny shoes is value enough, but it is far from the only (or first) use of Velcro.  An accurate clock that could be used on board a ship was a biggie too, although I never personally encountered one, at least when it mattered.  Accurate time-telling on a ship was the key to dramatically improved navigation back in the days of sailing by the stars.

How Do You Know a Great Product Manager?

Great product managers are polymaths, with several areas of deep expertise and skill.  They are Renaissance women and men, with many areas of interest.  They are great communicators.

Most importantly, they are sooth-sayers.  By the last, I mean that they not only understand the big picture and context of their markets and their business, but they know what is likely to change their business, and where their markets are sensitive to or ripe for disruption.  One definition of sooth-sayer is “one who tells the truth.”  You can’t do that without data, and the ability to understand what the data is telling you.

Add to this a dash of humility and a full dose of open-mindedness, and you have a great product manager.

Of course there’s all of the esoteric skills that the role requires.  When they aren’t present yet, I feel like I’ve met a great product manager to be.

I know it when our conversation rambles all over, goes “depth charge deep” in areas, and then bounces back to the broad view, all with an eye for the relevance and insights that matter for the topic at hand.

What’s  Your Favorite Interview Question?

“Why?”

I almost don’t care what the context of that question is – reviewing a candidate’s previous experience, asking them to provide a “fresh view” on my current situation, or convincing them to dance through a hypothetical situation.  What I want to know is why they think there is value, or a problem , or an opportunity, or … whatever.  A collection of well-dispersed, and sometimes-immediately-sequential “Why?” questions can tell me more about how someone thinks, and more importantly, how they are likely to solve problems, create solutions, and dominate markets than any other question I’ve found.

When is the Best Time for a Start-Up to Hire a Product Manager?

Not counting the founder?

Three to six months before the first product peaks.  All successful start-ups have one good product – solving a single valuable problem, for a single market.  Most (my opinion / observation) start-ups don’t have a second good product or market.  A passionate and insightful founder can spend a long time understanding a market, a problem, and a solution.  That knowledge and passion can yield a successful product.  When is that founder, who is busy running the company, going to find a new problem to solve, a new market to dominate, or a new solution to replace his original idea?

Alternately, I guess the founder can hire someone else to run the company, and anoint herself “president of the product.”  That still counts as hiring a product manager.

What Has Been the Defining Moment in [My] Career?

Switching from electro-mechanical design engineering to software development.  The shift in innovation time scales, the different approach to problem solving, and the markedly different economics of product creation had a profound effect on me.  The evolution from “creating solutions to (defined) problems” to “identifying problems worth solving” was more gradual, as I evolved into a programmer-analyst and consultant and product manager.

“Going agile” half-way through my software development career was pretty eye opening too.  I’ll throw that in as my backup answer.

Mistakes.  What Was [My] Biggest?

From someone else’s perspective, it was leading a team down a six-figure software-development path that solved a problem no one really cared about.  That’s probably defining-moment number 3, when I started including validation of value as part of my scope of engagement as a programmer.

From my own perspective, as they say, it’s the train you don’t see that hits you.  I’ll guess that it was something I didn’t do, not something I did, that would turn out to be the key plot device in my Frank Capra movie.

I came across a really interesting article LukeW.com, showing how making changes to the way an input form on a website increased interaction by 25 to 40%. The changes reflect the value of thinking outside-in, investing in user experience, and performance measurement.

Bonus: the idea is cool.

Mad Libs Input Form

[full size image available in Luke's article]

The idea being presented is to replace the old boring web input form designed for a computer. The new, fun form is a fill-in-the-blank (aka Mad Libs) layout. The article is on Luke Wroblewski’s site.  The team at Vast.com created and tested a version of this form for the Kelly Blue Book site. [Luke cites Huffduffer.com as the first place where he saw this technique.] Thanks, Luke for sharing this with all of us!

Outside-In Development

Product managers are acutely aware of the need to solve market problems. We are regularly reminded that we’re creating solutions for people in our markets who use our products to solve their problems. When we write requirements, we avoid writing design specifications, and thereby lose the ability to enforce that the proposed solutions also take an outside-in approach. We maintain an outside-in perspective, but we lost the ability to influence an outside-in aesthetic.

Note: Outside-In Software Development is a great book, you should read it.

That’s one area where user experience works well in concert with product management – assuring that the same drivers of what to build are informing the design of how it is built.

The genius (or at least elegance) of this Mad Libs form from Vast / Kelly Blue Book is that it humanizes the experience of requesting that a nearby dealer contact you to discuss a possible purchase of a car from them. The forms we’ve all had to fill out on countless web sites are very inside-out. They expose the inner workings of the program – “gather this info, and that info, and this other info.” Those forms force users to do what the program wants. Blech. The form that Ron Kurti designed, however, forces the program to do what the users want. Huzzah!

Bad Requirements Prevent Elegance

I’ve written about the importance of writing design-free requirements several times.  Avoiding design constraints in your requirements is even one of the pillars of the big 10 rules of writing requirements.

If you had written the requirements for this contact the dealer page, would you have specified the design of the form?

Most of the requirements analysts I’ve worked with would have. I’ve even worked with companies that have developed templates / stencils defining how these interface specifications must be documented – requiring that all the fields be aligned, with specific pixel gaps, etc.

If you had specified the design (read: limited the choices of the designer), you would have prevented this solution.

Mr. Kurti’s elegant solution is clearly better.

One way to write the requirements that would not have prevented this solution would be with a user story and acceptance criteria:

As a car-shopper, I want to engage a car dealer, once every few years, so that I can purchase the car I selected.

• The car-shopper can provide his contact info (name, email, phone) for the car dealer.
• The system will display the information identifying the selected vehicle.
• The system will display the information identifying the dealer being contacted.
• The system will include an opt-in newsletter-subscription option.
• The system will notify the specified dealer when the car-shopper indicates.

The user story nudges the developers into an outside-in perspective by emphasizing the user’s goal. The acceptance criteria make it clear that any solution that meets those criteria is acceptable to the product manager. It allows the interaction designer to create a compelling solution, rather than forcing him to recreate a boring experience.

Measurement Rocks

The Vast team measured the impact of making this change to their form, and saw between a 25% and 40% increase in conversion (people contacting dealers versus people abandoning the process when they see the form). That’s a lot more leads for the dealers, and presumably a lot more money for Kelly Blue Book and Vast. This is a great example of how you can measure the impact of investing in user experience, because it should spark ideas for you.

What can you measure and test and improve?

Now that’s ROI for you.

You give your requirements to the engineering team, and they look complete.  The team builds your product, you launch it and the market soundly rejects it.  Why?  Because your requirements weren’t complete – they didn’t actually solve the problem that needed to be solved.

Complete Requirements – Revisiting

Going back almost four years, I wrote Writing Complete Requirements, as part of the Big Rules of Writing Requirements series.  That article centered on two key ideas of requirements completeness.

• Data, not opinion, is the most important input into determining completeness.
• There is no absolute way to determine the completeness of your requirements in advance.

Completeness is best measured by market acceptance, so technically you can’t know if your requirements were complete until your customers buy (or fail to buy) your product.  This doesn’t mean you should give up on this rule of requirements – you can still focus on, and improve, the completeness of your requirements.

Objective and Heuristic Assessment

Given a market problem and the associated requirements (which you can argue are actually the same thing), you can review those requirements to determine if they objectively appear to be complete.  This assessment is based on what you objectively know about your market (needs, opportunity costs, competitive alternatives, etc).  You can also apply heuristic, or logical analysis to identify gaps in the language of your requirements.

Objective assessment is the application of market knowledge (data) to determine if the nature of the problem is being addressed completely by your requirements.  A bird-feeding maven would know that the requirements for your bird feeder would be incomplete if they didn’t address the problem of squirrels stealing food from the birds.

Heuristic analysis is the identifications of logical omissions in your requirements, without the need to apply market insights.  A logician would know that the requirements for your bird feeder were incomplete if they didn’t address the need to refill an empty feeder.

When you’re writing requirements, you need to do both.  Heuristic analysis of your requirements will identify where your requirements do not fully solve the problems you already know about – an eCommerce checkout process without the ability to receive payment, for example.  Objective assessment will help you identify the problems that you overlooked but need to solve – the need to allow customers to have different billing and shipping addresses when placing an order online, for example.

Complete Requirements for Incomplete Solutions

Don’t confuse having complete requirements (a good thing) with completely solving a problem (not always a good thing).  In agile development, the idea of satisficing is key to scoping individual iterations.  The idea, simply put, is to solve enough of the problem, and not delay delivery (and value) until you can build a solution to the entire problem.  Because of the law of diminishing returns, for many market problems, there is little or no incremental value in solving the entire problem.  Those resources can be better applied to solving additional problems.

Kano analysis provides a framework for identifying which market problems must be completely solved, and which ones have a more is better characteristic.  In practice, more is better problems exhibit the law of diminishing returns, and should not be “completely” solved.

[larger image, or view the entire Kano analysis presentation]

Conclusion

Complete Requirements are requirements that

• Identify all of the market problems that need to be solved and their nature (absolute vs. diminishing returns).
• Are logically complete in their coverage / articulation of those market needs.

To objectively improve the completeness of your requirements, apply market data in an assessment of your requirements.  To heuristically improve the completeness of your requirements, look for logical inconsistencies and gaps in reasoning or coverage.

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

Deep Dives

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

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

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

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

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

OK Stewart, that’s only 519 words.

Why does cross-selling, the process of selling something additional to someone who is already making a purchase, work?  This article explores some of the theory and rationale behind cross-selling – from qualification to motivation and profitability.

Cross-Selling is Big Business

You have an eCommerce site where people purchase products from you.  Adding cross-sale capabilities to your site can have a significant impact on your bottom line.

The e-tailing group’s 2009 report shows (by survey of eCommerce executives) that 55% of online retailers will include cross-sell and upsell capabilities in their sites in 2009 (already there or being added).  For retailers that measure the data, cross-sale promotions result in a range of conversions (additional sales) from under 1% to over 10% – with a plurality of responses in the 1% to 4% range.  That represents additional revenue the retailers would not get without using cross-selling.

According to the Get Elastic blog, Amazon reported that cross-selling accounted for 35% of their 2006 revenue.

Understanding why cross-selling works requires understanding customer’s purchasing processes work.

Customer Purchase Process

The following is a model for how customers make purchases.

• Customers start by thinking about their problem – what problem are they trying to solve (with a purchase)?
• Some people will try and understand the problem space, while others are happy to jump to solutions.
• Understanding the solution space (what are my options?) is next – and may be a shallow or deep analysis.
• Within the solution space, customers will select a product and decide to buy it (from you) or not.
• Customers who reject their first product choice may select another product or may abandon your store.

You can take a higher-level view of these customer activities and decisions, and categorize them into areas:

• Learning - Your customer is learning about her problem and possible solutions.
• Choosing - Your customer is comparing possible solutions, with the intent to purchase one of them.
• Buying - Your customer has selected a solution, and is trying to buy it.

Customer Qualification

In direct sales, one of the first steps a sales rep will take is to qualify a prospective customer – how likely is this prospect to make a purchase?  A similar model can be applied, when treating your website as a sales rep, to understand how likely it is that a visitor to your website will make a purchase.  There is a ton of additional qualification (assessing a prospect’s ability to pay, for example) that we won’t talk about in this article.  In this article, we’ll focus just on this simplified purchasing model:

• Customers who are learning are more likely to buy than visitors who are browsing (window shopping).
• Customers who are choosing are more likely to buy than customers who are learning.
• Customers who are buying are more likely to buy than customers who are choosing.

That last bullet seems silly – of course customers who are buying are more likely to buy – like 100% likely, right?

Wrong.

Prospective customers abandon the buying process all of the time.  SeeWhy reported ~70% abandonment rates during 2009’s post-Thanksgiving online shopping spree.  They also used the phrase “a relatively healthy 63%” to describe abandonment rates in August 2009.  SeeWhy is specifically measuring abandonment of the shopping cart (inside the “buying” area), but there is abandonment (often called leakage) throughout the process above.

The further a customer is into the purchase process, the more likely they are to actually make that purchase.

Clearing Hurdles

As a customer moves through the purchase process, they are clearing hurdles that would prevent them from making the purchase.  Each time they clear a hurdle, the pending “mental cost” of making the purchase gets smaller.

One of the hurdles is making a decision to purchase now, another is making the decision to purchase from you.

Offering cross-sale promotions to customers who have already (probably) decided to purchase from you, now, means that you’re offering the promotions to customers who are qualified.

Relevance

A defining element of a cross-sale is relevance.  You’ve got a customer who is purchasing a product, to solve her problem.  You want to increase the value of the transaction – both for your customer and for yourself.  To do that, you have to offer a relevant cross-sale item.  Selling french fries with a sandwich makes sense.  Selling car wax with a new car makes sense.

Selling car wax with a sandwich?  You probably won’t have a lot of success with that.

How do you determine relevance?  You can start out with an “expert opinion” – car wax is relevant to cars, for example.  Or you can do some data mining of past orders – “7% of people who bought cars also bought car wax.”  That lets you start out with a hypothesis (that car wax is a relevant cross-sell item for purchasers of cars).  If you’re data mining past orders, however, you may not know the direction of the cross-sell.  Cross-selling works because the two products are complementary goods – usually asymmetric complements.

Complementary goods are rarely symmetrical.  Peanut butter and jelly is a good example of symmetric complements – they have comparable price points, and both generally can be improved by purchase of the other.  In the mixer-cookbook example above, the cookbook is a great complement product for the mixer.

However, if your customer had selected the book initially, the encouragement to “add a stand mixer” would fall on deaf ears.

Foundation Series: Substitutes and Complements

You can measure behavior on your site to determine the nature of the complementary goods relationship.  For the orders that include two particular products (that are offered as cross-sale promotions for each other), in what percentage of orders with both products was each product selected first?  Alternately, what is the conversion % of product A when added to a transaction for product B, versus the conversion % for product B when added to a transaction for product A.

Measurement of Cross Selling

The obvious metric that most people think of when evaluating cross-sale promotion effectiveness is conversion rate.  Conversion rate identifies the percentage of people who, when buying the “original” product, choose to also buy the “promoted” product.  Making changes that raise your conversion rate increase your sales of the promoted product.  However, this conversion ratio is more a reflection of the relevance of the promoted product to the original product than it is a measure of profitability.

Your goal is to maximize profitability, while providing additional value to customers (who are better off or more satisfied with the original purchase when they also purchase the promoted item).

Introducing a cross-sale promotion can increase, decrease, or have no effect on the rate of purchase (conversion percentage) of the original product.  You need to measure the original-product conversion rate for customers who were shown the cross-selling promotion versus those that were not.

Second, you’ll want to know what the ideal products to promote are.  Typically, more than one cross-sale promotion is presented to a customer at a time.  For this example, assume 3 promotions are displayed.  Also assume that your data-mining exercise has identified 5 products that could be promoted as cross-selling items for this “original” product.  Which three of the five do you select?

You should select the three that you expect to be the most profitable.

“Most profitable” can be calculated as (profit per promoted item) x (conversion % – of the promoted item in the context of the original item).  When you don’t have conversion percentage data, you can either gather it (through testing) or predict it (through modeling).  There are many aproaches for predicting the degree of affinity, or implied relevance, of one product to another – but all of them are too detailed to cover in a blog article.  When you don’t have a model, you can test the possibilities to see which ones perform the best.

Some companies also report average order value (AOV), but that’s not necessarily an indicator of profitability.  It may be a component of profitability, but not necessarily.

Product Managing Cross-Selling

If you’re product managing your website, and exploring adding cross-selling capabilities, or enhancing current capabilities, here are some things to keep in mind:

• Your customers are in the middle of a buying process, and will be interested only in complementary products that would give them a better purchase – more value, even if it means more money.  This drives both the importance of relevance and value as criteria for selection of products to promote.
• There may not be any one person who is responsible for (rewarded for) the profitability of your cross-selling capabilities, as the complementary products being promoted may be “owned” by different parts of your organization.
• You will want to test the effectiveness of the approach you use for promoting particular products – which original products, promoted products, and unique combinations of the two are the most profitable?
• You will want to be able to test the effectiveness of changes in the presentation of promotions (images, page location, text, etc) on profitability (or on conversion percentage as an isolated variable.
• You may want to offer discounts that apply only in the context of the cross-sale promotion (e.g. “Buy these together and save!”) and measure the impact on profitability – do the added sales offset the reduced profit per sale?
• You may find that a given complementary product has a different degree of relevance (and therefore effectiveness) depending on the market segment to which you are promoting it.  As an example, a game controller may be more relevant to consumers buying a large computer monitor than small business owners buying the same monitor.

Conclusion

Cross-selling works when you promote a relevant product that is complementary to the original product.  It works because the prospective customer is already in the process of purchasing the original product, and is therefore already qualified.  You should only promote products where the additional sale increases value to your customer and increases value to you.

Ultimately, cross-sale is about profitability.

Do you know about substitute goods and complementary goods?  If you’re doing any eCommerce, and are thinking about cross-sell and upsell, you should understand the basics about substitutes and complements.

Substitutes

You’re considering purchasing a specific product (e.g. a blank compact disc from Memorex).  You could consider purchasing an alternate product (e.g. a blank compact disc from TDK), substituting the alternative for the original.  At a high level, that’s the definition of a substitute good.  Any product that could be substituted for another product, and still satisfy the needs that the original product was intended to address.

Complements

You’re purchasing one product (e.g. a slice of bread with peanut butter).  The value you get from the original product would be increased by the purchase of a complementary product (e.g. a slice of bread spread with jelly).  The basic definition of complementary goods is “products that are purchased together.”

Economic Models: Substitutes and Complements

The definitions for substitute products and complementary products come from the world of micro-economics.  Substitutes and complements are used to model the interdependent nature of the changes of prices on the supply and demand of “related” products.

You can imagine a junior economist who tried a pricing experiment to determine the price elasticity of demand of Jif brand peanut butter.  He predicted that by raising prices on the peanut butter, that the store would sell less peanut butter.  Sure enough, demand (at the higher price) was lower, and sales dropped.

However, he also discovered that sales of Skippy brand peanut butter went up, almost by exactly the amount that Jif sales dropped.  This is because Jif and Skippy peanut butter are substitute products (economists call them “goods”).

Later on, this economist tried another experiment.  He raised the prices on both Jif and Skippy at the same time.  This time, the store sold less peanut butter in total (there were no other brands), and the economist thought his experiment was concluded.

Another surprise for the economist – sales of jelly dropped too.  Sales of peanut butter and of jelly are tied together – when you sell more of one, you sell more of the other.  Economists, trying to be difficult, would say that when you raise the price of one, the demand for the other falls.  Technically true, but a little confusing.

Thus entered substitute and complementary products into the world of economics and pricing.

Substitutes and Upselling

You know that you’re upselling – trying to replace one product that is about to be selected with an alternative product – when your customer is considering substitute products.  Notice in the screenshot from amazon.com (above) that ~9% of the people who were otherwise going to buy the original product instead were convinced to buy a more expensive substitute product.

The goal in upselling is to create a win-win situation.  Your customer gets more value from the substitute product, and you get more profit from the sale of the substitute than you would have received from the original.  Everyone wins.

Complements and Cross-selling

The number one mistake I see when people talk about cross-selling is they call it “upselling [sic].”  Its enough to make me Cranky. The example above, also from amazon.com, shows an encouragement, when purchasing the first book (in the series), to also purchase the second and third books. What’s especially clever is that there is no discount – the total price is the same as the sum of the prices if purchased individually.

You can take advantage of the complementary product model to create product bundles, identifying products that should be sold together.

Although that may not be the best idea.

Often, you will see bundles created by combining products that do not go well together – products that are not complements.  This is a sneaky way for companies to sell products that otherwise would not sell as well.

The recording industry made money in the 1950s and 1960s selling singles.  The recording industry then made a lot more money selling albums that “bundled” 8 or 9 mediocre songs with one or two hits when compact discs hit the market.  Digital downloads have re-introduced the popular purchasing of singles, and revenues are declining – not because of piracy, but because a “take advantage of our customers” bundling practice is now broken.

Complementary goods should be used to create bundles that increase value for your customers.

A baking cookbook is a good complementary product for a customer purchasing a stand-mixer (a key appliance for baking).

Symmetric Substitutes and Asymmetric Complements in Context

Substitute products are symmetric – either product works effectively as a substitute for the other – in a specific context.

If you need a new computer to use at your desk, then a desktop computer and a laptop are symmetric substitutes.  Regardless of which one is your originally selected product, the other is a valid alternative.  If however, you are looking for a computer that you can use while travelling, the desktop is not a valid alternative for the laptop (nor would it be your first choice).

When you’re considering the travelling scenario, the products are not substitutes.  Economists will say that they are substitutes as long as they share common uses.  But economists are looking at aggregated behavior.  You have to make decisions in context – and when the context implies that products are not substitutes, they are not substitutes.

Complementary goods are rarely symmetrical.  Peanut butter and jelly is a good example of symmetric complements – they have comparable price points, and both generally can be improved by purchase of the other.  In the mixer-cookbook example above, the cookbook is a great complement product for the mixer.

However, if your customer had selected the book initially, the encouragement to “add a stand mixer” would fall on deaf ears.  Surprisingly, amazon.com still recommended adding a mixer to my book purchase.  Technically rated a “toss up” by GetElastic in their great cross-selling do’s and don’ts article, but I put it squarely in the don’t bucket (until measured and proven otherwise).

Summary

• Complementary Products – consider cross-selling an additional product.  Complements are usually asymmetrical.
• Substitute Products – an upsell is a suggestion to replace the original product with an alternative product.  Substitutes are symmetrical, but only in a context where both products address the relevant needs of your customer.

Unless you live in a world filled with unicorns and rainbows, writing realistic requirements is critical.  When you set unattainable goals, the best result you can hope for is a frustrated engineering team.  Write requirements that are attainable, and your team will surprise you with what they can achieve.

Attainable Requirements – Revisiting

A little over three years ago (ten unicorn years), I wrote Writing Attainable Requirements, as part of the Big Rules of Writing Requirements series.  In that article, we focused on the unique situations that every team faces – politics and people, and the shared challenge of implicit practicality.  Those factors are as important today as they were then.

Defining Attainable

Attainability, for requirements, is simply the answer to the question – can this be reasonably done?  Most, but not all, of the answer to that question comes from understanding if your team can build and test a solution to the problem you identify with your requirement.  Being able to create a solution requires that the problem you’re solving is tractable, and that the team creating the solution has the skills to solve it.

Being able articulate a problem and it’s solution is necessary, but insufficient – solving the problem requires that there be a feasible solution.

As the founders of the agile development movement explained in their pitch for “low overhead” process – people trump process.  I think it was Alistair Cockburn who added, “but politics trumps people.”

Finally, process is the often-overlooked element of determining attainability.  Realizing the benefits of a novel solution to an existing problem usually involves process changes – sometimes significant ones.

The next few sections go into more detail on each of these – tractability, feasibility, people, and process.

Tractability

Goldilocks ruled out the large bed because it was too large.  Eating the elephant, drinking from the fire-hose, boiling the ocean – these are all common phrases in the American vernacular, because so many people try to do too much (at one time).  There are many ways to decompose a large, intractable problem into smaller, addressable components.  Practicality requires that the problem you’re trying to solve is not too large.

If everything you do is small, however, you won’t ever accomplish anything big.  That’s where strategic product management shines.  As part of understanding your market, you identify large, valuable problems to be solved.  To solve those large problems, you have to break them up into smaller problems, and then address them individually.  You also have to make sure your team understands the big picture and the larger problem that ultimately needs to be solved.  A great way to share context while decomposing problems is with the use of Ishikawa diagrams.

And zooming in…

Maintaining context is a particularly critical component of working with agile teams, where each deliverable’s possible size is constrained further to what a team can accomplish in an iteration.

[click for larger version]

For some problems (and some teams!) this may be enough information to provide the context to develop a product backlog.  And your agile team will move forward into managing their own execution from the product backlog stage.  For larger or more complex problems (such as this example), you will need more detailed communication before diving into user stories / use cases.

The same Ishikawa diagram, with more detail, looks like the following:

[click for larger version]

Agile Product Management: Providing Context

This reduced granularity represents the smallest go-to-market atomic requirement.  Further decomposition results in smaller requirements, but they become too small, because they are no longer independently valuable.  I’m not talking about “the sum of the whole is greater than the sum of the parts” stuff here – I’m talking about “if you only get X, without Y and Z, it has no value” stuff.

Feasibility

Even after decomposing market problems into addressable chunks, you still have to make sure that there are feasible solutions.  One of the brighter software developers I worked with back in the day used to say “We’re writing software – it’s all ones and zeros – we can do anything.”  He also followed that up with “…but should we be doing that?”  The team I was working with at the time probably could do just about anything.  But not everything can be done with a given budget and a specific deadline.  Some things are simply infeasible.

Scrum teams measure velocity – a reflection of how much software they deliver in a given iteration, as a function of how much work they believe is involved in delivering.  This is a great “protected” measure of efficiency.  The team is protected from requests to do work that has little or no value – by measuring throughput in terms of effort, a team can get more efficient at doing more.  A requirement is infeasible, and therefore unattainable, when it exceeds what the team can accomplish given a fixed amount of capacity.  Project managers refer to this as the Iron Triangle – given scope, cost, and quality, pick any two as inputs and the third will be a variable output (absorbing the impact of uncertainty that arises during the development process).  I prefer to use timeboxes rather than that rusty old triangle, to emphasize my perspective that quality is inherent in delivery, and should not be a “variable output of uncertainty.”  Because quality is what usually bears the brunt of uncertainty.

plus  yields

When the solution to a defined problem is prohibitively expensive, it is not attainable.  The notion of cost should also be considered in the context of value.  Requirements with higher value can justify implementing solutions with higher costs.

Prohibitively expensive solutions make requirements unattainable.  Relatively expensive (relative to their value) solutions also reflect unattainable requirements.  You need to collaborate with your implementation team to understand the costs associated with any particular requirement to know if it is attainable.  This is one of the strongest arguments against throw-it-over-the-wall interactions between product managers and implementation teams.  Without that feedback about feasibility and cost of a solution, you can’t assure that the requirements you are proposing are attainable.

Regular readers of Tyner Blain will realize that this is just an alternate way of stressing the importance of considering ROI when defining requirements.

Politics

There are political realities that every organization faces.  It could be a benevolent dictator CEO, or an executive with an agenda or pet project.  It may simply be that there is value in the problems you’ve identified, but solving them is not aligned with your corporate strategy.  You may be focusing on dominating an existing market, where expansion into new markets is the company’s focus – or vice versa.  You may be focusing on top-line growth opportunities, while the company is fixated on cost-reduction in a time of economic contraction.

Each of these scenarios causes you to be fighting an uphill battle internally.  When that hill is too steep, you’re writing unattainable requirements.

Process

When deciding what to build, you also have to think about how you launch.  Launching, as Dave Daniels regularly points out on his Launch Clinic blog, is not just putting your product up on your website for sale.  You have to think organizationally about all of the other moving parts:

• Do your customers have the ability to absorb an update to your software?
• Can your customer service reps be trained in time to promote and support the new capabilities?
• Will your sales team be able to communicate a message that helps them close deals based on what you’ve just built?

Process is more than just the process of typing, compiling, and testing code.  Process includes everything needed to successfully go to market and sustain your product.  If you’re defining requirements that are too far ahead of your market they are not attainable.  If your requirements embody process changes that are too difficult or expensive for your customers or your organization to absorb, your requirements are not attainable.

Conclusion

Attainable requirements are requirements that

• Have a reasonable cost to implement,
• Are aligned with your company’s strategy and stakeholder’s agendas, and
• Result in solutions that can be consumed by your company and your customers.

Make sure you’re writing attainable requirements.

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.

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.