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.

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

User Goals

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

Corporate Goals

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

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

Alignment and Conflict of Goals

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

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

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

Vending Machine Example

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

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

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

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

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

Consider the following procedure I’m forced to endure:

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

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

Consider an alternate procedure:

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

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

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

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

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

Generalizing User and Corporate Goal Conflicts

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

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

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

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

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

Blue Ocean Strategy

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

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

Creating a Blue Ocean Strategy Map

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

 [larger image]

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

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

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

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

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

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

Personas

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

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

 [larger image]

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

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

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

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

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

Mapping Personas to Products

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

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

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

 [larger image]

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

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

Improving The Model

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

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

Conclusion

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

Growth is a make or break measurement for products and companies.  Investment is often determined by expected value, which is based (in part) on expectations of growth.  When you create a product, there are aspects of growth – how many people can use your product, and how many people do use your product.  When dealing with a freemium business model, there are two elements of use - paid use and free use.

Three Goals of Growth

You can think about growth in terms of three goals – increasing your servable market, increasing your market share, and increasing your paid market share.

• Servable Market – The number of customers that could potentially use your product.
• Market Share – The percentage of the market (or of the servable market) that does use your product.
• Paid Market Share – The percentage of the market (or the servable market, or your users) that use and pay for your product.

As a product manager, when you consider capabilities to add to your product, you need to understand which goal your capability is designed to address.  These are all inter-dependent metrics, so it can be challenging to stay focused on each.  For example, if you have a 1% conversion rate from free customers to paying customers with your freemium business model, you may assume that by increasing the number of free users, you will automatically increase the number of paying customers.  That might be true, it might not.  Ultimately, you want to increase the number of paying customers – so that is part of all of these decisions.  When making each decision about prioritizing the next capability to add to your product, make sure you understand the primary growth goal you are affecting.

To keep the language from being too contorted, in the rest of the article, I’ll talk about users and customers as people, and not try and differentiate companies and people.  Users are people (or companies) that use your product or service.  Customers are people (or companies) that pay to use your product or service.  Your product could be a physical product, a software product (or license), software provided as a service, or a service.  I’ll refer to it as a product.

Growing Your Servable Market

The pedantic definition of your servable market is all users who could use your product.  A better way to think about your servable market is all people who experience the problems you’re trying to solve, who have reasonable access to your product.  People who don’t have those problems are not part of your market.  People who have those problems, but can’t reasonably use your product are part of your un-servable market.

Imagine you build a product that only runs on Windows Vista.  Windows XP users are not part of your servable market – they could upgrade to Vista and use your product, but they haven’t yet.  There’s a barrier to entry that they have to overcome.  Perhaps you have a pizza shop that delivers within a 10 mile radius and allows customers to place an order for pick-up and drive to your store and pick up the pizza.  If your shop is in Mountain View, technically people could drive from downtown San Francisco to pick up a pizza – but there’s a barrier to entry (the time and expense of driving to Mountain View) that makes those downtown San Francisco people part of your un-servable market.  

The size of your servable market reflects the potential number of users you could serve.  Your focus on growing your business can include changes designed to increase the size of your servable market.  You can write (non-functional) requirements that express this goal.  One type of non-functional requirement is platform support - supporting different operating systmes; supporting netbooks (with less-powerful processors) as well as laptop computers; supporting devices with slower network connections; and supporting visually impaired users through your user interface.  Sometimes, the requirement to support a particular platform is represented as a constraint (e.g. you must provide support for linux users).

Many products are developed today as software as a service (SaaS) applications - and they are usually implemented as websites, where people can use the product through a web browser user interface.  The approach of ubiquity of web browsers and “always connected” devices leads to platform selection for web-based products being a less-constraining  factor in definition of your servable market.  You may still be constraining yourself based on the specific browsers (Internet Explorer, Safari, Opera, Chrome, Firefox, etc) that you support.  You can gain a lot of insight through an analysis of your traffic, or you can rely on general trends.

Your business model may only support customers in the United States of America (like the soon to be launched Google Voice).  Your user interface may be text only (and not support screen readers or other devices).  You may be building a Facebook application.  You may be selling headphones with controls for the new Apple iPod Shuffle (that has no integrated controls).

What’s important is that you identify the things you need to do (added capabilities, platform support, country availability) to increase the size of your servable market – and associate them with the theme (or context) of increasing the size of your servable market.

Growing Your Market Share

Your market share is the percentage of those people you could be serving who are your users.  You can also think of this as the size of your user base, but thinking of it as a proportion of possible users provides more insight (because it provides visibility into how many people aren’t in your user base too).  As part of developing a business model (or financial justification for investment in a new product), you will have developed a model with some assumptions about market share.  Venture Capitalists used to joke about pitches that projected capturing “1% of a trillion dollar market, and therefore a $10 billion business” without providing justification.

You have to develop a plan for how and why you will achieve a particular market share.  One approach is to develop a viral marketing message, for products that “sell themseleves.”  Another approach is to develop a product that is inherently viral.  You can, of course, apply multiple tactics.  

The point here is to identify those product capabilities or features that will encourage users who can use your product to use your product.  Adding support for a platform does not encourage users to use your product – it just makes it possible.  Adding a solution to a valuable problem encourages people to start using your product.  Your product may be one that is designed to inspire love, or one that is designed to reduce annoyances.  An effective (and right-minded, in my opinion) approach is to identify personas within your servable market, and focus on their problems.  As a product manager, you choose which of those problems to address – and your team invents a solution approach.  You then validate that this approach is an effective one for the particular problems of the target persona.  

You may also want to define market segments to subdivide your servable market, so that you can develop unique strategies for presenting your solutions to potential users.  For example, you may find yourself with a surplus of cheap black pearls.  You can create two market segments – people who buy cheap jewelry and people who buy very expensive jewelry.  For the first group, you may position your product as cost-effective elegance.  For the big-spenders, you may position your product as something rare, unique, and not like those “everyday” pearls their friends all wear.  [I am pretty sure this is a reference to an anecdote from Predictably Irrational, but I'm not sure.]

What’s important is that you identify the things you choose to do (develop solutions to specific problems) in order to increase your market share – getting viable potential users to become active, actual users – and associate them with the theme (or context) of increasing your market share.

Growing Your Paid Market Share

People normally talk about this as conversion - conversion of free users into paying customers.  We’ll do the same.  I wanted consistent section headings. so I came up with “Paid Market Share” as a title.

Conversion is a key element to a freemium business model – one that offers two or more versions of a product.  One version is free to use and the other is a premium version that users pay to use (thus becoming customers).  Your conversion rate is the percentage of your users who are paying customers.  As we mentioned in the previous section on growing market share, you will have developed a business model for how much market share you would get and when and why.  If your business model is (or involves) a freemium product offering, your plan will also include projections around the number of paying customers you will have over time.

This is where focus becomes valuable.  As you identify problems to be solved (as part of developing a market-share growth strategy), you need to also decide which problems should only be solved (or should be solved better) for premium customers.  For example, the free version of MediaMonky (audio software) solves the problem of being able to listen to your audio files on your computer.  The catch is that when you add new music, you have to click a button that updates your “library” (so that MediaMonkey will play the new music).  The premium ($20US) version will automatically detect those new files.

You may also decide that a product is free for some users (companies with fewer than 10 users), and charge a fee to larger companies (10 or more users).  I don’t consider this to be a freemium model  In a freemium model, any user can choose either version of the product.  A related model is one where one set of users pay while another set doesn’t.  The distinction is probably best made by thinking about market segments.  If all (potential) users in one market segment only consider the premium version, and all (potential) users in another market segment would get no additional benefit from the premium version, then you would approach your growth strategy differently.  You wouldn’t be focused on converting customers, you would be focused on attracting paying customers – which is the same approach you use for growing market share.  In this case, you’re trying to grow the “pay for our product” market segment.

When you do have a freemium model – one where any given user can choose to pay or not – your focus is on identifying problems to solve for premium customers.  Not only do you have the normal “is there value in solving this problem?” question, you also have a positioning question.  Will you alienate the users of your free product (or inhibit market share growth) by offering a capability only to paying customers?  Another interesting strategy is to introduce new capabilities to premium customers first, and then have them “trickle down” to the free version as new capabilities are introduced for premium customers.

This strategy seems to be a powerful way to leverage market insights to continuously make your product more valuable than your competition’s products.  This could be a great way to “set the pace” for your market – forcing your competition to be reactive.  Slower competitors will lose not only to your premium product, but to your free version, which will out-value their paid products.  You get to define the rate at which your market changes.

What’s important is that you identify the things you choose to do (develop solutions to specific problems, and position them appropriately) in order to increase your rate of conversion – getting current free-product users to become premium-product (paying) customers.

One Way to Bring it all Together

I’ve done work with a client who has a distributed leadership team, so whenever I wanted to write on a whiteboard or stick stuff to the walls, I had to do it electronically.  We created a “strategy” Google-spreadsheet.  We have three columns one each for – grow the servable market, grow our market share, and grow our paid market share.  We added items into the appropriate columns, and developed relative priorities within each column.  The client strategy at any point in time, clearly drove the balance of emphasis for a given release across those columns.  Some releases, for example, were entirely around growing the servable market.

Conclusion

It isn’t enough to just consider the value of a particular capability, you have to put it in the context of an overall growth strategy.  Even if you’re solving problems from all three columns (servable market, market share, and paid market share growth), your top down strategy should drive how much effort you dedicate into each column, for any given release.

No cell for Dell.  According to Kaufman Bros. analyst Shaw Wu, carriers rejected prototypes from Dell because the “lack of differentiation.”  As product managers, we know the importance of keeping up with the Joneses, but we also know the importance of including differentiated value in our product offerings.

Old Rumors

The rumors that Dell would offer a cell phone (re) started when Ron Garriques, former EVP and president of Motorola’s mobile devices division joined Dell about two years ago.  There are many more articles and speculations from that time period (just search for them).

New Rumors

In January, Silicon Alley Insider reported a lack of denial from Dell CEO, Michael Dell in January.  A reader of the Insider, claiming to be “close to Dell” suggested a September 2009 product availabiliy, and calling it a “MePhone.”  They particularly called out 09/09/2009 as the date.  Tyner Blain (the company) was started on 05/05/2005, so maybe that’s a good idea :).

Barrons just reported Wu’s comments that carriers essentially rejected the Dell cell phone prototypes because they were no different than current and pending product offerings from competitors.

Dell recently filed a revamped retention plan for Garriques to stay through March 2010, according to the Austin Business Journal’s reporting a couple weeks ago of recent SEC filings.

Product Management

The entire Dell phone thing may be a farce (I don’t think it is), but it doesn’t matter.  The product management perspective on this situation (real or otherwise) is still interesting.

Should Dell enter the Cell Phone Market?

There are two sides to this question – the cell phone (and more particularly, the smart phone) market is hyper-competitive.  In Dell’s strong markets (corporate, channel), there’s the Blackberry devices from RIM.  In Dell’s stated focus markets (consumer, retail), there’s the iPhone and the Palm Pre (which is not a product yet, but has generated a lot of buzz).  Competition in either of these markets will be tough, as they are both pretty saturated, and both are under pressure with current economic conditions in the US.  Companies can easily cut back on subsidies for cell phones, and consumers can easily delay purchase of a replacement phone.  Customers in either market would need a compelling reason to purchase from Dell.

On the other hand, computer and smart phone technologies are rapidly converging.  Phones get more powerful, and people are shifting “traditional computing tasks” to their phones because of the convenience of having a phone where having a laptop is impractical.  Computers are getting smaller every day, and new usage patterns are developing.  You could argue that a computer manufacturer should be on top of this movement, and to be best positioned to have insights into what a “hyper convenient computer” should do, they should get into the smart phone market.

Kano Analysis

When you apply Kano analysis to the potential feature set for a phone, everything you might add to the phone falls into one of three buckets: must be, more is better, and surprise and delight.

Kano analysis recap

Kano provides three relevant classifications of requirements (the fourth category is redundant). All requirements can be placed in one of these categories.

1. Surprise and delight. Capabilities that differentiate a product from it’s competition (e.g. the nav-wheel on an iPod).
2. More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life or song capacity).
3. Must be. Functional barriers to entry – without these capabilities, customers will not use the product (e.g. UL approval).

Prioritizing Software Requirements – Kano Take Two

What Wu points out is that while Dell may have identified all of the must be requirements, just doing the minimum to be considered as a product is not sufficient to be accepted by your customers.  With the competitive landscape of the cell phone industry, these capabilities are necessary, but not sufficient.  The cell phone market is not a pure B2C (business to consumer) market, because the carriers (the providers of cell phone connectivity services) play such an integral role in the ecosystem, they have to be considered as customers too.  This is because the consumers are willing to accept long-term, very expensive contracts with service providers.  Those contracts allow service providers to subsidize the price of the physical phones (to the tune of $100 to $300 per device), in exchange for a contract that is worth over $1000 to the service provider.  For a phone manufacturer to penetrate the market in a meaningful way, they have to get these subsidies (from the service providers) in order to be remotely competitive on price with other phone providers.

Wu’s assertion is not that Dell failed to satisfy the requirements of the service providers, but rather that the service providers determined that Dell’s offering to consumers was insufficiently differentiated from other phones.

Differentiation

In addition to incorporating the must be capabilities into their phone, Dell also needed to have enough more is better features – like battery life, reception, screen size, (lower) weight to be perceived differently by consumers.  Dell also could have taken a surprise and delight approach, and introduced new capabilities that essentially make the competition irrelevant, by carving out a new market space.  Dell could have also focused on design elements – the same feature set, but in a more desireable device.

For fun, we can imagine some capabilities that Dell might have introduced that would have made their cell phone distinctive, allowing them to reach agreements with service providers to offer subsidies that would make their phone competitive in the market.

• Double the battery life, double the dB gain (strength) of the signal, cut the weight in half – all “obvious” more is better features – so they are probably also currently impractical, or Dell would have done it.  Note that these would have had to be achieved with protected intellectual property, or all of the other phone makers would also be doing it (or doing it very soon after Dell did).
• Create a social networking ecosystem around the phone – a surprise and delight approach to making the phone not just a phone, but a social networking device or entertainment device.  There are many solutions that solve parts of this problem (facebook connect, instant messaging, twitter applications) by connecting the phone to a customer’s social network.  No one is really providing a “social networking platform that is also a phone” today.  While I don’t know what this magic combination of features would be, I do know that it would be possible.  With android, the open-source operating system from Google, Dell software engineers have the ability to develop this, and encourage the open-source software community to contribute.  Flock is an open source browser that did this by building on the core software of the Firefox brower.  This could be developed either for consumers or business users who can use the product for managing their networks and contacts.  Imagine out of the box integration with Salesforce.com, and what sales rep wouldn’t want this?
• Create an entertainment ecosystem in which the phone plays a key role – the iPhone and iTunes work together to create this, in a walled-garden of interoperability.  Dell could develop a multi-vendor (of media), open-source, device-agnostic media solution for “everyone else” and extend the android operating system to work in this environment as well.  An alternate proprietary system probably wouldn’t work, it would just be “more of the same.”  Many large media companies are trying to figure out the right models for digital distribution of content.  Tivo lets you “time shift” and watch a show whenever you want.  Imagine integration with your smart phone, that also let you “location shift” and watch it wherever you are, whenever you want.
• Change the way networking works for your phone – develop a mesh network with your phone (every phone connects to every other phone in range to share networking resources).  This will create problems with today’s battery-life, and todays service-provider business models.  But imagine if hulu.com allowed you to download tv shows and movies to your phone (with advertisements embedded in the video), and then you could share those shows with peer-to-peer technologies like bittorrent.  More people would watch more video (and therefore more attention would be dedicated to advertising), and people would want the phones that could do this.
• Figure out a way to improve on location-based advertising, figure out how to solve more customer problems with the phone (phone + operating system + applications).

Conclusion

We don’t have any of the details about specifically where the Dell phone (if it exists) fell short.  But assuming that it did, we can have fun speculating about things that Dell could do that would make their product distinctive.  More importantly, we can learn from how Dell has apparently stumbled and apply it to our own products.  Are we just doing more of the same?

Another key idea – Wu said “…versus current and coming products…”  It is not enough to just do more than “yesterday’s competition” – you have to be ahead of tomorrow’s competition too.  This dynamic is generally true, but magnified in the cell phone market, where the service providers know what tomorrow will bring.

Planning by ROI.  Hmmm.  Isn’t that impractical?  In an econometric way, yes.  But you can still estimate the relative value of the capabilities / stories you’re planning for your scrum sprints.  The point is – don’t look only at value – also look at costs.  While “ROI” may be a poor choice of terms, “bang for the buck” is not.

Mea Culpa

In the previous article, Plan Your Next Spring By ROI: Part 1, I made a bad choice of sloppily using ROI (about a dozen times) to describe “bang for the buck.”

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

[...]

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

Plan Your Next Sprint By ROI: Part 1

[Editor: Note - the author has also messed up again, this time by burying the lead at the end of the article.]

Giants.  And Their Shoulders.

I had a great conversation over the weekend with Luke Hohmann, founder and CEO of Enthiosys, and realized my mistake.  Consider the titles of three (excellent) articles Luke wrote earlier this summer:

1. Why Prioritizing Your Product Backlog for ROI Doesn’t Work (Part 1 of 3)
2. Developing Attributes for Backlog Prioritization (Part 2 of 3)
3. Prioritizing for Profit (Part 3 of 3)

Not to mention giving a presentation at Agile’08.

You’d think I would have noticed, and been more careful in my use of language.  Sorry about that.

Luke, in his first article, provides several arguments against econometric assessment of ROI, and I agree with all of his points.  In his second article, Luke goes into details about defining attributes for reflecting the goals of internal stakeholders, external stakeholders (buyers and users), and the system.  I promised to do the same in this article, but frankly, why reinvent the wheel?  Our differences from Luke’s article would at best be nuanced, so the best use of your time (and mine) is to just go read his second article.

Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit. As an aside, it is this set of attributes that most clearly distinguish the Scrum-centric role of a Product Owner with the full responsibilities of an Agile Product Manager.

Developing Attributes for Backlog Prioritization (Part 2 of 3)

Including Costs in Sprint Planning

There are two dimensions by which to keep costs in mind when planning a sprint.  The first is in determining how much work to schedule for any given sprint.  When you use timeboxing to plan a sprint, you’re saying “we have the capacity to do X work per sprint” and “we should only schedule X work per sprint.”  Your plans are based on estimates, so you need to have a feedback mechanism to make sure you’re doing a better job in planning each sprint than you did with the previous sprint.  Burndown graphs are a great way to do this.  The burndown provides feedback within the sprint too, not just at the end.

Mike Cohn, of Mountain Goat Software, gave a great presentation on how to estimate costs for an agile project.  Without giving it away, he proposed (starting on slide 14) using planing poker to get quick estimates of user stories [more details] at the product backlog level.  Then, more detailed estimates are created for the tasks within the sprint.  If your team uses use cases, you can choose to use use case points as a low-overhead estimation method (but not nearly as low as planning poker) to determine the initial estimates of costs.

A Planning Example

You have the following set of items being evaluated in your product backlog.  Note that there are a mixture of strategic, user-centric, and code-refactoring items under consideration.

• Profile Editing – As an insurance agent in the community, I want to be able to edit my profile to personalize my identity within the site.
• Data Abstraction Refactoring – The system’s data model is inelegant and needs to be refactored, if ongoing development is to be easier.
• Action Notification – As a manager of agents, I want to be notified whenever my agents submit quotes to potential customers.
• Grouping Items – As an insurance agent, I want to be able to group contacts, proposals, communications and other items, so that I can organize my work.
• Reporting – As a manager of agents, I want to be able to run reports to track financial metrics and activities by agent, product, geography, and time period, so that I can manage my team effectively.
• Serializable Objects – The system’s implementations for data backup and data export are redundant and brittle and should be refactored to clean up the code.
• Customer Centric UI – The user interface is currently product-centric in approach.  Our strategy to offer multi-vendor product lines will require agents to focus on customers first.

Using the value-estimation and cost estimation techniques outlined by Luke and Mike you determine the following value and cost estimates for each “story.”

If you were to ignore the cost estimates you would do the data abstraction refactoring and customer-centric UI stories first, followed by the profile editing, action-notification, and other tasks in order of descending value.  As it turns out, that is not the way to maximize value over time.  At first glance, the profile editing story looks like the biggest bang for the buck.

Create a scatter plot of value versus cost.

[larger version]

You can clearly see the differences in value and differences in cost of the different stories.  If, however, you add the element of value/cost – bang for the buck – and prioritize by it, you will schedule stories in a different order.  Value / cost is also the slope of a line from the origin of the graph to each story.  If you draw those lines, you see the following:

[larger version]

To maximize value delivery over time, work across the chart in a clock-wise direction.  Profile editing is the first task, but grouping items and data abstraction refactoring are tied for second place.  This is different because you’re prioritizing by bang-for-the-buck, not just bang.

Collaboration And Agile

When you consider the agile manifesto

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas

© 2001, the above authors. this declaration may be freely copied in any form, but only in its entirety through this notice.

you see that there is an opportunity to take this even further.

Have Developers Improve ‘The Plan’

I proposed an idea to the development lead on an agile team a couple weeks ago.  A couple hours later, he pinged me to let me know he had just applied it and was very excited.  A quick whiteboard session (started with a version of the diagrams above), and he was able to immediately make his sprint better.

I told him that when I was still slinging code, and later, when working with teams of engaged and talented developers, I often ran into the problem of having a “cool capability” and wanting to get that capability into the current release.  I wasn’t pushing for the capability because it was high bang-for-the-buck, or even high-bang – I just thought it was cool.  So I would implement it.  Bad Scott, no biscuit.

What I proposed was that when a developer has a favorite feature, instead of just trying to squeeze it in, the developer should figure out how to make it cost less, until it had the highest bang for the buck.  Each initial cost estimate is a planning-poker estimate.  By spending cycles on design, a developer can figure out a cheaper way to implement it.  And that moves the story to the left on the chart.

Your challenge, visually, if you want to bump reporting up in the planning backlog, looks like the following:

[larger version]

You, as a member of the implementation team, have to come up with a design for reporting that is roughly one-third the cost that was originally estimated.  Do that, and it gets bumped up in the queue.  [And yes, I realize that very few developers get excited about reporting.]

The product manager’s job is to make sure you get all the dots in the right place vertically.

The implementation team puts the dots in the right place horizontally.

Everyone embraces the ability to change the graph.  The product manager moves the dots up and down as she learns more about the needs of the market.  The implementation team moves them to the left (and sometimes to the right) as they design better solutions.

Quoting Luke again – “Our experience is that successful Agile Product Managers have an almost natural, intuitive feel for prioritizing backlog items to drive profitable growth. Fortunately, this natural ability is greatly enhanced when they make the link between the backlog and their ability to drive profit explicit.”

This feels intuitive to me.  What about you?

You’ve got a giant backlog of user stories and product capabilities.  How do you determine which stories to implement right now?  By the estimated value of each story?  Pick the ones the developers want to build next?  How about picking the stories that maximize the ROI of the sprint?  To do that, you need to estimate both value and cost.  While remaining agile.

ROI Refresher

In our earlier Definition of ROI: Return on Investment article, we provide an explanation and example of calculating ROI.  In short, ROI is the acronym for return on investment.  How much return do you get, as a percentage of what you have to invest.  If you invest $100 to get $120, your return is $20 (the profit).  Your investment is $100.  Your ROI is 20% (20/100).  Another way to think about it is bang for the buck.

Prioritizing by ROI versus Prioritizing by Value

You can prioritize based on value – “Do the most valuable thing first.”  And that is a good, but suboptimal approach.  We even suggested it as “the best” prioritization technique in our prioritization article from almost three years ago.  Since then, by continuing to focus on software product success, I’ve learned to believe in a better way.

Just over a year ago, we showed how prioritizing by ROI delivers value faster.  The reason this works is that each sprint (or timebox) has a fixed capacity for work, so you want to cram as much value into that box as possible – not just do the most valuable thing first.  Here are a couple images from the previous article that show the impact of using this approach.

Identified stories, from highest value to lowest value (V = Value, W = Work (or cost)).

If you can schedule 30 units of work in a sprint, your first sprint will deliver 19 units of value, and your second sprint will deliver an additional 9 units of value.  The thirs sprint delivers the remaining 15 units of value.  Why more value in the third sprint than the second?  Because you didn’t sort by ROI, you sorted by value – but were constrained by cost.  When you sort by ROI, you get the same tasks, in the following order:

With this sorting, your first sprint delivers 25 units of value, your second sprint delivers 9 units, and your final sprint delivers an additional 9 units of value.  There are more details in the original value-maximization article.

This is critical to executing a market-driven strategy that will dominate your competitors.  You not only have to stay tapped in to the market needs, but you have to deliver faster than the other guys, or your distinctive insights will be wasted.

Political Prioritization

Really?  Yes.  The first risk to the success of a project is that it gets canceled.  Only the projects that don’t get killed even have a chance to be right, and therefore maximize value for your customer (or company).  That means you need to prioritize in a way that satisfies your stakeholders.  After attending last year’s IBRF, I wrote the following article as an interpretation (and slight extension) of Roger Burlton’s very good presentation about process improvement.  When you’re tasked with improving a company’s processes, the first question you have to ask is “which ones should we improve first?”

From that article:

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Stakeholder Value Matrix

The end result is a prioritized list of processes to improve, based upon which ones cause the combination of most pain (current state) and most gain (when improved) across your stakeholders, based on maximizing the utility of the group of stakeholders.

Visually, the preceding diagram shows the end results of aggregating the stakeholder inputs in terms of pain and gain.  A couple utility curves are overlaid (arrow shows increasing utility) to show what to do first.  The 1,2,5 processes are clustered together in the “highest utility” or “most value” range.  This approach would focus on those processes first.

Persona Prioritization

When developing software, you should primarily be user-focused.  [Note: this is somewhat of a religious debate, I guess we worship at the chapel of UX.]  Luckily, most of the time, stakeholder goals and user goals are not in conflict.  However, to sell your solution, you need to make sure you are addressing both buyer goals and user goals.  Sometimes they are the same, like with consumer products, and sometimes they are not, like many enterprise software products.

As a product manager, you have to know when to listen to, and when to ignore the squeeky wheels.  If you’re in a start-up doing its second product, solving a new problem for a new market segment, you’re dealing with founder’s dilemma.  That founder has a bunch of stakeholder goals for you, and the juice to make sure you address them.  If you’re trying to get analyst’s attention [good article by April Dunford at Rocket Watcher], you may feel pressured to prioritize “check the box” features that may be important only to buyers and analysts, without actually adding value for the users.

Of course, you can’t ignore analysts and buyers and internal stakeholders.  If your product gets cancelled before you get to market, you’re done.  If analysts criticize or ignore your product (for some markets), you lose a lot of sales.  And if buyers don’t “think they want it”, they won’t buy.  You never get a chance to demonstrate value to the users.

But focusing solely on those folks means you won’t have a product that people love, and you won’t generate word-of-mouth, customer loyalty, or value for your customers.

So any solution needs to account for the needs of the users.  Organizing users into personas, and making strategic decisions about which ones are important will help.  Include the other people (buyers, etc) but use a persona-centric model for describing what you’re doing – just to make sure the users are at the center of your decisions.

Intermission

So far, we’ve argued that prioritization should be by ROI, and while accounting for other people, should be user focused.  Actually, nothing above is sprint-specific, the same concepts apply to any product planning and development approach.

In part 2, we’ll look at defining user stories and user persona.  We’ll look at the value of each story relative to cost, and show a couple low-overhead ways to easily visualize this info – both driving scheduling and motivating the team to improve.

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

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

Product Success Is Not Easy

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

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

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

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

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

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

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

Empirical Processes

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

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

Creating Successful Products Intentionally

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

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

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

1. Identify Your Market

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

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

2. Select The Problems You Will Solve

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

3. Create a Product Roadmap

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

4. Design and Implement Solutions

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

5. Get Feedback on Your Solutions

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

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

6. Incorporate Feedback Into Your Plan

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

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

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

7. Revisit What You Are Doing And Why

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

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

Conclusion

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

Prioritization is about maximizing the value you provide to your customers. When you have multiple sets of customers with different priorities, what do you do? You could try and find the lowest-common-denominator, and please everyone a little bit. But that would be the wrong thing to do – by trying to please everyone, you fail to delight anyone.

Setting Up A Prioritization Example

To keep it simple, imagine that your market can be divided into three distinct groups. You would represent each of those three groups with a persona. While working with customers in each group you identify that each group has a distinct set of priorities. You have five capabilities you want to introduce – represented by five features. You will be able to release one capability (feature) per release. Keep it simple for now by assuming they all have the same cost and time to implement.

Each group ranks the features 1 to 5. Each group ranks them differently.

One client I worked with would create a simple spreadsheet like the one above. Each group has a column, and each feature has a row. The number in each cell is the sequence of that feature, in priority order, for each group. That client would then add an “Aggregate” column, representing the sum of the values. My client would then sort the spreadsheet from lowest to highest aggregate value.

Feature 3 would be in the first release, then feature 2, feature 1, feature 5, and finally feature 4.

Each of the three most important features for any given group is highlighted in green, with descending intensity. This makes it easy to see that (for this example data) each group gets their most valuable feature in one of the first three releases. It takes until release 4 for all three groups to have their “top 3″ implemented.

You can call this the lowest common denominator approach. Relative value is averaged out across all of the groups. Each group has an equal say in what gets released when. One problem is that each group is (almost never) exactly as important as all of the other groups.

Prioritizing Features By Customer Importance

This approach, flaws and all (we’ll come to that) could be improved by taking into account the relative importance of each group. Consider adding a weighting value for each group. That weighting might reflect the size of the market segment, the strategic value, or a combination of factors that cause one market segment to be more important than the others.

The chart above shows the same example, except now groups 1,2, and 3 have an importance measure of 10,20, and 40. The aggregate value column now incorporates that weighting. Instead of just adding up the sequence values for each feature, the values are first multiplied by the importance of their group.

Counter-Intuitive Math

You would think that since the smallest numbers come first, you might want to divide by the relative value of the groups instead of multiplying. When you aggregate the sequencing, higher numbers (lower priorities) tend to push features to the bottom of the list, and lower numbers (higher priorities) tend to pull numbers to the top of the list. If you divide by the relative importance of each group, instead of causing their inputs to bubble to the top, you end up reducing the relevance of the inputs from that group. By multiplying you make each group’s inputs relatively more significant, as the relevance of the group increases.

From the color coding, you see thta group 3’s influence is greater than either group 1 or group 2’s influence. Also note that (for this example), group 2’s most important feature is scheduled ahead of group 3’s third most important feature – even though it is also the most important capability to group 1. The aggregate value column is now sorted, using the same approach as before, but with a weighting that favors the more important group.

The Problem With This Approach

The approach looks pretty clever, and it is not horrible. What it is is mediocre. And it encourages mediocrity. First, you get mediocrity because a feature that is “kind of appreciated” by all groups will get a lower aggregate value (and therefore a higher priority) than a feature that is incredibly super critically urgent for one group but wholly uninteresting to another.

Consider feature F1. It is (because we get to make up the examples here) critically important to Group 1. It is also completely irrelevant to group 2. This is because the people in groups 1 and 2 are very different. They care about different things. Because group 2 is uninterested in feature 1, group 1 has to wait until the fourth release to get it. Bummer for those losers in group 1.

Now consider feature F5. Group 1 doesn’t care about it, and they get it in release 2. Those guys are probably sharpening pitchforks and lighting torches.

They don’t get what they really want until release 4, and you can argue that this is ok because the other groups are more important. But you haven’t set expectations well. Group 1 thinks their inputs are fed into the mix, and your roadmap is for them just as much as it is for everyone else. Turns out, this approach is not very good for setting expectations with group 1.

Another Manifestation of The Problem

Now look at the flip side. Your most important market segment, group 3, does not get what they want in sequence. To keep our example exhilarating, imagine that each shaded feature (sequence 1,2, or 3) is a “must have” for the group that ranked it. No group will go live until at least the 1,2, and 3 (shaded) features are implemented. That means that group 3 – your most important market segment – cannot go live until release 4. Group 2 can go live after release 3. But group 2 is not the most important group. You tried to satisfy the biggest, most valuable group first – and it did not work.

Why? Bad math.

You cannot use “sequencing alone” to represent the value that each feature provides to each group. For one group, maybe only the first two features have a lot of value, and the other three are all relatively worthless. You get a form back from them that shows 1 through 5. But it does not show that the value of (the features sequenced first and second are ten times the value of the other three features.

Solving the Problem With Good Math

There is a solution. But it is so much more labor intensive that most teams won’t do it. You have to determine the value of each feature to each market segment. You can’t use sequence or priority as a proxy. It has to be a number. Then you can aggregate.

The Philosophical Problem With This Prioritization Approach

There is still a philosophical problem with this approach, even if you did solve it with the right math. As we mentioned before, you are creating a mediocre – and therefore sub-optimal – solution by aggregating (and effectively averaging) the value of each feature to each group. Those features that are “kinda nice for everyone” will beat out the features that one group is really passionate about, but other groups don’t care about. If you take this approach, why bother to even define personas – you’re subconsciously ignoring those insights. Market segments are dominated by the companies that put out the killer features. It would be “killer” for some users if their car could go offroad. And killer for others if it got great mileage. Another group might really care that it is showy and fast. If you prioritized a feature that helped each of those goals somewhat (say, really good tires), how passionate would your potential customers be? The offroad guys want a roll cage. The eco-hawks want a super-efficient engine. And the “all hat no cattle” guys want a wing on the back – and it should come in yellow.

You may find that your segments are so different that you need to treat them as different markets, or at least market different products to them. Otherwise, you end up with a car that goes offroad but cannot climb a 40 degree slope, that gets 25 miles to the gallon, and, while yellow, does 0 to 60 in 7 seconds. You don’t delight anyone. How much penetration will you get in any of those markets?

Not much.

The Better Way To Prioritize

Pick your most important market. Do the most important things to them first. Then go to your next most important market. Repeat. Your prioritized road map will look like the following:

Group 3 – your most important market segment – goes live as soon as possible. After release 3. Your next most important market segment goes live next. Until you run out of features and segments. Note – make sure you continuously reprioritize. You may, for example, discover a new feature that lets you double your penetration with group 3. You should probably do that before finishing a feature targeted at group 1 – even if group 1 is not launched yet.

Conclusion

Do the most important things, for the most important markets, first. Then add the next most important thing, after you learn through your incremental release plan, even if it means delaying the launch in a lower-priority market segment, in exchange for higher returns from an already served segment.

Prioritize the present when planning your product. Neglecting the future is almost as bad as over-emphasizing it. The key is to incorporate your plans for the future correctly by making them play second fiddle to the present needs of your market. Serve both today and tomorrow – but prioritize today.

In The Long-Run, We Are All Dead

If you’ve had any macro-economics courses, you’ve heard the phrase “…in the long run” a million times. Supply and demand balance out in the long run. Monopolies are not profit-maximizers in the long run. The yield curve is an accurate predictor of…

You get the picture.

John Keynes (of Keynesian economics fame) said:

Long run is a misleading guide to current affairs. In the long run we are all dead.

You can make financial investment decisions based on the eventual outcome that is theoretically predicted. Keynes’ point is that practically speaking, the long run is too long.

The same holds true when making product management investment decisions.

Focus On The Now

Jeff Lash wrote a really good article on my birthday about the need to plan for the present [needs] and the likely future [needs] – and to not over-emphasis the future.

Understanding the long-term implications of decisions is important, though possibilities well into the future should not overshadow more pressing short-term decisions.

Plan for the present and likely future, Jeff Lash

Jeff talks about the need to make sure you address the current market demands. Jeff warns against the risk of rejecting “good enough for now” solutions when they fail the litmus test of meeting improbably future needs.

Planning for too far into the future often happens because people are in search of the “perfect” solution. (Surprise — there is never one!) A “good enough” solution might perform well for several months or years; unfortunately, those looking for the “perfect” answer will reject what is “good enough” and insist on a solution that is usually more complicated, more complex, and more expensive.

Plan…, Jeff Lash

Plan For Tomorrow Too

Jeff raises one of the major concerns with planning for tomorrow:

Another danger in planning ahead too much is that the farther into the future you try to look, the more likely you are that your predictions will be wrong.

The right way to deal with this is not to ignore tomorrow (because it is inherently risky), but to account for that risk.

Prioritization is inherently the making of investment decisions. You prioritize the present needs of your market ahead of the future needs. On the average, that’s how it works out. But you shouldn’t arbitrarily delay future needs. How do you compare the potential value of something way out on the horizon with something more immediate? We can look to economics (and management accounting) for techniques to do this.

Equivalent Measures

In accounting, you use the notion of net present value to create equivalent measures of the value of two different investment choices. This allows you to maximize your return on investment. You do the same thing when making product management decisions.

In product management, we prioritize based on ROI. More specifically, you maximize the overall value by prioritizing deliverables by value per unit of cost. This maximization strategy front-loads the value into your development schedule. In layman’s term, you’re getting the fastest high-value returns by working first on the use cases that have the highest value-to-effort ratio. Not the use cases that have the highest value.

This is exactly the same as financial ROI maximization. The hard part for product managers is in determining the right numbers to use. Once you have numbers, the rest is easy.

Discounting For Risk

To get the right numbers, you have to estimate or assess the value of any particular capability. We deliver most effectively when we plan each release at the use-case level. You also have to estimate the cost of delivering each use case. Depending on how you run your projects, you may want to flesh out the use cases and then develop detailed work breakdown structures and cost estimates. However, you can move more quickly by using use case points to estimate the level of effort (and therefore cost). Since your estimates of value are likely to be imprecise, you can make decisions “of the same quality” using use case points as you could with detailed cost estimates.

All of this math results in approximations, so you should always use your best judgment and “sniff test” the numbers. If the numbers are telling you something that you didn’t expect, either you don’t understand your market, or you made bad assumptions about value or cost.

This approach works for comparing “everything today” features or functionality. To properly incorporate tomorrow’s use case into the prioritization, you need to discount for the risk that your value-estimate is wrong. You do that by calculating the expected value of the use case. If you estimate a 10% chance that your use case is worth $100,000, then the expected value of that use case is $10,000. The expected value is the risk adjusted value. You use that risk-adjusted value in your prioritization.

Conclusion

In the real world, Jeff’s advice is almost always right: focus on the present, not the improbable future.

With the approaches outlined above, you can make a financial argument that will usually lead you to the same conclusions. But when it doesn’t, you’ll have the data to back it up. There are times when a long-term investment (for future use) is justified, even at the expense of delivering some immediate term value. If you completely neglect long-term investments, you’ll never be a visionary leader of your market.

If you over-emphasize long-term value, your product will be dead before your market is ready to benefit from it.

Do you recognize this early logo from Amazon.com? Future Now has a great article detailing how Amazon evolved their “add to shopping cart” implementation. From reviewing this summary of the evolution of one feature, we can see that Amazon decided there was value in reinvention. The improved the way their product did something over time. Have you?

Continuous Improvement

Software developers understand the value of continuous improvement. It is a core tenet of agile development – as you do more, refactor what you’ve done so that it is better. Some people who promote agile explain that refactoring is a barrier against spaghetti code and broken windows. That is certainly true, but there’s also merit in simply making the product better.

The key is to define “better.” Refactoring as part of implementing something new comes from a simple idea – “elegance” in design includes an analysis of how well the code solves the problems it is being asked to solve. When you add new functionality, you redefine the context by which you analyze. When you extend your code base in unanticipated directions, you are likely to be reducing the elegance of your solution. So you refactor, to make sure your design is elegant given the new context for analysis.

One of the development teams we’re working with right now is proposing a rewrite of a set of utilities that are part of an enterprise architecture. A small piece in a very large puzzle. Unfortunately, their argument is that “the code is not good.” Instead of looking at their specific situation, we can ask the question – “When is there value in rewriting?”

Value In Rewriting

First, we should define rewriting. Imagine that your software is a “black box.” It accepts inputs, and provides outputs. It does some work or analysis or magic or something inside the black box – you don’t know what. When you feed it an input, it responds with an output. Our definition of rewriting for the purpose of this discussion is that the “black box” view of the product does not change. The same inputs produce the same outputs. Not faster, not prettier, not less buggy, not more scalable, nothing. No (externally) perceivable difference.

In other words, the developers are saying “let me rewrite, instead of writing new code.” New code changes the behavior of the black box – the outputs are better or faster or different, inputs are handled differently, etc. A “noticeable” change. As product managers or analysts, we’ll assume that noticeable and valuable go hand in hand. :)

Newton’s First Law of Software: Software, when unmodified, behaves the same way it always has.

What are valid reasons for changing how it is written?

• Fiat. A corporate mandate may come down, stating that all software will be written in a single language, or will run in a specific environment. These types of mandates are intended to drive economies of scale and reduce costs by inspiring teams to leverage competence and knowledge across multiple products. Microsoft Office and Apple both apply this approach in designing consistent user interfaces to their products. People familiar with one application will be able to be productive with a second application more quickly. So there is potential future benefit here.
• Cost of Change. When a product is being actively modified, there is a cost associated with making those changes. That cost is a function of how hard it is to make those changes. Making the code easier to work with does have value, in that it makes the cost of change lower. There can also be benefits here, but they are probably smaller than the value of doing something new. Until they get big. That may be the genius of refactoring as you implement new functionality. By keeping the code base “always good”, you incur small incremental refactoring costs in the context of implementing new features. The argument is that these small costs immediately pay for the next incremental refactoring due to time saved in adding functionality. It is a positive feedback loop.

It rarely makes sense to just rewrite for the sake of rewriting. If development costs represent 20% of the cost of a solution, then you need to reduce development costs by 5% for every 1% of incremental value (from redesign or new functionality) that you postpone. You can easily show that a 5% reduction in development costs “pays for itself” quickly if you operate your development team as a cost center. You should instead be operating as a profit center.

Value in Redesigning

There can be dramatically more value in redesigning a product. Redesigning is one step up from rewriting. These changes are externally visible. The software still does the same things, only it does them better. Better can mean an improved user experience, higher quality, faster responses, more accurate analyses, higher scalability, etc.

From a requirements perspective, a redesign does not change any of the functional requirements. It changes the non-functional requirements. Since non-functional requirements exist to support specific goals, a change in non-functional requirements reflects a change in value. And value drives prioritization.

You can, and should, prioritize redesigns along with adding functionality. Amazon, as the Future Now article (hat tip to Mary Schmidt’s Idea Pool) indicates, valued the repeated attention to, and redesign of the “add to cart” button on their web page. They were clearly making intentional trade-offs between strategic goals. As an example, with one design, they promoted other corporate initiatives at the expense of conversion rates (turning users/clicks into transactions).

Is Your Product Improving?

Our unscientific perception is that most software product teams are myopically focused on “what else should we do” and are forgetting “what can we do better?” It may be that you’re tackling such a large problem that “more” overwhelms “better.” But you should do the analysis.

Learning how to write use cases can be tough, but it is simple compared to the balancing act of determining which use cases to write and how to manage the expectations of all the stakeholders that are involved. It can be a difficult balancing act to prioritize use cases to assure that you meet the goals of the business while satisfying the needs of the users.

Goal Driven Use Cases

In the world of structured requirements, we apply an approach of top-down decomposition to determine what we need to build.

In an article stressing the importance of non-functional requirements, we summarized the relationships from the above diagram as follows:

• Goals are achieved by enabling use cases.
• Goals drive non-functional requirements.
• Use cases are enabled by implementing functional requirements.
• Use cases influence non-functional requirements.
• Non-Functional Requirements define the characteristics of functional requirements.
• Functional requirements drive design decisions
• Design choices are restricted by constraints
• Design choices guide implementation
• Implementation is product

Non-Functional Requirements Equal Rights Amendment

The key element, with respect to this article, is that goals are achieved by enabling use cases. In other words, without the use cases that people* perform, the goals of the business can not be achieved.

[*Sometimes the use case is performed by a system - not all actors are people]

Principal Stakeholders Own Business Goals

We learned a lot from Outside-In Software Development, by Carl Kessler and John Sweitzer. One of the important things we learned is how to understand the goals of principal stakeholders. Principal stakeholders are the “owners” of the ROI that we are attempting to achieve with our product or solution. The business has the goals, but the business is an abstract entity. If the goal of the business is to increase sales by 10%, we can’t call up the business and ask “did we meet your goal?” We have to call up the vice president of sales. The business is organized so that there are people who are responsible for the initiatives and goals of the business – they are responsible for growth, profitability, costs, strategy. The insight we got from Kessler and Sweitzer is an appreciation that this ownership lies with one or more individuals.

When a goal has an owner, we can validate that we have met the goal. We can validate that we have satisfied the owner of the goal. You can’t do that validation with an abstract entity, a “business”, but you can with a person. Certainly, we can do the math ourselves, but if we want someone to pay the bills – and more importantly – invite us back to do more projects, we have to satisfy an individual. And that individual is our principal stakeholder.

Principals Own Use Cases

Our principal stakeholder owns the business goal – and therefore owns the use cases that enable that goal to be achieved. Our stakeholder will validate the completeness of our use cases by answering the question, “If we enable all of these use cases, will we completely meet your goal?”

End Users Own Use Cases

User-centered design is also one of our core principles, and an acknowledged best-practice. For many companies, it is more than mandatory – it is a way of life. The entire software development process is sometimes built around a focus on the end users. This approach puts the user in the center.

You can identify end user goals with the following approach:

1. Identify the actors that interact with the software.
2. Identify the personas that represent those actors – thus avoiding the elastic user syndrome.
3. Develop an understanding of the personal goals of the personas – and by extension, the actors through ethnographic research.

Stakeholder Goals: Principal vs. End User

This creates what appears to be a conflict – do principals own the use cases, or do end users own the use cases?

Mixing Interaction Design With Structured Requirements

One approach to resolving this conflict is to eliminate it by mixing interaction design with structured requirements. In this approach, the interaction design component applies end user ownership as an input to the design, but not the content of the use cases, as the following diagram shows:

In the diagram above, the changes (relative to the Wiegers process) are marked in blue.

The interaction design process starts with two parallel activities. On the left is the identification of corporate goals, which is analogous to the creation of an MRD. An MRD can be a reasonable mechanism for documenting the corporate goals. It provides more detail than “Increase profits” with statements like “Increase profits with improved pricing.” On the right side is the creation of personas to represent the most important users.

Interaction Design and Structured Requirements

This approach side-steps the issue by relegating the end users to “design input” and not allowing them to contribute to prioritization and management. For many applications, this is a great way to approach things. Specifically, it works very well when the user’s goals are tightly coupled or highly aligned with the principal stakeholder’s goals.

When Goals Conflict

User goals are not always aligned with stakeholder goals. In our earlier article on identifying these conflicts, we proposed a simple grid view for identifying these conflicts.

In that article, we looked at situations where the goals of the actor were primarily aligned with those of the principal stakeholder, and therefore the business. We discussed using the grid to inspire solutions that removed the conflicts. Two birds with one stone would be the easiest way to summarize.

What about when goals are implicitly in conflict – or even diametrically opposed? We’ve worked on systems where that is exactly the case. Consider a two-tier sales model, and products / websites designed for the people in the second tier.

Two-Tier Sales Models

Here are some common business models where the users have goals that are directly in opposition to the goals of the principal stakeholders.

• Automotive Manufacturer and Dealer. A website, designed by a car manufacturer, to allow dealers to improve their ability to sell cars. The automotive manufacturer makes money by selling cars to the end customer, and the dealer makes money by causing the sale to happen. The manufacturer is compensated by profits on the sale, whereas the dealer is compensated simply by making the sale. In other words, the dealer is motivated to lower the price because a sale at any price generates the same profit for the dealer. The manufacturer is motivated to raise the price because fewer sales at a higher margin generate the same profit, but higher ROA (return on assets) than more sales at a lower margin. This is an implicit conflict.
• Book Publisher and Book Retailer. A book publisher sets a price for sale to the retailer, and a suggested (list) price to the end customer. The retailer will typically pay a negotiated discount, in the form of a percentage off list, for the book. Any books not sold by the retailer are returned to the publisher or (usually) destroyed. The retailer does not have to pay for books that are not sold. The retailer has limited shelf-space, and makes money based upon a combination of the size of the discount and the number of books that are sold, regardless of publisher. The retailer is therefore incented to increase the discount, and thus increase profits for a particular title – and the publisher is incented to reduce the discount, and thus increase the profits for a particular title. Since the list prices are fixed, the retailer negotiates the discount, and as leverage over the publisher, gets to influence the placement of the book within the store. Each publisher is forced to compete with other publishers. These goals are also in conflict.
• High-Tech Equipment Manufacturer and Value-Added Reseller. A value-added reseller (VAR) provides solutions to end customers. They do this by combining products from manufacturers, and adding value – in the form of planning, custom engineering, installation services, etc. The VAR will negotiate a price with the end customer for a solution. The typical VAR sells products from multiple high-tech companies. The VAR will negotiate with the manufacturers to get the lowest possible prices from the manufacturers. The manufacturer wants the end-customer price (when it includes their equipment) to be as low as possible – to increase the number of sales that are made. The manufacturer gets the same profit (based on the price to the VAR) regardless of the end-customer price. Every dollar that the end-customer saves, the VAR loses in profit. The VAR makes profit on the difference between price-to-the-VAR and the final selling price. The VAR will also want to drive down the price it pays to the manufacturer. Reducing the price-to-the-VAR transfers profits directly from the manufacturer to the VAR. These goals are diametrically opposed.

When goals are in conflict like this, we can’t just relegate the “end user” goals to design inputs – we have to incorporate them into the prioritization process. In these examples, the “end users” are the VAR, the book retailer, and the automotive dealer.

Imagine that the high-tech equipment manufacturer sells networking hardware. The manufacturer has an internal (direct) sales force, as well as the VAR channel (indirect) sales force. The manufacturer identifies tools that help sales reps to close deals. Large purchases are commonly made at as much as 80% off list price. The list prices are irrelevant – they are not even guidelines in many cases. So the manufacturer develops tools to help sales reps know what prices to set for end customers.

Internal sales reps have generally well-aligned goals with principal stakeholders. The sales rep will be compensated based on a combination of revenue (sales) and margin (profits). This compensation model creates implicit alignment between the user goals (get a bonus) and the company goals (make profitable sales).

One approach to helping the sales rep close profitable deals is to share an indication of the profitability of the deal with the rep. The rep can (will!) set a price that is designed to maximize the sales rep’s bonus. If the compensation system is well designed – this is also optimal for the business, and therefore the principal stakeholder. The sales rep will get increased compensation for raising the price (and still closing the deal) by getting a percentage of the increase in margin. The sales rep is motivated to increase the manufacturer’s profits.

The VAR, however, should not know the profitability of a particular transaction. The VAR is motivated to lower the price (the price to the VAR) as much as possible – even at the expense of losing a “profitability bonus.” If the VAR is given a percentage of the increased margin (to the manufacturer) it comes at the cost of losing 100% of the change in price to the VAR. Remember, the VAR makes money on the difference between the price from the manufacturer, and the price to the customer.

Depending on the manufacturer’s business model, this could lower the priority of a margin-inspection capability, or dramatically raise the priority of features that restrict margin-viewing to only internal sales reps.

Also remember that the manufacturer and the VAR also have aligned goals – like closing the deal. And the VAR can close the deal with the manufacturer, or with products from a competitor. So the manufacturer is incented to provide valuable functionality to the VAR. The manufacturer cannot ignore the VAR’s needs, or the VAR will work with a competitor and the manufacturer will lose all the business.

You have to determine the value to the principal stakeholder of the value of the feature to the end user. In other words – even if a feature “hurts” the manufacturer, is the pain “worth it” because of the value of the relationship and expected future business that the company will do with the VAR?

Once the value of all of the functionality is identified, you can prioritize it. An enlightening way to visualize this value is with a value-delivery matrix. Thanks again to Roger Burlton for inspiring our approach to prioritizing based upon a combination of pain and gain.

Roger Burlton, of the Process Renewal Group, gave an excellent presentation Monday morning at the 10th annual International Business Rules Group: Developing a Business Process Architecture and Program of Change. A lot of good stuff about how to define, develop, and manage processes. One idea in his presentation was particularly compelling – that of driving process improvement strategy based on stakeholders. This approach looks at how much benefit the stakeholders can get from the improvement, and how much pain the current process causes them. A very compelling strategic prioritization tool.

Thanks Roger Burlton!

Thanks Roger, both for sharing your thoughts with us at the IBRF conference, and for giving me permission to write about this technique. We’ve adapted it a little bit. You can see a pure example from one of Roger’s presentations online (slides 15 – 17). Click on the “Other Resources” link from the Process Renewal Group’s main page, and select Implementation: The Payoff from Architecture and Program Management.  If you would like to follow up with Roger about this or any of his other works, he’s asked me to share his email address here rburlton@processrenewal.com.
We’ve simplified the example grids to show fewer processes, written out an explanation built from Roger’s (verbal) presentation, and introduced the notion of utility as a means to prioritize. The base idea comes entirely from Roger.

Stakeholders

Roger’s technique is a straightforward one – like all good ideas, it is obvious in a “I can’t believe I didn’t think of it” way. In short, you find the processes that are the most valuable to the most influential stakeholders – and you improve those processes first.

This analysis focuses on principal stakeholders. The goal of this analysis is to encourage your principal stakeholders, or sponsors, to prioritize the most valuable processes first. Not all stakeholders are created equal, so you have to weight the relative importance of each stakeholder. You can weight them politically, by influence, or by whatever factor is most likely to get buy-in from the executives.

Determining Value

Value, in this analysis, is a combination of pain and gain. To begin this analysis, you have to define the processes under consideration. You should have already done this as part of defining the scope of the project – and Roger showed us some compelling techniques for defining and managing the scope of the project. For each process, you perform two analyses.

• How much gain does each stakeholder stand to get from improvement of the current process?

For each process, for each stakeholder, identify if the gain from the proposed process improvements would be small (1), medium (2), or large (3). Use whatever normalizing scale you like – the key is to be simple, consistent, and directionally correct. You don’t need to have a detailed benefit analysis for each process.

You’re trying to prioritize, early on, which processes to work on.

• How much pain does each stakeholder feel due to the shortcomings of the current process?

Perform another analysis for each process and each stakeholder. This time identify the relative level of pain felt by each stakeholder, due to the inadequacies of the process. Use the same numbering scheme: low (1), medium (2), and high (3). The key is to be relatively consistent in your approach to assessing pain. It does not need to be an econometric assessment of risks and penalties, or a detailed model of lost opportunity and revenue. The goal is to approximate “how bad is it?”

Note that the “Combined Gain” and “Combined Pain” rows show the (stakeholder) weight-adjusted sums of the relative gain and pain levels. Each process then gets a ranking on the “most potential gain” and “most induced pain” scales. When you have a tie, remember to skip the next number when calculating rank. (e.g. if two processes in the example above had a combined pain score of 5, then they would both have a rank of 3 – and process #1 would have a rank of 5).

Pain Meets Gain

Next, create a graph with pain ranking along the vertical axis, and gain ranking along the horizontal axis. Plot each process on the graph. The processes in this example would look like the following:

There is a reasonable distribution of potential value for this example. Value is a proxy for utility when viewing this graph.

Intro To Utility Curves

If you were to overlay utility curves on the diagram, you would see that some processes are more valuable than others.

These utility curves also help us visualize the discontinuities in the diagram. Processes 2, 5, and 1 are more valuable than processes 3 and 4, which are more valuable than processes 6, 7, and 8 (not shown in the grids above).

Prioritizing Processes

Given the relative values of each process, as demonstrated with the utility curves, we can break up the staging – or prioritization – of the work to clearly convey which processes should be improved first.

And then we can also see which processes to prioritize for the second iteration.

As we complete the first set of processes, we should re-prioritize. Like all projects, we are aiming at moving targets. The second phase may not include processes 3 and 4. Our improvements to processes 1, 2, and 5 may not have been very effective – there may still be a lot of pain and gain to justify refactoring them again. However, there is value in communicating our plan as we know it today to the executives.

Processes 6, 7, and 8 may never get re-engineered. Since there is relatively little pain (impetus for change) or gain (value available from known changes), there may always be a better way to invest our resources.

Conclusion

Getting agreement from executives about what to do, or more practically, what to do first can be very difficult. By presenting a view like this to executives, you make it very easy for them to make decisions. And following Roger’s lead – you have the opportunity to convince them that it was their idea all along, and you only facilitated the plan.

One Man’s Trash

Dan’s article is about the difference between what and how. He provides good advice on changing the conversation to be what-centric, not how-centric. Dan is writing from the perspective of an information architect, and he defines what and how as follows:

As I started to work in jobs where some people communicated with one another using requirements, it seemed reasonable to keep separating “the what” from “the how.” These two definitions are the result:

• Business requirements: What the project, system, or solution needs to accomplish.
• Functional requirements: From a high level, how the project, system, or solution needs to accomplish what it needs to accomplish.

Are Useful Requirements Just A Fairy Tale? (and why an IA should care)

Although we used slightly different language, we wrote an article about how different people in the software development life cycle think about different artifacts created in the process. The following diagram sums it up:

Requirements Documents – One Man’s Trash…

Dan describes the product management view of the world in his article. It is a good article, and you should read it – his pragmatic solutions to common frustrations are good ones. They center around turning the conversation (with product managers) into one of What do you need? instead of How do you think I should build something?.

Prioritization Hell

As good as his article is about the frustration of mis-matched roles, here’s the paragraph that really got my attention:

First, you get a group of stakeholders in a room so they can “blue-sky brainstorm” to figure out how they want to improve their product. The group comes up with a list that has everything from “Make the little blue buttons bigger” to “Bring world peace.” The list goes to an engineering team who organizes the list into three categories: Things we can do now, things we can do by the end of the year, and things that will take a long time. They email the categorized list to a project manager who changes the categories to Phase 1, Phase 2, and Phase 3 and sets up a project schedule for the first 10 things in the Phase 1 list.

Dan Willis

Aargh!

This is why prioritization matters.

You should always prioritize the capabilities that yield the highest returns on your investments. Those returns may be based upon a measurement of risk, a strategy for gaining market share, or straightforward cost reductions. You can also refine this approach by applying the principles of Kano analysis to maintain a user-focus. You may need to balance the goals of users with those of stakeholders. But definitely don’t let someone prioritize features based on how long they take to implement.

Dan, we feel your pain!

The iPod Product Family

There are several different iPods in the market, each targeting a different subset of the mobile entertainment market. Apple has audio and video players with different form factors, designed for different usage patterns. Those different designs have resulted in a feature-based market segmentation. That isn’t really a good way to think about the market – you should think about how the devices are used, not how many songs they hold. Nonetheless, when measuring the market, people look at the features as a means to segment.

Microsoft’s Early Approach

The product manager for Zune gave an interview on Windows Weekly – a TWiT network podcast with Paul Thurrott – several months ago. The product manager mentioned that they were targeting the Zune to achieve 10% of the 30 GB audio player market. I may be mis-remembering the details, but at the time I thought it was an oddly narrow target. The product manager wouldn’t talk in much detail, understandably, about the upcoming features that were planned for the next Zune. In the interview, they discussed how quickly the Zune came out.

At the time, I thought “OK, we’ll see what they have for the next Zune,” and I moved on.

The New Zune

The second generation of the Zune was just released, with new models and features. I read a commentary somewhere that said you’ll recognize the pricing model, because it is the same as the iPod. The Zune has models that are competitively priced with the iPod Classic products.

Tom Merritt, on Buzz Out Loud, commented that he understands the Zune strategy – first, come out with a player that is not as good as an iPod – then in the next release, make it “just as good” as the iPod. The third release will be better than the iPod, and the fourth one will be an iPod killer. He argued that Microsoft used a similar approach with Internet Explorer. Tom’s comments caused me to remember the earlier interview with the Zune’s product manager.

A Good Strategy?

This may be an excellent strategy. The ultimate success of the Zune will probably be influenced more by Microsoft’s ability to market the product than the relative merits of the Zune when compared with the iPod – but we can still learn from it. Here’s a generalized recipe that can be extracted from what Microsoft has done. Keep in mind that this is a strategy for entering a red ocean market, already dominated by a market leader.

1. First, segment the market. Pick one segment, and deliver a product that has only the must have features for that segment. This is your first release
2. Second, improve the product, delivering enough more is better features, and some surprise and delight features – for that segment. Release again.
3. Third, differentiate your product, so that it is more desirable to that segment than your competitor. Release again.
4. Finally, start tackling additional market segments.

Segmenting

Segmenting the market makes a lot of sense – Microsoft doesn’t have to be all things to all people. They don’t have to match all of the features of the iPod. They only have to match the features that are relevant to that market segment. Enough to start to compete. And with incremental improvements, they can potentially take over that segment.

Iterative Development

Having a smaller target allows Microsoft to not only release a first-version of the Zune with fewer features, it allows them to release more quickly. They don’t (yet) have to worry about a portfolio strategy – they can target a single user segment, and focus on delighting them. With enough distinctive capabilities, they can potentially differentiate their product from the competition.

Here’s a fairly harsh (and valid) critique of the first generation Zune, in comparison with the iPod. What the article doesn’t do is look at the strategy we’ve defined – it evaluates revision 1 against the “end game”, and the Zune comes up short. That’s a risk of introducing an initial “not a winner” product. But how much money are you losing if you wait until you think you can win before releasing the first one? Don’t get caught in a blender, segment your market analysis.
Every situation is different – you have to balance perception versus early sales. Will a first-gen product hurt future sales if it isn’t “ready to win?” If so, then you shouldn’t release it. But if it is a winner for some, or at least a competitor, it may make sense. I don’t think Microsoft will have trouble overcoming a poor reputation for the first release of the Zune. I wasn’t paying attention at the time, but I’ve heard Tom Merritt and others allude to how “crappy” the first iPod was. Doesn’t seem to bother anyone now.

Moving Targets

Apple will certainly present a moving target in the iPod by adding new features or improving existing ones. Microsoft will have to either predict and match the new features – in an endless battle of keeping up with the Jones’, or they will have to introduce new features that cause Apple to respond. Apple has “first mover advantage” and dominates the market. But Microsoft has a “second mover advantage” – they are able to learn from Apple’s investments in earlier products too.

There are two examples of features that show both Apple and Microsoft trying to redefine the “must haves” for the market. Apple just released the iPod Touch – an iPod with a touch-screen interface. And the interface is indeed very slick (I played with one over the weekend). People (in the targeted market segments) might decide that this is a significant differentiator, or they might not. The jury is still out.

Microsoft introduced the ability to squirt a song from one Zune to another. This “social networking” element would ideally allow people to share music, temporarily, with other people – who would then buy the music for themselves. There was a painful joke that the only squirting that was happening was on the Microsoft campus in Redmond, because that was the only place you were likely to get close enough to another Zune owner to squirt anything. Aside for that, the songs were over-protected with DRM (digital rights management, aka copy protection). A squirted song could only be played three times, and had a limited shelf-life. Once either limit was reached, the song was deleted from the recipient’s Zune. With the new version of the Zune, the calendar-based shelf-life has been removed (although you are still limited to X plays of the song).

We’re looking forward to watching both products evolve in the battle. Consumers win when there’s competition like this – so for now, even as a happy iPod shuffle owner, I’m rooting for the underdog. Yes, there is irony in calling Microsoft an underdog.

Different Business Models

There may also be advantages for Microsoft in having a different business model for their music player. Apple has certainly benefited from the iPod to iTunes to Apple computer “closed platform” linkage. While iTunes is available for non-apple computers, there is an implied linkage, and analysts believe a causal relationship that drives Apple computer purchases by iPod owners.

Microsoft is probably just trying to be a player in a profitable market.If you want to look at market share analysis for the Zune and iPod, and for PCs and Macs, read this article, instead of relying on the hazy data above. Those guys are way better at it than we are, and there’s a lot of conflicting data out there – this article seems very credible.

Conclusion

This article really isn’t a prescriptive one, as much as it is an exposure of a strategy writ large – pick a segment of the market, release iteratively, and attempt to displace the 800 lb gorilla. We’ll see if it works.

We all know the story about the emperor’s new clothes. I’ve been thinking about prioritization and scheduling, and as far as I know, no one is promoting that we maximize value – they (and we) have been promoting that we do the most valuable stuff first. Doing the most valuable things first does not result in getting value the fastest. In this article, we show why not.

Genesis

About a month ago, I read an article by Kelly Waters on how to prioritize intuitively. He presents a magic square diagram, showing both the “how valuable is it” and the “how hard is it to do” axes. I’m oversimplifying, read his article for more details – he incorporates elements of risk, complexity, etc. I really liked that he was addressing the “missing element” of how much work is involved. However, his diagrammatic approach, while presenting this information very well, does not really yield insights into what to do first. Kelly and I had a great discussion over the next couple weeks, exploring the interplay of work and value in prioritization, trying to find a way to encourage value-maximizing decisions.

Prioritize By Value

We have talked about prioritizing the most valuable requirements first repeatedly. And in the last of those links, we accidentally hinted at, but didn’t grasp the real goal:

We will only consider those steps where the profitability of change exceeds our hurdle rate for investment.

We’ve also talked in the past about using use cases as the basis for scheduling, as each use case represents realizable value. For the rest of this article, we’ll talk in the context of scheduling use cases across releases.

Consider a very simple example – you have five use cases, with values of 10, 9, 9, 8, and 7 respectively (the units don’t matter). If you sort those use cases in order by value, from left to right, they would look like the following:

The size of each box shows the relative value of having the use case implemented.

Based on our previous guidance (and everyone else’s), you would implement them in order, from left to right. Makes sense. Do the most valuable thing first. Do the next most valuable thing next. Repeat until the value is not high enough to continue.

What About The Amount of Work?

OK, the amount of work required should play a role too. In our time-boxing article, we describe each release as having a given capacity, which you can visualize in terms of cost (resource) and time (duration of applying resources):

We fill up that capacity with use cases, based upon how much work is involved.

We can estimate the work involved with each use case by any of a number of methods – but the earliest estimates can be developed using use case points.

Consider the following “work” measurements, identified for each of our use cases from above:

We have the same sequence of use case implementation (based on value), but now we can visually see that there are different amounts of work associated with each use case. The area of each box represents the relative level of effort required to implement the use case.

Prioritize By Value Results

The best way to explain the flaw with the classical “prioritize by value” approach is to show what happens after the first release. Consider that you can accomplish 30 units of work in the first release.

We can schedule the first two use cases for this release. The size of the time-box above represents the amount of work that can be accomplished. With the first two use cases scheduled, the time-box will look like the following:

We have completely used up the available capacity of the team (Work = W = 30 = 10 + 20) by delivering the two most valuable use cases. We have delivered 19 units of value (Value = V = 10 + 9 = 19).

Value Maximization

When we consider both the value (V) and the cost (in terms of work, W) of each use case, we see that some use cases generate more value per unit of work than other use cases. If we consider the ratios of value to work (V/W), and sort the use cases based on this approach, we would see the following:

And with the previous specific value and work values:

If we were to organize our delivery of use cases based on this ratio, we would be saying “prioritize the most effective use cases in terms of value per unit of work.” This may seem counter intuitive, but it makes sense – get the most bang for the buck earlier, and you will get more value faster.

Consider what our first release would look like:

We would complete three use cases (using 25 units of available work), and we would deliver 25 units of value. We would also be able to start working on one of the use cases that would be delivered in the next release.

True Maximization

To find the mathematically proven maximal value, we have to do a bunch more work. This prioritization exercise is actually an example of the bin-packing problem, an np-complete computer science puzzle. To make a long story short, we can’t use a simple heuristic and guarantee that in all cases it will be optimal. But we can do better than “most valuable first.”

If we use the scheduling rule as follows:

Schedule the use cases in order based on the highest value-to-work ratio, skipping use cases that are “too big” for the current release.

Then we will get value out of the system as fast as possible. There are a couple problems with this approach:

1. It does not take into account that you can apply work from one release to a use case that is scheduled in a future release. Intuitively, any “remaining time” after scheduling complete use cases should be spent on the next highest-ratio use case. I haven’t proven that mathematically, but it makes sense.
2. Use cases, and their underlying requirements, and the implementation tasks to support those requirements are not actually independent. You may need to introduce one use case before another – the second use case may not be possible without the first one. Implementing a requirement that is shared across use cases will reduce the “remaining work” for those other use cases – causing a need to recalculate ratios. Implementation tasks are often dependent upon one another. The discrete tasks to support a valuable use case may require implementation work that is also leveraged in lower value use cases. Further, some implementation tasks must be performed sequentially. You can’t optimize a query before defining a database schema, for example.

The second problem actually applies to any prioritization approach that incorporates value. The nature of software development introduces constraints (X must be completed before Y can be started). Those constraints narrow the possible scheduling choices. And they make it impractical to determine the “optimal” solution. At least with commercially available tools, excluding expert systems, which can be used to solve this type of problem.

Conclusion

• Sequencing use cases based solely on value does not maximize the delivery of value over time.
• Sequencing those use cases based upon the ratio of value to effort will increase the rate at which value is delivered to customers.
• It is impractical (and possibly marginally valuable) to determine the optimal sequence for scheduling use cases to maximize value.

You should use the “highest ratio first” approach, and when a use case can’t be delivered yet because of interdependencies, skip it. Also – apply judgement to sanity check if you are doing something that seems odd – like delaying a high ratio, high value use case. Explore with the development team if there are ways to adjust their dependencies to allow for a “more valuable” delivery sequence

What makes the best gadgets great? An understanding of goals and attention to design details. When we take a step back from writing requirements about software, and think about gadgets and goals – the perspective can help us write better requirements and make better prioritization decisions.

Thought Provoking

Mike Schaffner’s recent article about what we can learn from our favorite technologies got me thinking. We can learn about how to focus on goals to make great products. In summary of Mike’s points, the best technologies do one thing and do it well – sound technology that works, and is easy to use. Those characteristics are necessary*, but not sufficient to having a great product.

* Doing just one thing may not be the right goal, but for any given product, there is one thing or very few things that are more important than all the others. We’ve written about the 80/20 rule of requirements in the past – but it might even be 90/10.

Lets pick an example.

Apple’s 2nd Generation iPod Shuffle

I’ve been using a shuffle since the start of the year. I guess dropping hints at holiday times helps. If we think about creating a portable music device, we could come up with any of a number of criteria for the product:

• Great sound
• Long battery life
• Ease of use
• Price

But that would be backwards. Yes, the long battery life is good – but not differentiating. Nor is the size – other small players are out there. Pricing defines a market more than it defines dominance of a market. And sound quality matters – but how much? Is an audiophile going to use a shuffle as their primary listening device, or does it just need to be good enough (which it definitely is).

We can start by thinking about goals. For a device like the shuffle, it would be personal goals. I wish I could remember who said it, but someone wrote that the iPod is a “process improvement device” for improving the process of walking around (by adding music to it). What a great way to think about it. And yes, the shuffle definitely makes walking the dog more entertaining.

There is one feature of the shuffle that I thought was mildly interesting when I got it, and now I think it is the killer feature. That’s the clip.

One User’s Story

While not a full fledged persona and scenario development exercise, let me share a little about how I use my shuffle.

I am not a fan of working in the yard. The exercise is nice, and the results are worth the effort – but the time usually feels wasted to me. I may be a little ADHD, so even when I think “productively”, I bounce around from idea to idea – and no more than one or two survive to the end of the yard work. The rest of that time is “lost.”

I also listen to several podcasts – tech podcasts, programming podcasts, science friday from NPR (which is awesome), and occasionally books on tape. But I could never make time to listen to them. With the shuffle, I can listen while I work in the yard. I also use noise-reduction headphones, so I can listen even when mowing and weed-whacking.

Why The Clip Works

What makes this possible is the clip. I can clip the shuffle onto the back of my baseball cap and tuck the cord under my shirt. If the audio device were in my pocket, or strapped to my arm (options with other devices), the cord would get in the way. For walking around, there’s no real difference. But for doing active stuff – all the difference in the world. Thanks to Tom for mentioning the baseball cap trick to me – previously, I had clipped it to my collar. That works great on planes when you’re travelling – no cord to mess with while you launch your roll-a-board into the overhead compartment.

What’s The Point?

The main point is to think about the most important thing(s) for your product. And think outside of the box. iPod shuffle as process-improvement. I love it. I think all of the non-clip features are undifferentiated “me too” features in the shuffle. But the clip is valuable and unique.

What is “the clip” for your favorite gadget? What is “the clip” for the product you’re working on right now?

The second release of nexus went live today (build 127). It included the top features from our prioritized list published yesterday. This enabled the next use case from our first prioritized list of use cases – searching the articles. We also took this opportunity to refactor part of the user interface – adding pagination of articles and search results, and reworking the presentation of the article content based on user feedback.

In this article we look at the content of the third alpha release of nexus.

Alpha Beta

Alpha and Beta have become part of the web 2.0 lexicon for releases. The way many sites use the terms, it seems that alpha means “incomplete” while beta means “complete but needs work.” We’re taking a similar approach here. We know we are releasing incrementally increasing functionality. The early releases are driving usage and feedback. The insights we gain as we’re building also allow us to prioritize what people want as we go. When we think the functionality is sufficiently complete, we’ll move to beta status. I don’t expect to be in beta for long. With a website, I believe it is completely reasonable to continue adding functionality after a site goes live (post-beta). I think beta is a good label for “improve performance, enhance experience, validate existing value” activities. Since we’ll be doing that all along during the alpha releases, that should be a short cycle.

This begs the question – why not just call it a beta now? Because we don’t want to set the expectation that things are remotely complete at this point. There’s a lot of things people will be able to do with nexus that aren’t implemented yet.

De-prioritizing Support for a Use Case

In our initial prioritization of use cases listed broadcasting of nexus content as a high priority for the second release. This is an important behavior for Paul the Product Manager, one of our personas. We still believe broadcasting is important to Paul. However, we believe the cost of making it easier for him is not justified.

Paul can easily send an email, instant message, twitter tweat, jaiku update, cocktail napkin, blog post, or other message to people about an article at nexus. All he has to do is cut and paste the URL for that article. Ideally, he will cut and paste the nexus URL, encouraging people to rate the article and join our community. Or he may just find the article on nexus, and send the link to the original article. That won’t directly help us, but it will still help him achieve his goals.

Anything we do to facilitate this communication for Paul will at best take the same amount of effort for him, and most likely take more effort (and constrain his means of communication). And for marginal gain on our part. And there’s no way to assure that Paul will use our embedded implementation – he may still just cut and paste. Based on the non-zero cost of implementing, and the near-zero benefit (to Paul) of implementing support for his broadcasting, we won’t be implementing that within nexus. Hopefully Paul will tell people about nexus when he tells them about the article that they should read.

Thoughts About Capabilities

With the current functionality, nexus can become what it needs to become – a repository of validated content. With the ability to submit, rate, and review articles, we can collect the needed resources. With the ability to search, browse, and filter, people can use the site to find the content they are interested in. We can refactor the interface to make this easier – but the base functionality and presentation are in place.

One very powerful idea that came up during the evolution of use cases and design approaches was the notion of creating collections of articles that can be used together to achieve a learning objective (or a teaching objective). We think this may very well be the killer feature that makes nexus the place people go to understand a topic in our niche. Many companies succeed by combining available components and bundling them together for sale – the whole is greater than the sum of the parts. This is true of ideas as well.

In effect, each bundle of articles can be the equivalent of a multi-author book, or multi-instructor training curriculum. There are some other interesting unintended uses that could arise – bundles of articles where the goal is a shoot-out between several similar treatments of the same topic. People might create bundles of articles by their favorite authors. Training curricula could be formed in a general way (Learn to do Use Cases) or for very specific circumstances (Learn how to manage risks and schedules for projects at company X).

Prioritized Goals

Based on the above, and other similar analysis, here are the goals for the third release of nexus.

1. High Priority. Support for creation, editing, scoring and reviewing of bundles of articles. (Must have)
2. Medium Priority. Publish an RSS feed of newly created articles to which people can subscribe. (More is better)

There are also some low-priority goals, basically tweaking the presentation layer. These will be (possibly) addressed as targets of opportunity during implementation of other goals.

Next Steps

The two things we need to do next are develop the use case(s) for bundle interactions, and work on some design ideas.  If you think we should be taking a different prioritization approach, please join the discussion on this article.

The next build of nexus starts today as our agile project continues. Let us know what stuff you think is most important for this release, as part of our prioritization.

Already Scheduled Work

We already know that we’re going to focus on a couple items for this release of nexus. These items represent, as Roger put it in recent comments, areas of highest risk. Our interpretation – risk is the risk that the site won’t gain critical mass and become the valuable tool that it can be.

• Searching Articles. This is one of the previously identified use cases – also previously targeted for the second release.
• Pagination of Articles. While not a requirement per se, we are introducing this refactoring of the design as the most significant usability concern that has arisen. There are currently only 18 articles on nexus – and when you view an unfiltered list of the articles, you see all 18. When this list is 50 or 100 items strong – which should be this week – pagination will have a significant impact on usability and adoption. So this is on the top of our list for refactoring.

As an interesting aside – these are both technically challenging activities too – so they also represent two of the higher technical risks.

Other Possibilities

Here’s a quick list of other items, not in priority order, that we may work on this week. We will look at prioritization of them as early as later today – and as late as the completion of pagination and a first version of search.

• Broadcasting an Article – notifying someone who isn’t a registered nexus user about an article.
• Creating a Mashup – allowing users to create collections of articles that can be used for organizing ideas that span articles.
• Suggestion of Articles – provide article suggestions based upon the scores that you and others have given to articles on the site.
• Allowing article deletion/moderation – give moderators the ability to suppress articles that don’t contribute to the community.
• Allowing review suppression – give registered users the ability to suppress reviews that detract from the experience for people.
• Present a feedback form / suggestion box – allow users to make suggestions about how to improve the site.
• Enforce article uniqueness by URL – prevent duplicate submissions.
• Create an about-page for nexus – explaining the purpose of the site beyond the snippet in the sidebar.
• Create help documents – explaining how to accomplish goals with nexus.
• Create a subscription service – allow people to subscribe to notifications when articles are submitted to nexus.
• Allow users to edit their info – change password, email address, other data.
• Refactor the presentation of articles – time-box 2 hours for a redesign / treatment of presentation.

Your Suggestions

And any suggestions that y’all want to make at this time. Maybe some of the ideas above either inspired you to suggest new ideas. Maybe you have thoughts about the approach to implementing any of the above. Please share them in the discussion on this article. If you feel strongly about any of the above – either for inclusion or exclusion (or delay) – please share that input in the discussion below. And remember, you can subscribe to the comments for individual articles – so do that if you want to track this discussion as it unfolds. We’ll take all of the inputs into account when prioritizing these efforts for the current release.

Rolf presented a valid critique and some questions on our previous article announcing the launch of nexus. I started writing a long response, and realized it would work well as an article for analysis of our process over the last month. Here it is.

Rolf’s Critique and Questions

Here’s the critique/question part of Rolf’s comment:

However, allow me to comment on the agile project experiment (no offense intended !).
For me, in an agile project there’s no room for “Bonus Features -
a couple other things implemented early while we were there”. I’d like to see us come back to the original idea of prioritization (which can mean a change of priorities with the help of the users).

All new ideas or things we stumble upon should undergo the same persona/usecase/priorities analysis as the original ideas did. Otherwise this project leans over to hacking. (However, I respect your dictator role, Scott.) This should be done for the purpose of the experiment reader’s (and my) education and their chance of gaining insight. I know that it is easier to skip these things, but that is not what we are preaching in agile/lean product development classes/articles/books.

On the other hand, can the “change of plan” be interpreted as an experience with agile projects? Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products? (or even further, that projects should be created so, that a product manager can implement his own vision ;-)
This would be very interesting knowledge I gain from the experiment.

I’d love to know what YOU are thinking about the project’s process. Why did we deviate?

Hey Rolf, first – thanks for the help on the project, I’m looking forward to more as we go. Second – thanks for the spot-on critique of the “bonus features.”

It is definitely not agile. Can I plead temporary insanity? I cite as evidence the “ideas” section in the previous article. That is definitely the right way to do it from an agile standpoint – throw ideas into the prioritization mix. I would also add that there is an element of dictatorial product management in the mix. We can walk through each of the bonus features and see what we think…

Here’s how I would categorize the ‘bonus features’ above:

• Faceted navigation & URLs – an interaction design-driven part of the implementation approach. I would contend that this is orthogonal to the prioritization process. This is getting good ideas at a lower level, into implementation. I think this was wholly appropriate and not subverting the process. Maybe it feels clunky trying to mix it into the other discussions, but I didn’t view it as “implement and refactor without reprioritization.” I felt that the ‘out of the box’ routing (/nexus/article/show/12) was sophomoric, and the implementation of the first version of page navigation (specifically for browsing) required some form of IA implementation and solution in order to create the nav-bars. So this was the first proposed solution for browsing – just with user feedback.
• Having reviews in the first public release. I would say that this was just bad form on my part. A sign of weak project management. The product manager (me) knew it was important – it was scheduled for the second release. The developer (me) knew it was relatively easy – what I had just learned as part of implementing article-submission made it easy to extend to reviews. The project manager (me) was still busy freaking out about the risk of XSS attacks and was distracted by the demands from the President (me) that the site not go live until acceptable security measures were in place. The developer (me again) and product manager (me) snuck it into the first release. We occasionally show disdain for me in this way.
• Rating a Review – I put this in the dictatorial product manager bucket. I felt that it was important (as part of allowing comment/reviews) to the notion of credibility and trust, that we have this feature. Especially since to make it happen required 30 minutes of learning/refactoring the existing rating implementation to apply it to reviews as well as articles.
• User Page – hmm. Don’t really know if I can sneak this in as design or dictatorship. Just seemed like the right thing to do. Wasn’t in any of the mockups either – just appeared during development.
• Calculating a User Score – OK, so this one is definitely a violation of prioritization. And it probably took a couple hours to figure out and implement. I did get some feedback offline on the design and approach, but will it demonstrate value – maybe. No way to describe this one as anything other than “not following process.” Slapping myself on the wrist now.

Drawing Conclusions

Getting back to Rolf’s question – “Can we deduct that it is more important to have a strong product manager than to have a clear process for transforming ideas into products?”

I think people trump process any day. But a good process makes people better. So process is worth pursuing. I have a struggle on this project, wearing dev/design/product&project management hats. Plus I have the dictator-card. And blogging about the project as we go, while really useful info for learning, is also a form of inappropriate, low level marketing announcements. We’re essentially broadcasting very prematurely, about every move we make and when we’ll make it. So this study is a bit polluted. By watching the process, we modify the process. Good thing this isn’t a quantum mechanics experiment.

I think design inputs are valid elements of the implementation (faceted navigation as an implementation choice for browsing). I think a process that prevents convenient low-hanging fruit (rating the quality of reviews) is a bad process.

Also, I think we made a mistake in including reviews in the first release without re-prioritizing first. In my defense, the security-thing threw me for a bit of a loop, and reviews were not part of the very-first release (which was shared with the Austin on Rails developers). I probably should have just addressed security and released without reviews. As a developer, I needed some occasional breaks and accomplishments to make the days of reading about XSS and SQL-injection solutions more fun. And that’s what I ended up doing. Probably shouldn’t have.

We did get some good user feedback about reviews being more important than numerical ratings for some people. So it was easy to “cheat.” I think the dictator philosophy is actually a good one – listen to your customers – absolutely. But that doesn’t mean you do exactly what they say. You do what they need, to the best of your ability, which is highly aligned with what they say – but not exactly the same thing.

What Do You Think?

What should we do differently next week as part of building out the next release? Our plan is to start with prioritization of pending / new ideas.