Monthly Archives: June 2006

Guerilla Product Management

gorilla *(scroll to the bottom and come back)

Guerilla Product Management (pdf) is an article available from Sequent Learning Networks, written by Steven Haines. (Hat tip to brainmates for finding it)

Steven’s pdf includes 17 golden rules for achieving product management success(no, we won’t do 17 articles on each of them). Many of them are relevant in any consultative or sales role. We’ve bolded our favorites, and you’ll have to check out Steven’s article for the details on each point he makes

  1. Know what has to get done and when.
  2. Know how the company works and who is responsible for what.
  3. Make friends.
  4. Get cake or cookies…
  5. Do research – all the time.
  6. Learn to share.
  7. Get a thick skin.
  8. Learn to make fun of yourself.
  9. Show your enthusiasm all day long.
  10. Learn the numbers.
  11. Communicate.
  12. Take a hike.
  13. Keep excellent records.
  14. Strengthen your bond with marketing and R&D.
  15. Do good deeds.
  16. Don’t wait for orders.
  17. Build a community.

Steven Haines


Steven shares several good ideas about how to be a great consultant. And these are key elements of succesfull product management. It can be easy to focus on prioritization and completeness and traceability and schedules. That stuff all falls under the “be competent” part of product management. The people relationships and consulting work is what drives the next level of success.

– –

* Yes, I know – gorilla guerilla – I’ve never stopped laughing at Martin Short’s line from Captain Ron – “There are no gorillas in the Caribbean!” Besides, we’re all getting tired of that ‘big ten’ logo anyway.

Writing Passionate Requirements

big ten logo

One of the ten big rules of writing a good MRD is writing passionate requirements. What in the world is a passionate requirement [they were all wondering]? When you believe in the product, are committed to the work, and aren’t bored, you can write passionately. The goal of a requirement is to create sustained understanding. A dry document can create understanding, but an engaging document will sustain it.

The Big Rule of Writing Passionate Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

Nothing great has been born from complacency, lethargy or mediocrity. When we are defining requirements, we must be passionate about what we’re doing. If we’re just going through the motions, it shows up in the writing. If we aren’t excited about a requirement, the problem is either with us or with the requirement. Either way, it won’t inspire the rest of the team to do something great.

Passion For The Product

When we are excited about our product, and believe in the value for our customers, we will write better. When we know that we are doing work that is worth doing, we approach it with that ‘extra something’.

Commitment to Writing

If we are just going through the motions, creating a document because someone told us that we have to, it will show. We need to appreciate that an MRD is the focal point for an understanding of our customer’s needs. We realize that our engineering team will be using that MRD as the source of their inspiration and actions. When the goal of our writing is to deliver understanding, we write differently than when our goal is to hurry up and move on to the next thing.

Personal Engagement

Few things affect the quality of writing more than boredom with the subject. If we are writing requirements for YACC (Yet another C compiler) and we’ve done it ten times before, we will lose something. Years ago I got some great advice – get out of your comfort zone.

Everyone has a comfort zone, where the work they are doing isn’t challenging. Immediately surrounding that comfort zone is the stretch zone where there is a little fear, growth and challenge. This is where we should operate. We don’t grow by doing the same thing over and over, in the same way. Outside of the stretch zone is the fear zone where we are operating as a fish out of water. If we’re unable to react, learn, cope and succeed, we’ve gone too far into the fear zone.

Complacency comes from boredom, which comes from spending too much time in our comfort zones. And complacency shows in the quality of our writing. We may write accurate, boring, easy to read and easy to forget requirements.

Out of Control

All of the factors above seem to be out of our control. We have employers, they give us assignments. We have to do what we’re told, even if we don’t believe in it. There are three things we can do.

The first is to find a way to believe in the product. Review the financial benefits, think about the improvements it makes for the users. We can find at least an element of what we’re doing that is relevant or significant. And we can focus on that.

The second is to find a way to focus on self-improvement. While we’re performing the job that we’ve decided isn’t worth doing, we can take on the meta-challenge of exploring it as a testbed for discovering better ways to do the job. How can we reduce the level of effort required to do the job well? Can we invent new approaches or master existing ones? We can focus on that.

The third is to think about why we have a job we don’t enjoy, doing work we don’t believe in. If we need the job, then we keep it. If we don’t need this job, we can look for another one that we will believe in. Or we can simply accept that our writing won’t be passionate. But hey, that’s no different than most of the stuff that we read.


Every job is done better when someone is passionate about it – writing requirements is no exception. Find a way to be passionate.

Writing Atomic Requirements

big ten logo

One of the ten big rules of writing a good MRD is writing atomic requirements. Just as verifiable requirements must be concretely measurable as having been met or not, so must atomic requirements. If a requirement has multiple elements that can be implemented separately, it is not atomic.

The Big Rule of Writing Atomic Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

Every requirement should be a single requirement. If we can say “Half of this requirement is implemented” then this needs to be two or more requirements. If a requirement read “Sales reps can manage their client list and generate custom reports” it expresses two atomic ideas (list management and report generation). Those ideas need to be separated

Determining Atomicity

There is a very simple test – can a subset of the requirement be implemented? Phrases like ‘the user will be able to X and Y‘ are tell-tale signs that a requirement is probably not atomic.

Why Atomicity Matters

Atomicity matters when developing a product roadmap. We can’t prioritize half a requirement for one release and the other half for another. Each requirement should be scheduled for a single release.

Testing of requirements should result in either a “pass” or a “fail.” A requirement should not partially pass its verification test.

Tracability of requirements is also simplified when each requirement is unique.

Writing Verifiable Requirements

big ten logo

One of the ten big rules of writing a good MRD is writing verifiable requirements. Verification is both a function of having a precise goal, and having the ability to affordably measure the requirement. A precise goal is a verifiable requirement if we can clearly answer “yes” or “no” when asked if the requirement has been implemented. We also face the practical realities of being able to measure the results profitably.

The Big Rule of Writing Verifiable Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

We use a process that starts with market requirements, and then decomposes them into software requirement specifications. the market requirements must be written in a way that we can verify that the associated requirements specification will meet the market need.


We wrote previously that if a requirement can’t be tested, it should be rewritten. Roger Cauvin has recently reposted on testable requirements. Perhaps in anticipation of this article? :).

In the world of test driven design (TDD), the philosophy is to write the test first, and then write the code. We use a continuous integration approach to check in code regularly and run all of the tests as we go. When the test for a particular requirement passes, the code is done for that requirement.

We also get a big benefit in validating that we have delivered the right functionality to the customer. When we agree on the language of the requirement, we are also agreeing on the language of its verifiability.

Affordably Verifiable

With this big rule, we are assuming that we have already eliminated impractical or unattainable requirements.

Some tests are very expensive, or nigh on impossible. Roger alludes to this as testable in principle. Requirements should be testable in practice whenever possible. If a requirement can not be tested (“Must last 10 years”) in the delivery timeframe, we need to at least define a specific acceptance criteria – (“95% confidence in a cycle life of 10,000 cycles per procedure XYZ.doc”). This is the approach that Underwriter Labs uses for awarding UL certification to electrical appliances for safety.

Semantically, we can argue that this proxy criteria is in fact the requirement. It is the criteria by which acceptance is determined.

If the test is possible, but impossibly expensive, we shouldn’t run the test. If we can not agree on a practical proxy criteria, we are left with two choices. We can choose to not implement the requirement. Or we can choose to agree that the requirement is delivered when we say it is. Neither is a particularly good option, but the former is better than the latter, when it comes to maintaining a positive relationship with our customer.

Writing requirements without acceptance criteria introduces risk into our project. The last thing we want is to enter into a nitpicking discussion about what we have and have not delivered. We would much rather spend that time discussing what we can deliver next.


Write requirements that can be verified given the constraints of the project. Common constraints are time, money, equipment and expertise. Use language that makes the verification process explicit. The process of determining verifiability also dramatically helps eliminate ambiguity in our requirements.

Writing Unambiguous Requirements

big ten logo

One of the ten big rules of writing a good MRD is writing unambiguous requirements. Ambiguity is a function of communication. The writing can be generically ambiguous, or ambiguous to the writer. A requirement could be precise in intent, but ambiguous in interpretation by the reader. Understanding our audience is as important as precision in language. We write unambiguous requirements because misinterpretation of requirements is the source of 40% of all bugs in delivered software.

The Big Rule of Writing Unambiguous Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

A great requirement has a single interpretation. A good requirement has a single reasonable interpretation. As part of our development process, we will use listening skills like active listening to make sure that our engineering team understands the requirement we intended to write. The better the requirements, the less expensive and risky this communication process will be. Writing unambiguously is critically important when using outsourcing models that limit our interactions with other team members.

Ambiguous to the Writer

We introduce ambiguity with imprecise language. Using shall instead of should is one of the first things people suggest (or require!) when writing requirements. [Added 2010.08.17 – shall is ambiguous too – use must!]  Red flags are also raised with words like can and might. Marcus wrote a good post about vague requirements language

What do the terms: user-friendly, flexible, easy-to-use, fast, and intuitive mean to you? Do you think these terms mean the same thing to someone else? Generally, no!

from Speculative and Vague Terms

These are examples where the language is ambiguous, both to the writer and the reader. Any uninformed third party could read these requirements and identify the amiguity in the language. This makes these mistakes easy to catch – all that is required is a good working knowledge of the language.

Ambiguous to the Reader

Even precisely written, grammatically correct prose can be ambiguous to the reader. This ambiguity can come either from lack of expertice with the language, or from incompleteness of the requirement.

Language Ambiguity

With the ever-increasing outsourcing of teams, we have to think about writing requirements for outsourced team members. When we use a complete technical outsourcing model, we have to consider the possibility (or certainty in some cases) that the primary language of the readers of the MRD is not the language it is written in. Making a document easy to read (short sentences, common words) can be at odds with making the language of the requirements precise.

Some good research on vocabulary size data for comprehension of english can be found here. The average native english speaker knows 20,000 word families. With a vocabulary of 5,000 english words, only 98.5% of the words in a given text will be understood. 5,000 words is a lot for a speaker of a second language (3,000 words is considered a working knowledge).

An analysis of the reading-level at which a document is written can be helpfull in identifying if the language is likely to be challenging for readers with limited vocabularies. The Gunning-Fog Index provides a measure of the education level at which a text is written.

Incompleteness Ambiguity

When the language is both precise and understood, we still face challenges in ambiguity by failing to provide all the information. When we find ourselves wanting to say “That was implied, you should have known that!”, we are still being ambiguous. Clarity exists not only in language but in intent. Should the reader assume that when we specified user-authentication and role-based functionality that we intended users to have roles? If we specify that the best-matching search results must be presented within 1 second, is it ok if the rest of the results are presented later? And how many of the best-matches must be found?

Writing requirements like this is definitely a risk, and probably ambiguous. If we have a history, a rapport, and synchronous feedback cycles with the readers of the document, this may not be vague. We may be able to rely on them to assume the same things we assume. The language in the document may be serving effectively as shorthand for this communication. If we are working as a team with a shorter history of working together, this almost certainly will not communicate what we intended. There is also a risk of going too far.


Writing unambiguous requirements requires us to write complete requirements. It also requires us to use precise language that communicates information across domains to our readers. To determine the right level of effort, we need to monitor the effectiveness of our communication, and balance that with the amount of time we can afford to dedicate to word-smithing instead of other product management activities.

Writing Consistent Requirements

Big Ten Logo

One of the ten big rules of writing a good MRD is writing consistent requirements. Consistency within an MRD has two dimensions that are important to requirements – logical consistency and grammatical consistency. There is also the element of writing an MRD that is consistent with other documentation – external consistency.

The Big Rule of Writing Consistent Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

Pragmatic highlights that the requirement must be logically consistent with the other requirements in the document – no overlaps, no contradictions, no duplications. This is certainly the most important point of consistency.

There is also benefit to consistent writing in an MRD. We can use templates to provide a consistent framework, but more importantly the prose needs to be consistent. This consistency makes it easier on the readers.

Logical Consistency

Logical consistency within an MRD requires us to pay attention to what we’re writing. Applying the big rule of atomicity (one market requirement per written requirement) simplifies this quite a bit. The biggest source of duplication comes from writing requirements that involve involve two related ideas. The duplication is obvious when we find it, but with very large systems (and documents) it can be easy to overlook.

Avoiding contradictions can be harder. We might write mutually exclusive requirements, or requirements that are independently attainable, but that neither can be realistically attained if they are both implemented. For example, we could write a requirement that specifies near instantaneous search results, and we could write a requirement to include insanely large amounts of data (like the call logs for all customers of a telecom provider for all time). While this is possible, it might not be attainable for our team, who could easily implement a relatively innefficient search algorithm, or who could set up a very large data store.

Grammatical Consistency

Use of templates can provide a way to make individual requirements consumable. They also help with the learning curve of people who regularly read the MRD – they set expectations, and when followed, make scanning of the documents more efficient. The problem with templates is that not every requirement fits the same mold, and it can be cumbersome to squeeze the requirements into a stock format.

External Consistency

An MRD is one document in the flow of requirements from market needs to product. Often, an MRD is used to drive the creation of a PRD, and it captures a vision for the product and explanation of the relevant market research and how it applies to creating our product. Occasionally, only one of the MRD / PRD documents is created. Either a Software requirements specification (SRS) is created directly from the MRD, or the PRD is created in conjunction with other strategic documents (vision, roadmap, market research). Different companies use different approaches, and there isn’t a generic best answer.

Regardless of the mix of documents we use, the documents exist to support each other. Each document is a targeted expansion of the higher-level document. We need to make sure we write each document at the same level of detail, and each supporting requirement at a level of detail “one step” beyond the requirement it supports.

This approach allows readers to know where to find the big picture view, and where to find the devil in the details.
We have to make sure we don’t contradict ourselves logically. We need to manage the level of detail that we use consistently within and across documents. And templates can help us with using a consistent structure within a document.

Writing Complete Requirements

big ten logo

One of the ten big rules of writing a good MRD is writing complete requirements. We identify problems and opportunities in the market. We determine that one of these problems is valuable enough and practical to implement. Then we have to write the requirements, and make sure that the requirements will completely solve the targeted problem.

The Big Rule of Writing Complete Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

Simply put, if the requirement is implented as written, the market need is completely addressed. No additional requirements are required. When writing a specification, we may use decomposition to break individual requirements into more manageable, less abstract criteria.

No Silver Bullet

bullet going through playing card

Unfortunately, there is no silver bullet that we can apply to make sure that a requirement is complete. The best we can do is explicitly check it for completeness. And there’s no gaurantee that we will be right – our analysis is only as good as we are.

Pragmatic Marketing has a coffee mug that helps us with this.

pragmatic coffee mug

Their message is simple – use data to support everything from valuation to prioritization to completeness verification. Don’t use opinion.

Imagine the following market problem for a mom-and-pop exterminator:

We aren’t making enough money from quarterly treatments. Our technicians are completely booked, but they spend at least three hours a day driving from job to job – double the industry average. Our prices are competitive, and our costs are in-line with the industry. We need our technicians to perform more treatments per day. Spot checks of a few previous schedules revealed that travel time could be reduced by 70% if we reorganized the treatments to minimize travel time.

We could write a product requirement as follows:

We need software that determines the better routes for our technicians each day. The optimal route is the one that requires the minimum travel time between each location, and between the office and the first location. Our software must generate routes that are 50% better than our existing process. Our dispatcher will be able to use these routes to plan each technicians schedule for the day. Note: The dispatcher will communicate the daily schedule to each technician at the beginning of each shift.


We have data. Prices and costs are reasonable, but profit is unacceptable. Technician efficiency is the identified culprit. We’ve written a software requirement that should provide us with an improvement. We’ve assessed the potential value (50% reduction in travel time) and validated that it is feasible (70% reduction for manual spot-checks). We’ve even established critera for testability of the requirement (50% improvement over existing process – we can use historical data to validate the software solution).


Well, it looks complete.

In our example, however, we didn’t do enough research. If we implemented software that provided more efficient routes, we would not get more efficient route execution – here’s why:
Additional research reveals that 80% of the time, the technicians have to return to the office to pick up more treatment chemicals because they didn’t bring enough with them for the whole schedule, or they have to cancel the last job of the day to account for drive time to return left-over chemicals to the office. The technicians can not take the pesticides home with them, and try to avoid a return trip to the office at the end of the day. If they use up all of the chemicals, they can drive directly home from the last appointment.

We need to add a requirement that our software also include planning of the amount of chemicals to take on each day.


Completeness comes from analysis. And our degree of completeness comes from the quality of our analysis. There is no silver bullet, we just have to think. Remembering to validate completeness, and base our decisions on data gets us half-way there, but we have to get ourselves the rest of the way there.

Writing Attainable Requirements

Big 10 logo

One of the ten big rules of writing a good MRD is writing attainable, or realistic requirements. These are requirements that can be practically implemented, by our team, according to our schedule. Practicality is a function of the skills of our team members, the costs that we face to implement a particular requirement, and the circumstances in which we are developing. Agile proponents use the phrases ‘people trump process’ and ‘politics trumps people.’

To write attainable requirements, we have to think about our people and our political situation.

The Big Rule of Writing Attainable Requirements

From our previous article, Writing Good Requirements – Big Ten Rules:

The requirement must be realistically achievable. Barbara and Steve make great points about understanding the cost of implementing something as expressed in the requirements. As we pointed out in our thoughts about good requirements management, there is an optimal tradeoff between costs and benefits for any given company or project. We can formally approach this using the techniques identified for more is better requirements using a Kano framework. In short, the investment must have an ROI that exceeds the opportunity costs by the hurdle rate.

Looking at cost-benefit tradeoffs also supports the argument that valuable should replace necessary.


What is the political climate in our organization? Are we trying to reduce costs for existing products and processes? Are our executives willing to invest in top-line growth through innovation?

Jeffrey Phillips writes on the results of an IBM Global Services Survey, following up on an analysis by Brian Edwards. Jeffrey points out that most of the CEOs think about innovation in terms of cost reductions, not top-line growth or disruptive change:

However, almost uniformly the CEOs indicated that cost reduction was the number one benefit they expected to receive from innovation.

Top line growth was third or lower on CEO lists.

In this type of environment, requirements that represent disruptive change can be impractical. We have to be able to sell the idea, and get at least VP or C-level sponsorship for an idea that contrasts with the beliefs of the head honcho.


Who are the developers on our team? Are they free electrons? Rands provides this definition:

The Free Electron is the single most productive engineer that you’re ever going to meet. I have not even provided a definition and I’m guessing a person has already popped into your mind that fits the bill.

A Free Electron can do anything when it comes to code. They can write a complete application from scratch, learn a language in a weekend, and, most importantly, they can dive into a tremendous pile of spaghetti code, make sense of it, and actually getting it working. You can build an entire businesses around a Free Electron. They’re that good.

Usually, we work with mortal humans (or at least homo-logicus, as Alan Cooper would call say). We have to explore the cost side of any requirement with our development team. They provide the feedback that allows us to understand what we can do for little, some, and a lot of money/time/effort. We have to balance that input with the benefit side of the equation. It isn’t enough for the requirement to be valuable, it also has to be cost effective.


Practicality is just a general way of thinking about attainability. Can 50,000 concurrent users access a website with subsecond response time? Sure. That’s a practical requirement, generally speaking. But is it practical for our team? Do we have the expertise, or the available funds and executive sponsorship to go get the expertise we need?


Determining if a requirement can be realistically achieved isn’t that hard. What we have to keep in mind is if we can realistically achieve it with our current team.

Even when the requirement is technically attainable, it may still be politically impractical.

Intro to Requirements Gathering – St. Edward’s University

St Edward's logo

Welcome Dr. Franke’s students in Analysis, Modeling and Design MCIS6310! Thanks again for inviting me to present to your class on requirements gathering and requirements management.

The presentation is available for download. You can get both the slides and the notes pages. The notes pages include additional content and links to articles for further reading on the individual topics.

For the rest of our readers – the presentation for the St. Edward’s class is primarily written for people with little exposure to formal requirements management processes. It does not go into the depth of most of our articles, and instead hopes to present a broad overview of what we do when managing and developing requirements.  The presentation is 34 pages (about 90 minutes speaking time)
If you’ve been reading Tyner Blain for the last few months, there is little new material. If you’re new to Tyner Blain, the presentation is worth a quick read. Although we didn’t record the presentation, the notes-pages will provide some additional context to the slides.

Prioritizing Software Requirements With Kano Analysis – Article Published cover

Pragmatic Marketing, through their print magazine, has published an article on Kano Analysis in vol 4, issue 3 (May/June 2006). The article was written by Scott Sehlhorst and represents a merging of two of the posts (1, 2) at Tyner Blain that focus on Kano Analysis. Special thanks to Krystin Benmoussa for doing a great job of editing the article! magazine includes some fantastic articles of particular interest to product managers and product marketing managers. There are over 50,000 subscribers to the printed form of the magazine, and back-issues are also available online. We’re honored to be included in this issue. Thanks to Steve Johnson at Pragmatic for suggesting it initially, and thanks to the awesome graphic designers that did the layout and graphics – they make the piece look fantastic in the print version.

Link to the online archive of the article: Prioritizing Software Requirements With Kano Analysis