Monthly Archives: October 2006

Prioritize With Poe – Halloween Fun

Edgar Allen Poe

Once upon a morning meeting, while we wasted minutes fleeting,
Over many an issue of status one through four,
While I listened, eyes glazed over, suddenly there came a question,
As if a project sponsor asked which feature we need more.
”Tis prioritization,’ I muttered, ‘asking ’bout the issue’s score –
Only this, and nothing more.

Ah, quite clearly I recall, it was in the VP’s meeting hall,
Where business and developers cajoled and implored.
I looked at our rework allowance – vainly had I sought to balance
New functionality and fixing bugs – bugs that just might stop the show –
For the worst bugs might just crash the server don’t you know –
More importance drives the score.

Each single issue raised the specter of abandoned users
Losing capabilities – precious for their goals and more;
And as my whiteboard marker fluttered on the board
I created buckets of priority on the board –
Each separate bucket of priority on the board; –
We sorted issues by their score.

Post-its placed in each big column; organizing our big war room,
‘Search is broken from command line’ one of the coders roared;
Bucket one or maybe two he claimed, priority it must be highest,
Without it I can’t test my code. Never use it, user muttered,
I only search by person’s address, and search works fine for postal codes,
Better move to bucket four.

Spelling errors, cryptic messages, the wrong colors on the screen,
Urgent, critical, must-have-features, struggle to avoid the sink-hole for
Never will the dev team finish all that we will relegate
To the least important bucket, the one we know as bucket four.
The oft forgotten, if there’s still time, budget busting bucket four.
Keep mine out of bucket four.

Can’t remember if they told me, how important that one can be,
If the moon is one-fourth waning, and it happens on a Monday morn.
‘Impact,’ I said, ‘can be quite large – if that happens as you said;
but divide by fifty to adjust for circumstances you deposed –
it almost never happens in the circumstances you deposed; –
Allocate to bucket four.

Sponsor’s teeth are grinding loudly, neck veins bulging to explode,
‘My favorite feature you’re forgetting!’ I must admit it was ignored.
Politics and process battle, to the victor goes the spoils;
But features sort by prioritization, we all agreed to rank by score –
Leveraging his lofty title, the sponsor forced a change in score –
Removing it from bucket four.

The list grew smaller, one by one, of issues still to be decided,
As we slogged through more discussions of the buckets one through four,
‘We’re not yet balanced,’ I implored, ‘our numbers aren’t realistic.’
With six of ten in bucket one, and one of ten in bucket four –
‘They can not all be most important’ some of them are less not more –
Shift some more to bucket four.

Balancing the less important wasn’t easy first time through,
But we all struggled, sorted, balanced – slowly filling bucket four;
Pointing out the most important still would be the first we tackle
Until we’ve used up time remaining – unless we choose to ask for more –
We fill each timebox in each cycle – unless we choose to ask for more,
Our only hope for bucket four.

Cutting quality is not an option for delivery of our software,
Time and people, money and scope, but we can not risk the product’s core.
Something falling, from the whiteboard, falling slowly toward the floor –
His favorite feature, flashy graphics, written on a post-it note,
Bucket three was somewhat crowded, on the whiteboard by the door,
Hoping to avoid the stigma, tender lifelines for the features,
All avoiding bucket four.

No one noticed as I bent down, picking up the post it note,
Breathlessly I looked around, the project sponsor had grown bored,
Conversing softly about wineries, our politician had not noticed
His post-it was not where it started, on the whiteboard by the door –
Adrenaline was taking over, I was shaking as I crossed the floor
Returning it to bucket four.

The meeting ended moments later, and the minutes were sent out that day,
No one noticed my correction, removing it from near the door;
The feature was where it belonged, politics be damned I chuckled
Priority would win this battle, with flashy graphics in bucket four –
Opinions lose to facts in battle. Lowest value? Bucket four.
Issues we now sort by score.

Writing Correct Requirements

Big Ten Logo

We ran a series called Writing Good Requirements – The Big Ten Rules in May 2006. Bloggers are notorious for not being able to count. We had ten rules at the time, and now we’re adding an eleventh. Writing Correct Requirements may have been the unwritten rule, but now we take a look at it.


The original series started with a summary of the ten rules to writing good requirements, and then we followed up with ten articles with details of each rule. And now we add another one – writing correct requirements.

The Big Ten Eleven Rules of Writing Requirements

  1. Valuable
  2. Concise
  3. Design Free
  4. Attainable
  5. Complete
  6. Consistent
  7. Unambiguous
  8. Verifiable
  9. Atomic
  10. Passionate
  11. Correct

Correct Requirements

Correctness in requirements is simply about getting it right. We wrote previously about how to apply use cases to creating correct requirements. Writing requirements correctly is as much about getting accurate information as it is about accurately documenting the information we gather.

Correctness applies in a context. “Are these the right requirements to achieve goal X?” Verification is the process of verifying that we identified the right requirements to achieve a particular goal. Validation, on the other hand is the process of assessing requirement completeness. People often swap these terms as being nearly synonymous.

Verification Techniques

To verify that requirements are correct, we start by asking two simple questions. Here’s an example for writing a software requirements specification. Set aside for the moment that some people consider this to be design, although from a developer’s perspective, it is a specification (or requirement). This serves as a good example for business analysts.

  • Does each of these requirements contribute to achieving our goal? If a requirement does not help us achieve the goal that it supports (in a structured requirements framework), it is not a correct requirement. Either the requirement is placed under the wrong goal, or it truly doesn’t belong.
  • Can our goal be achieved without these requirements? If our goal can be achieved without the requirement, then it isn’t required. “The system shall generate a report of all outstanding customer bills” is a requirement. If the goal is “Identify a customer’s unpaid bills”, then “The system shall display any unpaid bills for a customer” is a more correct requirement, because the goal can be achieved without a report.

A market requirement (useful to product managers) would be “Reduce the cost of accounts payable by 5%.” There is an ideation step in going from documenting market requirements to documenting product requirements. In that step, a product manager will decide how to approach, with her product, the reduction of accounts payable. Consider the following approaches and requirements and their hypothetical correctness verification.

  • Approach: Remind customers of outstanding bills. Requirement: “The system shall generate past-due notices for all bills on the monthly anniversary of each bill.” This requirement would not be correct if bills are issued with 90-day terms, because the bills are only due, not past-due. We identify that this requirement is incorrect because of the semantics of past-due billing, and the hidden complexity of varying billing terms.
  • Approach: Relax outstanding debt by 5%. Requirement:” The system shall reduce the outstanding balance of all past-due accounts by 5%.” This requirement would reduce accounts payable amounts, but it would not address the opportunity cost of the missing funds. Companies earn interest on credit balances, and pay them on debts. By decreasing the amount owed, a company would not have any impact on the amount that it could have earned (or avoided paying) in interest. This does reduce the size of the accounts payable amount, it does not achieve the goal.
  • Approach: Increase prices for high-risk customers. Requirement: “The system shall adjust product prices per [referenced actuarial table], to reflect the risk of late payment.” This would not reduce the cost of accounts payable, although it might increase the profitability of the product (and might not). Since this doesn’t directly contribute to achieving the goal, the requirement is incorrect.


As the examples highlight, we have to understand how the market requirement works. A knowledge of the billing rules for our customers, as well as an understanding of the cost of capital are both required.


Writing good requirements demands that the requirements be correct. Correctness can only be identified with context and domain understanding. Correctness can be determined by asking if a requirement achieves the goal, and is required to achieve the goal.

First Look at Free Market Product Management


In the old west, when law enforcement wasn’t meting out justice to people’s satisfaction, the people would rally together and form a posse. Or they would contribute money to a bounty, and someone else would go “claim the money.” This just happened recently in the software world.

A Software Bounty

Alex King is maintaining a bounty to have someone write software to tether his Blackberry to his Macintosh (for use as a modem). After reaching $675 in contributions (requested from his blog, paid to his paypal account), the posse found what they wanted – a developer willing to do the job.

Hat tips to Doc Searls and Doug Kaye for popping this up on our radar.

Why Did This Happen?

Why did Alex need to raise a bounty? The Blackberry product manager didn’t create this for Mac users, and Alex and others wanted it.

Is it a product management failure? Probably not. There may be dramatically more demand for this, but a $685 bounty implies that there isn’t a lot of demand for this capability. Demand exists, but for a product that has almost 20% of the PDA market, this is a flea on a fly on the back of the beast. ROI-based prioritization would put “almost everything” ahead of this particular feature.

Small towns build up around military bases. Small manufacturers jump all over each other to create iPod accessories. Solar-powered window-fans to cool cars on sunny days. Much of the web2.0 mashup products. People have always been “filling the gaps” around successful products. As gaps get bigger, product managers decisions become more questionable. Maybe they overlooked the opportunity (or mis-valued it). Maybe it was strategically unaligned with the company’s objectives.

Is This Good?

There is something heart-warming to the individualist / capitalist / free marketeer in this phenomenon. Perfect mating of supply and demand. The customers say “I demand this, and will pay anyone for it!” until someone says “I’ll do it.” If there’s enough demand, it will happen. Many of the dynamics of open source software come into play. The developer of the feature can gain experience and visibility (and a little cash) working on this. The customer gets what he wants, without navigating the beurocracy of a zillion-dollar-industry.

Net-net, this is good, albeit small.

Joe Andrieu makes some great points about how marketing and branding play into this dynamic. That really isn’t the point here, since we’re not supplanting “real products”, just augmenting them.

Can This Scale?

Probably not much, without changing a lot. This happened with a handfull of people, requesting a single capability for an existing product. When it becomes a bunch of capabilities, or a completely new product, $685 just won’t pay for the development.

If thousands or hundreds of thousands of dollars could be raised to develop something, that would be awesome. But once a project is that large, it would need some real product management to make it a success. Prioritization, clarification, organization, and testing would all be needed to assure that the posse got their money’s worth. And who’s going to pay for the product manager when the voice of the customer is actually the customer?

This works in the open-source world, where the financial side of things is non-existent or indirect. Sticking with the profit motive for the moment, we lose much of the altruistic approach of open-source. We would need a profit-motivated product manager to allow this to scale beyond the micro-application level that we see here.
But wouldn’t it be fun if it could scale?

What Would it Take?

How could we compensate a product manager for organizing the posse? Give them a piece of the action? There are sites like Rent A Coder that allow customers to put jobs up for bid. But those sites have a single-customer dynamic. Maybe organizing multiple bounty-driven software requests into a single site would reach a critical mass that could support the overhead of product management.

More thinking required….

Group Think?

What do people in the group think? :)

Does Your Product Have Soul?

raySoul? or Sole?sole

Does your product have soul? Michael Shrivathsan asks this question, and we take it in a slightly different direction.

Design is Soul

Michael uses an interview with Steve Jobs to build a strong argument for the criticality of design. Along the way, he quotes Steve as saying that “design is the fundamental soul of a man-made creation…” It is a great argument for the importance of design. And the Apple imagery Michael invokes drives home the power of design. We agree with that. We just don’t think design is soul.

Intent is Soul

Michael quotes Socrates too, as saying that the soul is “the essence of a person, being that which decides how we behave.” We’re more aligned with Socrates than Steve on this one.

Products are created to achieve goals – to solve problems or exploit opportunities. That is the essence of the product.

The soul of a product is the goal it was designed to achieve.

Lack of Intent

Many products lose sight of their goals over time. They add too many features and they fail to prioritize. They lose sight of their users and thereby lose sight of the market. They try and solve too many problems, taking on too many goals. This scattered “emphasis” dilutes the essence of the product, and weakens its soul.

Soulful Products

  • The Compact Disc / Player. A record that doesn’t wear out. Old folks like me will have at least one record or cassette that they bought more than once because they wore out the first copies. Young folks may be surprised to know that records lost fidelity over time, as the needle scratched away the dynamic range of the surface of the record; and cassette tapes, while magnetic, were analog, and they stretched over time. Especially the first and last tracks on the cassette. There’s an essence to the compact disc. You can listen to your favorite album continuously, indefinitely, without a loss of fidelity. In the 90’s, this was a huge deal.
  • Anti-Lock Breaks. Make a car stop in the shortest possible distance, regardless of road conditions. Another huge deal. Wouldn’t surprise me if anti-lock breaks save as many lives as seat belts. Of course, there’s no way to gather the stats.
  • The microwave oven. Cook stuff as fast as possible. After WW2 radar technicians discovered the physical damage caused by their units (birds would get cooked in flight), Amana researched and invented the Radarange.
  • The cell phone, email, web browser, typewriter, air conditioning, PVRs. All products with a clear essence…

…At least initially.

Today, these products are ubiquitous, and have become “product categories” – their essence was so powerful, they had so much soul that more and more products are created in each category.

Sole or Soul?

We can also see how things have gone awry, as products have diluted their own meaning over time – combining features “because you can”, for example. Some products don’t lose sight of their visions. 37signals does a great job of staying focused on the goal of the product. To “do more things”, they create more products – not more menu items and tabs in an existing product. Gmail is a great email client. Not so good at contact management or calendaring, but also not diluted by those things. Google has a calendar now, and I hope will have a contact management solution soon. But Gmail has soul. Lotus Notes lost their way.

What matters is what your product is supposed to do. Are all the features in support of your goals? Your user’s goals?

Or are the extra features diluting the essence of your product? Dilutive features may be exec “pet projects”, or loud-customer-requests, or cowboy-capabilities (added by someone who thought it would be cool).


Design is important, but the soul of a product is its essence – its goal.

Monty Python and Software Requirements

Arthur and knights

Monty Python and the Holy Grail is one of the funnier movies ever made. It was rereleased a couple years ago with digital remastering, deleted scenese, and lots of extras in a two-disk version. The rest of this post will make you chuckle if you’ve seen the movie.

Bugs Can Come From Anywhere

Software bugs can come from any of several places in the SDLC (software development lifecycle).

SMEs That Aren’t Experts Give Bad Data

“But how do you know she’s a witch?”
Interviewing session

When we interview subject matter experts and business owners, they may give us misleading or incorrect information. They may lack a key insight or understanding, or they may oversimplify or overcomplicate the problem.

Stakeholders Change Their Minds

“Blue. No, Yellow! Aaaarrrrgh”
wants and needs

Kent Beck argues that customers will not know what they want. A SME needs to be able to clearly identify what they need.

Poor Listening Skills Cause Miscommunication

“Right. We’re not to leave, unless Prince Herbert comes with us.”

misunderstood requirements

Even when our customer knows and expresses his requirements, we may not listen correctly. Active listening is a key technique to avoiding this miscommunication.

Ambiguous Documentation Prevents Communication

“If he were dying, he wouldn’t have bothered to write ‘Aaaaaarrrrgh’.”
reading ambiguous requirements

We have to document our requirements unambiguously if we hope for people to interpret them properly. We also have to keep in mind that we are writing for someone else to read the docs eventually – not just taking dictation. Writing for the implementation team can be even harder when outsourcing – we limit our ability to clarify and reach a common understanding.

Back to our regularly scheduled programming…

Another Use For ‘Why?’

Man Asking Why

Why?” The question is our inspiration and our muse. “Why?” is the justification for our requirements. The key to identifying “What?” and “When?”, which lead to “How?” and “How Much?” But there is another use for “Why?” – communication of intent (with stakeholders and implementers). Requirements documents are artifacts, but they are also dynamic documents. By documenting “Why?” a requirement is a requirement, we make it easier for future readers to understand.

Meeting Debriefing

I was observing a meeting earlier this week where a member of my team was reviewing a “finalized” requirements document. The requirements in that document were gathered previously, and validated for both correctness and completeness. This review, another step in the elicitation process, involved stakeholders who were not involved in previous sessions. The meeting was not an efficient one.


Over the course of two hours, the team reviewed and discussed no more than ten requirements. The project is a migration project from a legacy system to a new solution. There are minimal process changes in this phase of the project (and therefore the review is looking minimally at process re-engineering).

The following are some of the questions asked by participants in the review:

  • What is the difference between those two [variations of] start dates?
  • Why do we need that information in the system?
  • Why can’t we simplify X to Y?

The answers to these questions (each was asked multiple times about most of the requirements that were reviewed) generally involved relatively detailed explanations, hypothetical examples, and occasional diagramming of business object relationships to effectively communicate why the existing requirements had been written, and why they had been written in the way they had been written.


At the end of the meeting, one of the project sponsors expressed concern that a “final review” meeting was so ad-hoc and disorganized. Our sponsor now has a fear that requirements are being missed, or documented incorrectly.

Anecdotally, there were no significant changes to those requirements as of the end of the meeting. Why did we have to spend 20 man-hours to make no perceptable changes?

Because we didn’t document the answers to these questions the first time!

Document Creation

The creation of, and initial validation of the requirements document involved interviews, contextual inquiries, and side-by-side comparisons and gap-analysis with existing process documentation. The resulting requirements were documented.

All of the questions that were raised in this meeting had been raised in previous sessions. None of the answers had been included in the documentation. And the overall project is large enough, and complex enough that people inconsistently remembered or completely forgot the justifications for the requirements.

Documenting Why

Including the justifications, scenarios or examples, snippets of business object models, and other supporting information would have prevented much of the debate. If we had included the underlying “Why” data that drove the “What” data (the requirements) in our documentation, we would have avoided rehashing these same issues.

It isn’t enough to ask why during elicitation – we have to document the justifications along with the requirements.

Pragmatic Marketing 2006 Survey


The polls are open! Go to their announcement to take the annual Product Management and Marketing Survey!

Previous Results

Salary Trends

Pragmatic has some good detailed analysis of the data within each year’s survey results. We thought it would be interesting to look at trends over time. Interaction design tells us to focus on personal goals as defining the framework for how someone approaches their job. Surveys aren’t really going to capture those driving goals, or things like utility, job satisfaction, etc. The closest thing we have to a normalizer is looking at product management salary trends over the years of the survey. We also don’t have normalizing data that would show us years of experience, cost of living, or a normalizing stock-option method (like Black – Scholes) to create an “equivalent compensation” analysis across the years.

Within each year’s results, there are some demographic breakdowns by region of the country – but those only help a little. Markets like Silicon Valley, Austin, and Boston will skew the data relative to smaller markets. It would be interesting to see (in future survey results) what the salary data looks like as a scatterplot versus a cost-of-living index for the locale (city, not region) of the respondants.

salary trend data

We saw salary rises immediately following the dot-com bust, followed by some stagnation and deflation in recent years.

If we adjust for inflation we see some less optimistic annual changes in real earnings.

  • 2001: 0.7% Loss in buying power
  • 2002: 3.2% Increase in buying power
  • 2003: 4.0% Increase in buying power
  • 2004: 3.3% Loss in buying power
  • 2005: 4.2% Loss in buying power

Looks even worse. If we show the same graph as above, but in 2000 dollars, we get the following:

inflation chart
This highlights the fairly rapid decay in product manager salaries over the past few years.

Women’s Suffrage

Notice also the unreasonably large gap between blue (female) and maroon (male) overall compensation data.

Next: Go take the 2006 survey.

New Web Advertising Network – Performancing Partners

Performancing Partners network is a well established company that is building their ad network as we speak. They’ve already signed up several hundred bloggers, and advertisers. They have a refreshingly different approach to advertising – the advertisers pick the sites they want to advertise on, and the bloggers / publishers pick the ads they want to run.

The new network is called the Performancing Partners network.

Publisher Goals

As a publisher, Tyner Blain has one main goal

  • 1. Build a community around software product success.

To achieve this, we do a lot of different things – we cover important topics, create original content, start discussions with the experts who are writing great stuff, and help people find great products or services that help them do their job better. We also try and write both for people new to the domain, and help push the envelope to extend the domain.

Joining the new network will help us provide / control the product and services ads that show up on Tyner Blain.

Advertiser Goals

Advertisers have two main goals:

  • 2. Reach the right audience with a targeted message for that audience.
  • 3. Manage the costs of customer acquisition (and by implication, manage the cost of advertising)

Performancing Partners Addresses These Goals

We’ve had reasonably good success with contextual ads – they seem to generally provide links to suppliers of related products and services, but many advertisers are companies we have not heard of. And with hundreds of articles in our archives, we can’t monitor and inspect every supplier.

Goal # 1: As a publisher, Tyner Blain will only show ads that are pre-approved. This gives us quality control, and allows us to make sure that only advertisements that would benefit our readers will be displayed. With a consistent ad placement in the sidebar, our readers can easily say “not interested” by “not looking” – without disrupting the flow of articles. This choice actually reduces revenue for us, but our primary goal is community – advertising just helps cover our costs.

Goal # 2: Advertisers will select specific blogs on which they would like to show their ads. Instead of defining keywords, and hoping that their promotions will be displayed to their target audience (based on article content), the advertiser will select a publisher and request that their ads be displayed. This is perfect control for a site like Tyner Blain – where we have a consistent and loyal audience, in a targeted niche.

An added benefit for advertisers – Tyner Blain will be showing their ad in the sidebar, which means that for the month that it is displayed, it will appear on every page. Advertisers don’t have to predict and compete for “high traffic” pages on the site, or worry about ads being “clicked out” and disappearing as soon as their budget is gone – the ad will appear for the entire month, for the entire site.

Goal #3: Advertisers can control costs with a flat monthly fee – instead of paying per impression or per click. This completely eliminates the incentive for bad people to game the system, increasing advertiser confidence that the generated leads are credible. It also allows for perfect forecasting and complete control of advertising spending. Performancing also has a completely transparent pricing and payment policy – no secrets for anyone.


  • This new network is good for Tyner Blain’s readers, because we will be able to improve the quality of ads that show up on the blog.
  • This new network is good for Tyner Blain’s current advertisers because they can target and manage their advertising spending more effectively.
  • This new network is good for potential new advertisers, who want to get their message out to a select audience – and we have one!

Signing Up

Advertisers that want to join the Performancing Partners network can get more info or sign up easily.

Publishers can join the Performancing Partners network too. Read for more info, or to sign up in a minute or two.[Update: faq]

Disclosure: If you sign up via a link from Tyner Blain, Performancing will pay us a 5% referral fee at no cost to you. If you don’t want to do that, just manually navigate to their site.

Meaningless Marketing Messages


Web Ink Now has a great article and analysis of the gobbledegook that passes for marketing messages. They’ve done an analysis of over 50,000 articles during the first nine months of 2006. Not only have they identified many of the most ridiculous terms, they’ve ranked them (or stack-ranked them, as a former employer would say) based on frequency.

The Goal of a Marketing Message

A nebulous goal that leads to inaction is “find customers” or “sell product.” That may be the high level goal of marketing, but it is no more useful than using the goal “Make more profit” would be in defining a software product.

Shotgun Approach

Using platitudes like cutting edge and user-friendly is like shooting at a distance with a shotgun. Maybe, just maybe, you’ll hit someone – but you’re kidding yourself if you think it was anything but luck. The gobbledegook that David Meerman Scott at Web Ink Now identifies is the worst kind of trite meaningless jargon. Finding customers is about persuasion, and requires us to target individuals with a sniper rifle (prolonging the firearm metaphore).

Sniper Rifle

A marketing message should be a targeted communication, with a specific persona or audience in mind. Learn from David and Seth and the host of other people who know this stuff a lot better than we do!

Enjoyable Read

In addition to the great article, there is some serious data eye candy in the graph of the top twenty trite terms. The top three:

  1. Next generation
  2. Flexible
  3. robust

Go to David’s article to see the rest of them.

Don’t Prevent My Success

balancing act

Finding the right balance when defining requirements can be hard. On one side, we want to avoid an inadequate system – “Don’t prevent my success by excluding features I might need”. On the other side, we want to avoid cost-overruns, delayed schedules, and negative-ROI features. This can be a hard line to walk.

Business Analysis Balancing Act

My brain is in business analyst mode while writing this. While the ideas can be extended to product management too, for this post, we’re only looking at the problem from a single-customer, enterprise software project perspective.


Burned Before

During a meeting with our business owner (BO) today, I had the following exchange:

BO: I assume that the [new] system will let me […]

BA: Never assume that the system will do something you need it to do (while we’re gathering requirements). Since we’re customizing existing software, it may do what you want, but you shouldn’t assume it. Do you need to do [X] with the system?

BO: No.

BA: OK, so you will never have [situation Y] which would require [X]?

BO: You said never, and I can’t say never. We jump through a lot of hoops to keep our business running on [the legacy system] because people said “we’ll never need to do that!” So I can’t say never. I expect that the system will let me do everything I might need to do.

We can learn a lot from this exchange. First, we know that our business owner (stakeholder) appreciates the importance of the requirements gathering process to actually getting the deployment (customized enterprise software) that she needs. Second, we realize that she isn’t focused on the practical elements of deployment – she is focused on not getting a lemon. This is good – her job isn’t to balance wants and needs with feasibility and value – that’s our job.

Our business owner comes right out and identifies that not requiring something has caused pain for 16 years (the life of the legacy system) for her and her department. She’s been burned before, and will do everything she can to avoid being burned in the future. We learn from our mistakes, and now she is applying her learning to discussion of capability [X].

Requirements Economics

We can apply the concept of expected value to determine how to prioritize requirements to support capability [X]. Assuming that [situation Y] is the only one that would require [X], we first identify the likelihood of [Y] happening. In this case, [Y] would require a change in existing business policy, as well as the occurance of something that “isn’t likely” and “hasn’t happened in the 16 years” that our business owner has been at the company. We’ll conservatively assume there is a 5% chance that [Y] will happen over the next few years. If the changes that make [Y] possible were to happen, then it would happen as often as ten times per year.
The value of [X] can either be expressed in terms of the cost of not supporting [Y], or the cost of making [Y] happen without the needed capability of [X]. In the context of other, already identified, requirements, we believe that there is a workaround solution that is already included in the plan for the deployment – leveraging other already defined requirements / capabilities. This workaround, while undesirable (from a usability perspective), would have a relative cost per incidence of a couple hundred dollars (in the context of a multi-million dollar project) in extra labor costs.

Combining the probability and impact with the frequency nets out something on the order of $500 of cost reduction in net present value.

Easy Choices, Hard Messages

Unfortunately, this means that we’ve already spent more on our analysis of [X & Y] than we would ever hope to save. Our economic analysis tells us that we shouldn’t hesitate to exclude this feature.

We have to circle back with our business owner, and help her appreciate why [X] will have an incredibly low priority, and almost definitely won’t (and shouldn’t) happen. And we have to do it in a way that she feels like she isn’t getting burned again.


This is a real-world anecdote. We can learn from it that people often feel passionately about things that really don’t matter when you analyze their value in the grand scheme of things. What is important is to make our decisions based on facts (and their resulting forecasts), not emotions. And then we have to communicate effectively, both to create understanding, and to use this opportunity to strengthen rather than weaken the relationship.