Most companies ignore their markets – and they will struggle to survive.  Some companies listen to their markets – and they have an opportunity to succeed.  You have the opportunity to understand your market, and transform it into your market – but you can’t get there just by listening.

Don’t listen to your market, understand your market.

Zappos All-Hands Meeting

Thanks Thomas Knoll (@thomasknoll) for pointing out that Zappos’ all-hands meeting was being live streamed today!  [Aside - how cool is that?!]

Chip Conley (@chipconley) spoke to the Zappos (and Bellagio) folks about several things, including being customer-driven.  He was able to pull several ideas from his book, Peak: How Great Companies Get Their Mojo from Maslow, but one of them stuck out in particular as being critically important to product managers.

Transformation Pyramid

There’s a copy of this on slide 28 of this presentation on Slideshare, essentially an adaptation of Maslow’s hierarchy of needs, applied to customer relationships.  It is not clear if this is an approved (by Mr. Conley) posting, so I’m not going to include a fair-rights copy of the image.  You can find out more by reading his book, visiting his website, or dive right into an application of this model to Wall Street from Mr. Conley’s blog.

The basic idea (for focusing on your customers) boils down to this:

1. At the base of the pyramid, you have companies that meet the expectations of their customers- they provide what customers expect (and no more).  In his presentation today, Mr. Conley pointed out that these companies will struggle for survival.  Good enough isn’t anymore.
2. At the next level of enlightenment are companies who meet the desires of their customers.  These are companies Mr. Conley points out as ones who will succeed.
3. At the top of the pyramid are companies who meet the unrecognized needs of their customers.  These companies, through understanding their customers, satisfy needs that people didn’t know they had.

In an earlier article on sustaining a market-driven competitive advantage, I wrote about listening to your customers (#2) and innovating in order to uncover the latent requirements.

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

That article was written with an inside-out perspective – essentially answering two questions -

• “Why should you innovate?”

• “Why Should You Innovate Repeatedly?”

As you repeatedly invest in understanding your customers, you gain insight into their latent requirements and needs – and get an opportunity to address them.  When you do this repeatedly, you become a thought leader for your markets, which you can leverage as a distinct competitive advantage.

Conclusion

Mr. Conley is approaching innovation, with respect to customers, from an outside-in perspective – and reaching a similar conclusion.

When you understand your customers, well beyond meeting their must-have minimum expectations, and beyond addressing their explicitly stated desires, you have the opportunity to solve the problems they don’t realize that they had in the first place.

From my perspective, his insights make it even more important that you continually focus on what your customers really need, and let your market guide you.  Not to be confused with “give your customers what they ask for” – they’ll only ask for a faster horse.

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

Strategy First, Roadmap Second

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

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

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

Market Myopia

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

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

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

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

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

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

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

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

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

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

Thinking Strategically

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

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

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

We know the importance of identifying the use cases that enable our business goals. We also know the value of understanding the actors that will use our products. This article shows how to demonstrate a simple but powerful view that maps the use cases to the actors.

Why Map Use Cases To Actors?

Most use case templates and requirements documents include a place to list the actors for each use case. Very few encourage us to provide a big-picture view. Even users of requirements-management systems are left without an easy way to show this perspective. Can it really be valuable, if it is so often overlooked?

A critical element of defining and managing requirements is assuring completeness of your requirements. The first step to assuring completeness of your requirements is to acknowledge that the requirements represent a structure of decomposition of a problem.

Once you’ve identified the goals of the business (or the problems faced by customers within your market, when taking a multi-customer view), you need to recognize that those goals are achieved by enabling use cases. Each of those use cases is then enabled through the implementation of functional requirements.

Part of defining use cases is defining the actors (a.k.a. users) that perform those use cases. You can (and should) use an actor hierarchy to describe the users. If you fail to define the actors effectively, you risk creating the elastic user anti-pattern. This anti-pattern is what happens when you lose sight of the differences between different user groups. You run the risk of designing a solution that fails to meet the needs of any one group of users, by homogenizing them into a lowest common denominator user. Or worse, cutting user-experience corners, and designing “whatever is easiest” and justifying those decisions by rationalizing a schizophrenic actor who changes characteristics to suit your designs.

Most people defining requirements (product managers and business analysts) will do a good job of defining use cases, and identifying the actors that use them. And most tools and books provide good guidance on how to define an actor, or how to define the actors for a single use case. But so few can give you that big picture.

Requirements Iterative Development

If you have worked the entire lifecycle of a requirements process from problem to solution, you have experienced iterative requirements development. Most requirements processes work top-down (some prototype-driven processes are more “bottom up”). Define the goals. Then define the use cases needed to achieve those goals. Then define the functional requirements…

Hold on.

Don’t let that “agile requirements” vs “waterfall requirements” debate sneak in here. That’s a matter of formality and scale. What we’re talking about, specifically, is iterative development that happens as a result of insight, independent of (or in spite of) the process used. This applies to any process for defining requirements.

You define a set of goals. You may or may not validate that set of goals. You think you are done. You start defining the use cases and mapping them back to the goals. You discover two things. First, some goals are not mapped to any use cases, and second, some use cases are not mapped to any goals. You resolve this. You add and remove goals, and you add and remove use cases. The act of defining the use cases enlightens you about the goals they are intended to support. You are iterating on your goals. Unfortunately, a lot of project managers don’t understand this, and build a schedule around a milestone such as “business requirements approval”. Then when you apply your insights into a revision (iteration) of your goals, during the “use case development phase” the schedule is blown.

You do your change requests, reset expectations, and manage the political fallout of a schedule change. Then after “use case approval”, you move into requirements definition. As you document requirements, you uncover new use cases, or rewrite use cases, or otherwise benefit from the insights you have. And those changes to use cases propagate back up into changes in requirements. Now you’ve really messed up the schedule. The way some people fixate on schedules, you’d think they would rather stick their fingers in their ears and keep the schedule than benefit from improvements now, when they cost 100 times less to fix. Oops. Guess I went on a rant, there.

This is also commonly called “requirements churn” and can be tracked – either in a good way or a bad one. The bad way to track this creates an environment that discourages change (“you better keep the schedule!”). The good way to track this creates an environment of “get it (more) right the first time.”

One way to get it “more right” the first time with your goal definition is to look at the big picture with your use cases. One piece of that is mapping (or tracing) the use cases back to the goals. Another tool is to create a mapping between your use cases and your actors.

Use Case To Actor Mapping

Create a simple grid in a spreadsheet. Each row is a use case, and each column is an actor. In each cell, when the actor is the primary actor for a use case, add the letter “P”.

Primary Actor

The primary actor is the person who is the subject of the use case, performing the verb of the use case on the object. A use case may have multiple actors but has one most important person. The term actor represents the person who takes action – not someone playing a role. Other actors may be involved, either as participants, or as infrequent or secondary performers of the use case.
Some examples:

• Primary Actor: Pilot. Secondary Actors:Flight Crew, Sr. Maintenance Technician
• Primary Actor: Author.
• Primary Actor: Financial Accountant. Secondary Actor: Financial Accounting Manager

Foundation Series: How To Read A Formal Use Case

A simple grid with a handful of use cases and actors would look like the following:

The interesting analysis this allows you to do (and it is more powerful with a larger body of use cases and actors) is to review the big picture. You would ask yourself “who does each use case?” even without this tool. That’s just part of writing the use case. Now you can also ask “what use cases does each actor perform?” And you can easily see to ask questions like “If A03 does that, why can’t A02 do it?”

This big picture analysis, in my experience, will also accelerate the discovery of missing use cases. You should also capture when an actor is a secondary actor in the use case. You will then have a grid that looks like the following:

When asking the comparative questions about UC03, you uncovered another use case.

This tool accelerates those insights, allowing you to make changes “further upstream”, or if your glass is half-empty, correct fewer mistakes later.

Conclusion

Use the use case to actor map to provide a big picture view of how people will interact with your product. This view will improve your understanding of how people use the product, simplify the analysis, and encourage insights earlier in the requirements process.

Problems are the reason why we create software. We solve problems. For the business. A “Goal” is an acknowledgment that you are going to try and address the problem. One mistake people commonly make is to describe problem manifestations and not problems. Read on to see the difference.

Problem Manifestation

Someone recently forwarded to a mailing list an article about how to define the impetus for requirements. The article was written by someone at a “product management training and consulting” company. Instead of linking to the article, let me just say that it inspired me to write this article, and not because I agree with it. So, the names are removed to protect the well-intentioned.

That article starts with a statement I really agree with, and one I really don’t agree with:

• The Good: “All great products begin with a well defined need.”
• The Bad: “Starting your requirements with a problem statement is a problem.”

The article goes on to describe a problem manifestation*, labels it as a problem, tells us it is bad, and then goes on to propose an alternative. Don’t Build a Stupid Product Roadmap shows a similar phenomenon – someone well intentioned criticized a really horrible product roadmap, and errantly drew the conclusion that product roadmaps are bad. This is the same thing. Problem statements are not bad – in fact, they can be one of the most effective tools for clearly communicating the vision of a product.

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

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

Abstract Your Problem Correctly

When you elicit a problem from users, it is usually a description of a problem with their procedure, or the design of their product.

• I can’t keep my tires properly inflated.
• It takes too long to find the information I need about the customer who just called me.
• My price catalog is always out of date.

These are examples of how problems manifest, given a particular process or product design. If you start with a problem manifestation like one of these, it will be impossible to avoid design cues in your requirements. And you should always avoid specifying design in your requirements. The article that started us down this path is correct – these are bad things. The solution is not to abandon problem statements. The solution is to abstract them correctly. This is a skill that great product managers have, and all product managers need.

Properly abstracted, the problem manifestations above could be rewritten as problems.

• The cost of operating my car is too high.
• I lose too many customers because their calls for support take too long.
• We are making unprofitable sales (and losing other sales) because we quote incorrect prices to our customers.

These problem statements can be turned into goals, from which the rest of your requirements can be defined. Goals would be in the form “Reduce the cost of operating my car by 20%.”

You can abstract too far. You know you’ve gone too far when the problem statement does not give you any insight into what problem you are solving. Here are the same three examples, abstracted too far.

• I don’t have enough money.
• We don’t have enough revenue.
• We don’t make enough profit.

This abstraction problem is a common one in product management. It has come up in a handful of discussion threads over the last couple of years here, and is a key point in a couple articles too.

• We see incorrect definitions of problem statements.
• We see incorrect definitions of use cases.
• We see business rules and requirements at the wrong level.

Don’t go too far, or your team won’t know what to do. The goal is to understand the problems that affect multiple customers in your market – not just a single company or user. Make sure you abstract far enough, or you won’t actually solve the valuable problems. And without valuable problems to solve, you can’t write valuable requirements.

Conclusion

Problem statements are awesome. They define the scope and vision of what you intend with your software. They provide a framework for measuring the value your customers see from your product. They provide context for prioritization and design decisions.

Problem manifestations are too low level to achieve any of these goals. They are bad.

Don’t abandon your problem manifestation, just ask “why does that matter?” until you reach the proper level of abstraction. Then you’ll know what the real problem is.

Logic is a funny thing. People can make the following argument: “Building a stupid product roadmap is bad, therefore, don’t build product roadmaps!” Ahem. [Author cracks knuckles] Read on for a rant.

The Argument Against [Stupid] Product Roadmaps

David, at 37signals, wrote an article about the problems with product roadmaps. Thanks, Amar, for sending me the link. I believe the article was written by David Heinemeier Hansson, since there are several comments from “DHH” in the contentious debate that follows. Maybe the article was meant to be contentious link-bait (the blogging equivalent of trolling in a newsgroup). Maybe DHH/David hasn’t been exposed to a good product roadmap.

Either way, consider me hooked.

The comment thread on the article is fun to read, and gets emotional. And that’s a good thing. People should get emotional about how we create software. It is a creative process. Just because we use science and engineering disciplines does not mean it is not creative – we just use a different pallet of colors than canvas-artists. So emotion is good. I also contend that every great product is imbued with passion.

The comments were closed four days after the article was published (last November), so we can only chime in here.

Ade Oloneh blogged a well reasoned response to David’s article. Ade sums up the heart of David’s article really well, so we’ll just quote him:

The article makes a lot of assumptions about people who have a product road map:

• They add all feature requests to the road map
• They don’t do due diligence before adding features to the road map
• They sell their software based on the road map, not the current features
• They share their road map with current and prospective customers
• They promise features to current and prospective customers

I agree that all the things above are bad, but to me this doesn’t translate at all to: don’t use a product road map.

<cite>Ade Oloneh</cite>

Ade then goes on to describe the positive experiences that he and his team have had in developing a roadmap for the Formspring product. He generally mentions that he does not do any of the stupid things in the list above, and points out that roadmapping has worked well for them.

Jeff Lash, of Good Product Manager fame, added an excellent comment to David’s article, and another great one to Ade’s article with links to more resources. His main point:

A road map is a tool. Like any tool, it can be used well or it can be used poorly. Saying that it’s a useless tool because some people misuse it is shortsighted and irresponsible.

<cite>Jeff’s comment on David’s article</cite>

Even Pragmatic Marketing offers a class – just on product roadmaps! It would be money well spent for DHH and team to check out that class. They could create even better products, and improve their customer relationships.

The Argument For A [Smart] Product Roadmap

We’ve looked at the value of product roadmaps for enterprise software before. I guess our theme of “broad and deep” resonated a little, since several comments on the original article were ad hominem attacks fixated on the contrast between enterprise product management and small company product management. What we failed to do effectively is point out that this approach applies to all product development.

Now we get back to the “traditional” requirements work. An application has a set of requirements, which are prioritized, and which drive a product road map and implementation plan. This is a long term, deep, product-centric view of the world. The product manager focuses on the users and their goals, as well as the business stakeholders and their goals. These are combined to define the road map for the application. Much like any other product development.

<cite>Enterprise Product Management – Broad and Deep</cite>

That article was specifically addressing how product management within an enterprise is something that happens in the context of the enterprise – and other moving parts, and concurrent development of other products. All very true. But that is not the only reason for creating a product roadmap. In a response to another comment, DHH could have been responding to our article:

I think product road maps make a lot of sense when you’re trying to coordinate supertankers like Apple because the iCal.app team needs to have an idea of when Leopard is shipping. And the iTunes team needs to know when the iPods are getting updated.

But actually, I think calling that a product road map is stretching it’s generally accepted definition. That’s more of a company coordination map.

A road map for an individual product that doesn’t have strong dependencies to other releases is a lot more questionable in value. What exactly are you getting out of deciding 3, 9, 18 months in advance what to work on? What extra powers are you gaining? I’d say very little.

<cite>DHH’s comment</cite>

And that comment is the reason I decided to write this article tonight.

Elements of a Product Roadmap

A product roadmap is the product-manager’s equivalent of a project manager’s rolling wave planning. In a sound-bite, you provide short-term details (for the next release), and long term “broad brush” discussions. If you don’t plan your product to address the needs of a particular market, and then execute against that plan, the only way you will succeed is by luck.

The long-term view of a product roadmap does not talk about features, or even capabilities. What it talks about is problems. Problems faced by your customers, in your target market(s). Last week in one of Pragmatic Marketing webinars, Steve Johnson quoted Peter’ Drucker’s famous saying: “The aim of marketing is to know and understand the customer so well the product or service fits him and sells itself.” Steve points out that (1) this is the aim of product management, and (2) when Drucker says ‘customer’ he means ‘the customers in your market’ – he’s being abstract.

Each item in your product roadmap – specifically 3, 9, or 18 months out - should be a problem faced by your customer. If you’re a good product manager, you will tackle the most valuable problems first. In the course of those first three months, you may uncover even more valuable problems to be solved. So you re-prioritize! When you’re right, your customers will not complain – they will thank you. Because you will be solving a problem that is even more important to them. With each incremental release, you address the most-important unaddressed problem. And you learn more about your customers (and your market). When you learn that the plan should be updated, you update the plan. This isn’t spring cleaning, where you blindly follow last year’s plan because it isn’t time to replan. This is continuous improvement, applied to product roadmaps.

Not only do you get smarter, but things simply change.

When you define a product roadmap, you also define the release dates for your product. Change happens. Your market changes, your customers change, your requirements change. Unpredictable events happen. Your competitors release a new killer feature, your developers have an epiphany (or run into a roadblock). Should you change your release schedule?

<cite>Scheduling Product Releases</cite>

You can adapt to that change, or you can ignore it. If your adaptation is only to update the product backlog for the current sprint (release), then you will be forced to deal with that change again and again with every release. If you update your roadmap, you only have to deal with each change once. And that leaves you more capable to handle more changes.

There is value in sharing your product roadmap. You let your customers know that you know what problems you are going to solve for them. And you let them see that you have become smarter about their problems when you do become smarter.

There is risk in sharing your product roadmap. Maybe part of your distinctive competence as a company is that you understand your customers, and your competition does not. Why help them?

You have to decide if you share your roadmap publicly (or “privately” with your customers). But you shouldn’t hesitate to have a roadmap.

Value of a Product Roadmap

There is value to your customers in knowing your roadmap. You can use a roadmap to effectively manage customer expectations with less effort and more consistency – and a more visionary horizon. You aren’t just waving your hands at a “product vision” – which is important too – you’re backing it up with “and here’s how we get there.”

There is value to your team in knowing your roadmap. You provide context, which is critical to addressing stakeholder goals. At a more tactical level, context provides a framework for interpreting requirements. As much as we strive to avoid ambiguity in requirements, there is still always room for context to bring even greater clarity.

Just make sure you don’t become a slave to an old roadmap. Keep it current. Use it to chart your course. And when your course changes, update your roadmap.

When do you update a mature product? When it is more profitable to update it than to let it ride. This question was recently asked at Ask a Good Product Manager, and we have our own take on the answer.

The Question

At Ask a Good Product Manager, the following question was posed:

Question: How do you decide to release a new version of a product?

My question is specific to products used by almost everyone in the world — products like Windows, MS-Word, Adobe Reader. For such products, how does product manager decide for the next release of such products?

Notice that these products are already at a level that almost everyone using it is more-or-less satisfied with them. For example: Having released Microsoft Office 2003, how would the product manager decide that we need Microsoft Office 2007?

For the record, we are fans of both Nick (who answered) and Jeff who started the site. A good product manager would check out all of the good questions and answers there. We just have a different approach than the answer that was given.

The Bottom Line

The bottom line, as they say, is the bottom line. So that’s where we start.

You release a new version of a mature product when it is more profitable than not releasing a new version.

It’s all about ROI (return on investment). Just as you use ROI to prioritize which features go in a release, you should use ROI to determine when to release, and if there should be a release at all. You can identify problems that are being experienced in your market or a new-to-your-product market segment. You have to determine how much incremental revenue your company will get through sales, directly as a result of solving those problems. This sales number is relative to the sales you would get if you did nothing.

You also have to figure out the cost of implementing (define requirements, design, develop, test, deploy, train) solutions to these problems. Note that you won’t include the costs that you would otherwise incur (support, maintenance, etc). Those are sunk costs, and you will have them no matter what you choose to do. These are your incremental costs of doing the new release.

If your incremental revenue exceeds your incremental costs, then there is a positive ROI associated with putting out a new release. That alone is not enough to green-light the project. You have to consider the opportunity costs. You could very well invest in something completely different, and make even more money. Wouldn’t you rather do that? So your ROI needs to exceed your hurdle rate, which reflects the opportunity cost of doing something else.

To sum up, your return on a new release needs to exceed your hurdle rate. The return is a function of incremental revenue and incremental cost.

Nick offers some good advice in his answer about not building a product that is too complex, making sure you understand your users, and the possibility of removing features in a new release. But all of those tactics are in support of the strategy: make more money. [Note: a charitable organization might use 'do more good' as an alternate to financial utility measurement.]

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…   And this week, we crossed over the 100 article mark!  Thanks to everyone who has submitted articles at nexus for helping us reach this milestone!  We’ve also had 150 ratings of the articles, and over 2000 readings.  Nowhere near the critical mass we need yet, but making progress.  Thanks to all!
Solve Customer Needs, Not Business Ones filed in product management

If you want to be a bad product manager, create new products based on business desires and existing assets. If you want to be a good product manager, create new products that fill customer needs that are not currently being met.

Making Product Roadmapping Work For Your Business filed in product management

Product roadmaps can be powerful assets to leading a technology business – buy only if they are created and managed in the context of appropriate policies. In fact, the product roadmapping process a company uses can be as important to its business as the roadmap itself. In the Product Strategy Network’s roundtable meetings on product roadmapping, field-tested practices and policies are presented in detail by PSN Members. Here are a few of the highlights:

Business Analysis: A Potted History filed in business analysis

This article is an informed and wide ranging history of the profession/role of the business analyst.  Written by a developer for developers to help understand the role and how to work with them.

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

Software Development’s Evolution towards Product Design filed under product management and project management.

Very insightful and fun view of how software is made – and how that process has evolved over time. Great images, great way to explain to “other folks” how software gets created.

Yours, Mine and Ours filed under product management and interaction design.

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

Requirements Traceability filed under business analysis and project management

The V Model; A Testing and Validation Model filed under business analysis, project management, and testing

This link is to a series of blog posts on the V-model. The V-model is a testing and validation framework for software development projects.

This article is useful for business analysts new to the software development world and highlights key quality gates in the development and implementation of software. The articles focus on what a Business Analyst or Project Manager should know about the process.

It Is Still The Requirements filed under business analysis

Identifies the assumptions most commonly made by business analysts. Also provides high-level steps for how to avoid those assumptions

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

User Experience Design filed under interaction design

Peter Morville on information architecture and the user-experience honeycomb
I’ve been practicing information architecture since 1994, and from Gopher to Google have seen dramatic changes in the landscape of organization, search and retrieval.

Through these ten tempestuous years, I’ve found the infamous three circle diagram to be a great tool for explaining how and why we must strike a unique balance on each project between business goals and context, user needs and behavior, and the available mix of content.

Requirements Model 2 – The Decision Tree filed under product management and business analysis

Good explanation of how to create a decision tree as a visual artifact when gathering requirements

UML 2 State Machine Diagrams filed under product management, business analysis, agile development

Overview, explanations, and details from Scott Ambler. This documentation approach can be used for agile and non-agile processes. It can also be used for product management / development and for business analysis.

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

The Popcorn Way and the Business Analyst in business analysis

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

10 Commandments of Product Management #1 in product management.

Michael Shrivathsan’s article Know Thy Customer.

Details on the following five approaches to understanding your customers better:

1. Listen to customers.
2. Usability tests.
3. Follow-me-home.
4. Walk-a-mile.
5. Customer surveys and focus groups.

Why Use Tasks? in agile development

Lists 9 reasons why your dev team will benefit from dividing user stories into tasks. A couple of paragraphs of detail for each reason.

Pioneering A User Experience (UX) Process in interaction design

Amy Hillman and the Boxes & Arrows staff walk through how to approach, justify and manage the first UX project for your company

Each Friday, we highlight some of our favorite articles, bundles or reviews that people have submitted to nexus. Check out this week’s Friday Favorites…

Here are my favorites from the latest articles submitted at nexus. Check them out, rate them, review them.

Share Your Secret Moves in product management.

The Cranky PM throws out a request for strategies and tactics and gets several in the comments.  The question:

How do you tell customers that feature X won’t be in the promised release?

Set the Right Release Dates in product management and project management

Advice about making sure that release dates are not set arbitrarily, but rather, have associated compelling events.

Seven Traits of Successful Product Managers in product management

Good detailed description of a great list of traits that correlate with success for product managers