3 Things Every Product Manager Should Know

May 17, 2011
Wikipedia "W" Award

Image via Wikipedia

Someone asked me recently how they could determine if their product manager was doing a good job or not.

I think this is always a tricky question.  There are lots of statistics that you can use — number of new customers, percentage of retained customers, revenue, revenue versus development cost, etc. — but some of these require information that may not exist.  For example, if your company hasn’t shipped your first product yet, you can’t really determine the number of new customers or the amount of revenue.

And sometimes, you simply want a quick and dirty way to reassure yourself that your product manager is doing a good job — that they are the “winner” you hope that they are.

So I suggest that a product manager needs to know the following three things.  If they do, then they are likely doing a good job.  If not, then something needs to change…

1.  What key business problems do your target customers have?

The product manager must know who your target customers are, some of the problems that they have, and which of those business problems the customers consider to be “key” or important.

Customers (and potential customers) will always have numerous problems — but only some of them are worth solving.  Some are simply irritants that your customers have decided to live with.   Others are so overwhelming that your customers don’t have the will (or money) to attempt to solve them.

Thus, “key business problems” have 2 characteristics:

  • Your customers want to solve them, and
  • Your customers believe your product can provide at least a partial solution.

These are the problems that a good product manager will understand thoroughly and can describe clearly whenever asked.

Say you’re talking to an e-commerce prospective customer whose web site is getting too many complaints from consumers trying to purchase products.  As a result, their revenue is declining and their support call center is overwhelmed.

If you were to talk to them, they might describe their situation like this:

  1. Consumer complaints are increasing,
  2. Sales revenue is decreasing
  3. Support call times are increasing (because they have to deal with irate consumers)
  4. Ad revenue is decreasing (due to reduced click-through rates)

But all of these complaints could be symptoms of a single “key business problem” — that the time required to purchase a product through their e-commerce website is taking far too long.

A good product manager will know what the “key business problems” are and will be able to tell the difference between “symptoms” and “problems”.

2.  How is your product approaching these key business problems?

OK, you have your list of key business problems from your target customers.  And you have your product which you hope to sell (or are selling) to these customers.  Before any customer gives you some of their hard-earned money, they will want to understand how your product makes their life better by solving one or more of their key problems.

They don’t want (or need) the gory details right away — they just want to understand the approach that your product is taking and be comfortable with the limitations (or risks) associated with using your product.

Consider our example e-commerce prospective customer…  Their problems could be due to traffic delays with their ad provider, network bandwidth limitations from their ISP, performance issues in their application, the number (and quality) of the images that they display for each product, the performance of their credit card processing partner, etc, etc, etc.

Perhaps your product collects statistics by monitoring each component’s performance.  Or perhaps you add a hardware device to a customer’s network to monitor communication between servers.  Or perhaps you monitor the application’s performance using simulated web browser client sessions.

Any of these approaches could diagnose the problem(s) with this prospective customer’s e-commerce system — but each approach also has potential limitations and/or risks.

A good product manager will understand how your product is intended to solve one or more key problems, be comfortable articulating your solution approach to a wide variety of audiences, and be well-versed in handling objections about the limitations and/or risks of your product’s approach.

3.  How well (or poorly) does your product solve these key business problems?

Once you present your product concept to a potential customer, you will have some feedback on how well (or poorly) they think your product will solve their key business problems.  You will get more information each time you interact with a potential customer and even more information when a customer starts using your product.   Once you have collected information from a dozen or so customers and potential customers — some patterns will begin to emerge.

Did you identify your target customers and their key problems correctly?  Do you actually understand their key problems and why they are important to your target customers?  Does the approach of your product appeal to them?  Do they think that your product can actually help them?  How well does your product actually help them?

If your product manager knows the answers to these questions — and a bunch more just like them — then your product manager can easily tell you how well (or poorly) your product solves the key business problems of your target customers.

Or put differently, a good product manager can tell you whether your product is likely to be successful or not in the marketplace and where your product needs to be improved to attract a larger share of the market.


Evaluating a product manager is not easy because there are a myriad of company cultures, product types, personalities, and business situations in this world and no two situations (or product managers) are identical.

However, a good product manager will always know:

  • What customer problems their product is attempting to solve,
  • How the product intends to solve these problems, and
  • How well (or poorly) the product solves these problems.

In addition, a good product manager knows that customer situations continue to evolve — so they will maintain contact with current and prospective customers, anticipate future needs, and provide timely product solutions — instead of reacting after the fact with something that doesn’t match what their customers need, want, or will buy.


How is Agile like a frog in a pot of water?

April 29, 2011
Frog example

Image via Wikipedia

Remember the old tale about the frog and a pot of water?   In essence, if you put a frog into a pot of very hot water, it will immediately jump out.   However, if you put a frog into a pot of cold water and gradually heat it, the frog will allow itself to be cooked to death.

Not to worry — I have never done either of these and I don’t suggest that you do so either.

However, there are lessons from this tale that I believe apply to the Agile development methodology…

I believe that a “successful product” must provide a valuable resolution to one or more needs from your target market.  Otherwise, nobody will buy it.  So when I talk to other Agile practitioners, I am amazed at how little thought they give to getting accurate and reliable feedback from their market.  Many of them make one (or both) of the following mistakes:

Product Owners Focused Solely on Development

The product owners of some companies spend so much time with Development that they quickly lose touch with their market.  Or even worse, allow the product direction to be set by the 1 or 2 customers that they have time to talk to.   Sure, they could talk to a number of customers via email, Skype, Twitter, etc — but you will only get answers to questions that you ask or reactions to significant positive (or negative) aspects of your products.  You may never know that some function takes twice as many clicks to complete as it should or that users are constantly using other tools to compensate for functional gaps in your product.

To know what your customers really “need”, you have to talk to enough of them so that you understand the difference between what a few customers say they want and what your product needs to provide to satisfy your target market.

Note:  If you’re interested in how to do this, consider this article written by Steve Johnson, Luke Hohmann and Rich Mironov  published by Pragmatic Marketing,

Developers Gone Native

Some companies encourage Developers to engage with customers so that they can get first-hand knowledge of what the customers need.    They carefully select the Developers for this task, because some are simply better suited for this type of interaction than others.

However, there are at least 2 problems with this approach…

  1. The Developers can’t spend a lot of time talking to customers — because they are typically senior people who need to be contributing to the product, and
  2. The Developers usually do not have the skills / experience to identify what each customer really “needs” (as opposed to what they say they want) and to synthesize the requirements for the product’s target market from feedback from only a few customers.

As a result, the Developers often focus on providing the capabilities that the customers they have met say they need — almost as if they were working directly (or “natively”) for those customers — instead of providing capabilities that benefit the majority of the product’s target market.

The Frog and the Water

If done right, Agile allows you to get rapid feedback from your market to keep you on course toward creating a successful product.  But your product can “go off the rails” just as easily with Agile if you don’t understand how to obtain and utilize customer feedback.

Waterfall is like the pot of hot water — it provides dramatic evidence of how well (or poorly) your product matches the needs of the market.

Agile is like the pot of cold water — and each iteration increases the temperature of the water in the pot a bit.   So if you do not have good people who are experienced in obtaining and understanding market feedback — you could, like the frog, sit in your pot until it is too late.

What Should You Do?

I believe that each product development team should consist of people who are highly qualified to do their specific jobs.  I look for teams where well-trained engineers are developing a product that is being tested by experienced QA personnel.  I’m not fond of teams where “everyone does everything” — because not everyone can be an expert at everything.

Likewise, your development team should include someone who understands the “art” of obtaining feedback from current (and potential) customers and synthesizing that into prioritized product requirements.  Whether you call this person a “product owner”, “product manager” or something else is up to you.   But they need to spend time at least 25% of their time with your current (and potential) customers.  Otherwise, they will quickly lose touch with what your target market needs and will have to rely on their own opinions, guesses, and/or hopes.

Creating a software product is very expensive and you can’t afford to make very many mistakes, because in many cases your competition is only “one click away” for a current (or potential) customer.  So avoid the temptation to ask developers to do this job “in their spare time” and get yourself a good product manager who can do this job “full time”.

The 7 Principles of Software Product Management

April 6, 2011
A stool with adjustable height.

Image via Wikipedia

As software product managers, we are constantly analyzing data:  needs from customers, revenue from sales, win/loss reports, development plans and costs, feature specifications, evaluations of competitors, etc.

As we process all of this information, an effective product manager should be guided by 7 key principles, divided into 2 key categories, as follows:

Product Planning

Effective software product planning requires you to balance the following 3 key principles:

  1. Customers — Your customers (or potential customers) represent the needs that your product should be fulfilling and the revenue that your company expects to receive by providing them with a suitable product (or service).
  2. Product (or Service) — This is the mechanism (or method) that your company uses to provide value to your customers.   If your product doesn’t fulfill most of their needs, then they will go elsewhere and buy something else.
  3. Product Team — This is the staff that your company employs (either directly or indirectly) to create and deliver your product (or service).  If your team doesn’t provide a suitable product, your customers will not be satisfied.  And if your team doesn’t know what your customers need, or understand how much your customers appreciate your products, then they will be unlikely (or perhaps, unable) to create a suitable product.

These three principles can be thought of as the 3 legs of a stool, with your company resting on the seat.  As a product manager, you must constantly balance these 3 elements.   If you over-emphasize (or under-emphasize) one of these principles, then your company will fail.   Just like a stool will fall over if one of its legs is overly long or short.

Product Creation

Creating a software product (or service) is an iterative process, whether you are using Waterfall, Agile, or some other development methodology.  In all cases, your product (or service) is provided to your customers in one or more releases.   As a product manager, you must balance 4 additional key principles for each of these releases, as follows:

  1. Content — Each release contains a certain amount of content.  A number of bugs that have been fixed, a number of new features that have been developed, and perhaps one or more changes to the infrastructure of your product.
  2. Resources — Each release is created (and tested) by a specified group of people; usually those who have the knowledge necessary to effectively and efficiently do the work.
  3. Schedule — Each release is delivered (or at least, planned to be delivered) according to a specific schedule, based upon the amount of work that needs to be done and the approximate date when the finished release needs to be completed.
  4. Quality — Each release must achieve a certain level of quality to ensure that it is suitable to used by the desired customers to accomplish its stated purpose.

As a product manager, you must also balance these 4 principles so that each release helps increase the value that your product provides to your customer.

However, in most situations you don’t have nearly as much flexibility.    Each product release must achieve a certain minimal level of quality, and while it is desirable to achieve a much greater quality, it is rare that this happens.   And although it may be tempting to increase the content you can complete within a given timeframe by adding resources — this rarely works — as explained in  The Mythical Man Month.

Thus, you typically have to manage trade-offs between the content that each release includes and the date (or schedule) when it will be available.


Product management is all about balance.   You need to  effectively (and consistently) balance the 4 principles that define the creation of each product release and also balance the 3 principles that govern your product planning.

If you do this well, your customers, company, product, and your team will all benefit — and you will be able to sleep well at night feeling good about yourself — which is always a good thing.

The 2 Most Important Words for a Product Manager

January 27, 2011

I’ve been reading the “42 Rules of Product Management” recently which is an excellent book consisting of articles contributed by a number of well-respected product management professionals.  My only problem with this book is that I can’t remember 42 of anything for very long.   So with this in mind, I propose the 2 most important words for a product manager to live by — “Why” and “No”.


You’re siting with a customer and they describe a feature, perhaps one that seems completely inconsistent with your product plans.  You can dismiss this idea or even dismiss the customer.  But you first need to know Why they thought this idea was important.   Time is precious to customers also, so they are unlikely to waste their time describing something they want unless it is important.  So ask them “Why is this important”? and make sure you listen (and understand) what they are saying.

Or perhaps you’re looking at your visitor count, promotion results, and sales numbers for your storefront during the last quarter.  The results in February are stronger than expected, especially since you didn’t run any special promotions that month.  You need to know “why this happened.”   Perhaps your promotions are not compelling (so it doesn’t matter if you ran any or not), perhaps your email newsletters are being interpreted as SPAM.  Perhaps your products are most interesting to Valentine’s Day shoppers.   You can’t afford to guess — so you need to know “Why”.


As you listen to more and more of your customers (and prospects), one thing will become very clear — you can’t please every one of them every time.  That’s why the “80/20” rule exists in the first place.  So you have three choices when a customer asks for something that you have no intention of providing them:

  1. String them along — promise them that you’ll look at it “soon” or in the “next release”.  But after a couple of promises like this, your credibility with this customer will be gone and they won’t want to talk to you in the future.
  2. Lie to them — Promise them that you’ll include their feature and then fail to do so.  Of course, this also ruins your credibility with this customer and they will not trust you in the future.
  3. Tell them “no” — Tell them the truth; that there is not enough demand for their feature from other customers.  They may object initially, but eventually they will appreciate your honesty, because it gives them options.   They can appeal to your management, provide additional information to justify their request, provide funding for you to do it as a “customization”, coordinate requests for this feature with other  customers, or decide to live without it.

Nobody said it was easy to tell a very important, strategic customer “no” — but you must have the courage to do what is right — for the benefit of your customers, your product, your company, and your team.

An Example:

Here’s what happened to me a while ago with a large automobile company.  This company had been using our enterprise software for quite a while in a test environment and always provided good feedback — lists and lists of highly detailed enhancement requests.  But they never made much progress in deploying our software in production, so it was hard to prioritize their enhancement requests over those from other production customers. One of their enhancement requests was “allow longer passwords”.  It had a high priority, but so did many of their other requests.   And since our product was built around a 8-character password — we didn’t see any point to expending the effort to change this.  In essence, we said “no”.

One day during a visit to their facility, we discussed their very long list of enhancements.  When the discussion reached the “longer password” item, their IT Manager explained that all of their other corporate systems required a password of 10 characters — so they could not even suggest adoption of our software because it didn’t meet their security guidelines.  Once we understood the “why” of their enhancement request, it became a high priority for us and the very next revision of our software allowed passwords of up to 16 characters.   Our customer deployed our software almost immediately and used it successfully in their business for quite a few years.  And in case you were wondering, they were never able to provide a written explanation of why they needed a longer password, because their internal security policies didn’t allow them to disclose this type of information in writing to anyone — for fear of compromising their other systems.

The Bottom Line

Learn to always ask “why” and be prepared to say “no” when it is appropriate.  But also be aware that a “no” can become a “yes” once you learn enough to understand “why”.

Does Agile development work for ALL software products?

November 2, 2010

I think most people involved in developing software have a reasonable understanding of what Agile / Scrum development is all about.  The general idea is to get customer feedback early and often so that you can adjust the finished product to something that is almost guaranteed to be what the customer wants.

The Scrum project management method. Part of t...

Image via Wikipedia

This is clearly a much better idea than the traditional, or waterfall, approach where you spend months figuring out what the customer wants, more months building it, and then hope (or pray) that the customer hasn’t changed their mind or that the market hasn’t moved while you were doing all the work.

And history is full of examples of products developed using the traditional way that didn’t get close to living up to their original market expectations because they were obsolete or out of touch with their market the day they were introduced.

However, when you listen to some Agile zealots talk — you will hear things like “there never was a product that couldn’t be developed using Agile”.   Frankly, this reminds me of “one size fits all” which anyone over the age of 5 knows is simply not true — especially in today’s market where every customer wants it “their way”.

So with your help, I would like to identify products (or situations) where Agile development may not be the best approach.  The goal is to avoid trying to force-fit Agile where it clearly won’t work and to identify how to adapt Agile concepts in other cases so that we can get the best possible product in every situation.

OK — I know this is ambitious and possibly not achievable.  But a journey of many miles begins with a single step.  So let’s get started by talking about some product types where Agile will have problems:

  1. Embedded Software — The software that runs all of the “electronic” modules in your car are a good example, including the ABS system, the throttle control system, and the fuel injection system.  Obviously, you can’t ship an interim version of this software to your customers and ask for their feedback — they wouldn’t know how to test it.   And imagine if the software had a bug, the car accelerated out of control and someone was injured or killed.   How would the manufacturer explain that it was only a “test” version of the software? (Hmmm, this sounds vaguely familiar for some reason…)   Lastly, it takes a long time to ship a product like this to a customer.  So even if you could get customer feedback, it would come so long after the development had been completed as to be nearly useless to the development team.
  2. Enterprise Software that Requires Customization — This is an idea that I described previously, so I will summarize.  Imagine that you provide a customer with software that takes them 6 months (or more) to customize and deploy, how will they ever be able to provide you with timely feedback?
  3. Real Mission Critical Systems — The software that monitors and manages the nuclear reactor in a power plant is a good example.  How could any software provider explain away an interim software release that allowed a catastrophe to occur because a feature wasn’t “finished”?    I mean before they lost everything in the inevitable flood of litigation.

There are only a few examples, but they seem to have a few things in common.  Perhaps Agile / Scrum development only works with products / situations without these characteristics:

  • No Timely Feedback — It is not possible to obtain feedback from the customer / end user sufficiently fast enough for the Development team to review and incorporate it into the product.
  • No Ability to Fail — It is not possible for the product to fail, due to a feature that is incomplete, incorrectly designed, or improperly implemented, without subjecting the customer / end user to unacceptably high risks.
  • Not a Standard Product — It it not possible for customers to effectively use a “standard” version of the product.  Every version must be customized before it can be used (or tested) by a customer which makes it very difficult to detect whether a failure is in the product or a customization.

I’m sure I’ve only scratched the surface, so feel free to add your comments.

And next time, we’ll look at a few ideas for using Agile Development practices for products which have one or more of these characteristics…

Documenting Requirements — the Tools you will need to be successful.

November 2, 2010

I wrote previously about an approach that I have used to manage requirements.  Subsequently, I have been asked to elaborate on the tools and rationale, so here goes…

As previously discussed, “requirements” consist of a wide variety of inputs from numerous internal and external stake holders.   Yet all requirements suffer from 2 problems — (1) It is impossible to address all of your open requirements in a given software release, and (2) things change.

So, that very carefully defined requirement from that key customer that was documented in year 1 may be significantly different from what that same customer needs in year 2 (or year 3).  You obviously don’t want to spend time developing something that doesn’t meet a business need and you also don’t want to lose any of the knowledge about that requirement that you have collected from this customer (and others).  Lastly, if you are going to reconnect with a customer to review the details of a particular business need — you MUST have a good understanding of what they have said before — or they will dismiss you as a waste of their time — which is not helpful on many fronts.

In other words for every requirement, you need some method to gather, track, and maintain its “definition” and the features that you will need to address it over time.  A document management system (such as Alfresco) is an ideal tool for this purpose.

You may ask — “but why not use a source code control system like Subversion or CVS?”   The simple answer is “they are not the right tools”.   Source code control systems are designed to help multiple people work on source code files that often overlap with one another.   Thus, these systems have sophisticated tools for identifying the differences between two versions of the same source code file and allowing them to be merged together.  In my experience, these tools do not work with documents — especially Microsoft Word documents — and can even corrupt the formatting and content in some cases.  In addition, source code control systems typically require each user to maintain a local content repository that must be synchronized on a regular basis to ensure that each user is always looking at the most current copy of a document — which is counter-intuitive, at best, for most non-Engineering personnel.

By contrast, a document management system is designed for editing, sharing, and managing “documents”.  It uses a simple check-in and check-out model that allows users to view any accessible document but requires all updates to be done using an exclusive write approach.  A document management system also provides tools for managing the maturity of each document so that preliminary feature ideas can be shared with some people and more mature feature definitions can be shared with others.   (Have you ever had a situation where a very early version of an idea was sold to a new customer by an overly aggressive sales person?  If so, then you should appreciate the ability to control when requirement and feature information is shared with different audiences.)

In other words, a document management system is the best tool for “managing documents” whereas a source code control system is the best tool for “managing source code”.  (Apologies if this seems redundant.)

You also need a method to plan a software release that will (hopefully) include numerous features that each address one or more requirements.  You need a method to select which features will be included in each release and a way to obtain estimates from Engineering on what it will cost to develop each feature.  You also need the ability to iterate the definition of each release numerous times — adding or subtracting different features — trying to get the “perfect” balance between features, schedule, and Engineering capacity.

You also need to capture all of the assumptions and dependencies that Engineering identified while creating their estimates for 2 very important reasons:  (a) Engineering spent time (and money) creating these estimates and if a particular requirement isn’t addressed now, it may be later.  You don’t want to pay twice for the same thing. (b) If you know how each estimate was derived, you are much more able to verify previous estimates or anticipate problems with current estimates, based upon$ its assumptions and dependencies — even if your Engineering personnel change over time.

You could plan each software release using a spreadsheet — but why would you want to?   Do you really want to continually update the spreadsheet, circulate it to numerous internal people, and then consolidate all of their inputs?   And even if you want to operate this way — do you really have the time?  Or are you assuming that you will get each release planned perfectly the first time?

This is where an issue tracking system (such as Jira) can (help) keep you sane.  You can use a field (such as “Specification”) to include a link to the relevant requirements document within your document management system.  You can use another field (such as “Target Release”) to designate the features that you want Engineering to review and have them include their estimates and assumptions in other fields — based upon the information on the feature and its underlying requirement(s) maintained in your document management system.  So when you generate a report (or Excel export) for a given software release — you will be able to immediately determine whether you have under or over defined the release based upon your Engineering capacity.

You are almost done — all you need now is a “plan” for this release.   If you are using the waterfall method, I suggest creating a project plan with Microsoft Project using the feature, dependencies, and estimate information from your issue tracker.   Update it regularly (I suggest weekly) and provide copies to all team members.  (I suggest using a PDF print driver so that you can easily share the project plan with everyone without requiring them to have access to Microsoft Project.)

If you are using Agile, I suggest using the GreenHopper plug-in for Jira — or something similar — to plan each sprint.

That’s all for now.  I hope this has been helpful.   As always, comments or questions are welcome.

Managing Requirements — One Approach That Works

October 3, 2010

I’ve had some recent conversations with colleagues and clients about “managing requirements”.  I was surprised at some of the approaches that had been tried — largely unsuccessfully.

And while I don’t claim to have THE answer on this subject, this approach has one significant advantage — it has worked in the past.

Some Background

I believe that “requirements” consist of many different things, including:

  • Issues reported by customers that highlight a need for better capabilities
  • Problems discovered by internal resources that highlight product gaps
  • Market opportunities that identify broad functional capabilities that could be targeted
  • Customer / prospect discussions that contribute specific product needs.  Often this includes “gaps”.
  • Enhancement requests that explain (sometimes in great detail) specific functions where the product needs to be improved

Thus, there is a wide range of specific and broad “requirements” provided by all sorts of internal and external people — and many of the requirements need to be grouped together — either because they logically go together or because without enough critical mass, none of the smaller items could justify the effort to address them.

Lastly, requirements change over time — either because your understanding of what is needed evolves or because the need itself changes.   (For example, if  a requirement specified that your software should support a dual-core processor and a quad-core processor was introduced before the requirement was addressed — you would probably want to update the requirement.)

Required Tools

I believe strongly in using tools for the function they were designed for.  So, I don’t use a hammer to “drive in” a screw — that’s what a screw driver is for.

Thus, I believe that you need the following tools to manage your requirements:

  • Issue Tracker — a tool for collecting, prioritizing, scheduling, and tracking all sorts of issues, including many of the requirement types discussed previously.  My favorite is JIRA, but there are many others just as good.
  • Document Management System — a tool for collecting, tracking, sharing, and managing all sorts of documents.   My favorite is Alfresco, but there are many others.

You may wonder — Why a Document Management System?   Because some requirements require more than a few paragraphs to adequately describe and as previously discussed — requirements may change.  If these “larger requirements” are captured in one or more documents and linked to the issue within the Issue Tracker — you can update the requirements whenever it is necessary without having to update the issue within the Issue Tracker.

My Approach

Here’s the “short” or “cookbook” version…

System Setup

1.  Create issue types (in the Issue Tracker) for the types of information you need to track.  This could include:

  • Bugs
  • Enhancements
  • Product Improvements
  • Major Features
  • Use Cases
  • Stories (and Epics)  — If you’re using Agile.

2.  Add fields to each issue type so that you can capture planning information.  For example:

  • Dev Estimate — how long it would take to implement this issue (or requirement)
  • Dev Estimate Assumptions — any assumptions that were used to estimate the level of effort.  (This is critical unless you plan to re-estimate each task just before you do it, because situations and people change — and you won’t be able to remember the details of each estimate unless the person who made the estimate keeps notes.  And if they are going to keep notes, why not put them in the system?)
  • Dev Estimate Confidence — how confident is the Development organization in this estimate?  “High, Medium, and Low” are often enough, but you may wish to use a percentage.
  • Reference Doc — a field where you put the link to the reference document (within your Document Management System).   You can also create a separate issue type of “Reference Document” so that you can link multiple documents in your Document Management System to the issue — if you commonly need to refer to multiple documents.

3.  Add “planning” capabilities to your Issue Tracker

You need a method to plan which issues (or “requirements”) will be developed next.  If you are using JIRA and Agile, you could use the GreenHopper planning plug-in.  Or you could add a “Target Release” field and pre-populate it with the names of your next 3-4 release vehicles.

The specific tool is unimportant — as long as it is easy enough for you to use, so that you can (and will) use it regularly.

Using the System

1.  Create documents for anything that can’t be described in a couple of short paragraphs or when the description might change over time.

Use your Document Management System to circulate the documents to appropriate internal (and external) stakeholders — so that each requirement is described appropriately.  You don’t want to waste Development time on poorly defined requirements — so spend the time to get them right.

2.  Create issues for each requirement and establish links to their respective documents.

3.  Create higher level “Major Feature” issues

Group related smaller enhancements and improvements under each Major Feature.  JIRA makes this easy with Links.   Other systems offer similar capabilities.

4.  Create individual issues for each customer request

Each time a customer requests a given feature or enhancement, you should record it as an enhancement issue.  And link each customer enhancement issue to an appropriate Major Feature issue.  Thus, when you are evaluating which features to do — you will have a record of the number of customers who requested something, who they are, when they requested it, etc. — which is incredibly valuable.  Imagine your credibility when you contact your favorite customer to ask them if they would like to test a new feature that they specifically requested… (Of course, they will be happier if you are providing their feature sooner than later — but that’s a different issue.)

5.  Plan each release

Plan each release based upon the content that you want to include, the amount of customer interest, and the roll-up of the estimated development effort.

And since YOU decide how frequently you want to launch new releases, you can use this approach for Agile sprints (3-4 weeks) or for major multi-year waterfall releases.


In summary, all requirements (or issues) get recorded in the Issue Tracker system.  All documents belong in the document management system (such as Alfresco).  Documents are written using standard tools (Word, Excel, Powerpoint, etc).  The Issue Tracker becomes your planning tool and you use the workflow and revision control tools of your document management system to manage the distribution, review, revising, and approval of all relevant documents.

I won’t pretend that this is a perfect system — but it DOES work.  And since these types of tools are already being used within a given company — it is MUCH easier to share information with others in the company and to capture data that already exists. Otherwise, you have to convince people to use “yet another system” and duplicate data between your bug tracking and requirements management system — which is simply too much work, invites multiple (and different) definitions of each issue, and makes it far too easy for things to fall through the cracks.

Next time I’ll discuss the benefits of using a Document Management System (such as Alfresco), instead of a source code control system (such as Subversion), to manage documents.

Thanks for reading this far and now it’s your turn…   How do you manage requirements?  How well (or poorly) does your system work?   Is there anything about my approach that needs improvement or concerns you?

Let’s hear what you think…


%d bloggers like this: