Abstraction

Knowing what works isn’t the most important thing. The most important thing is knowing what ought to work, but doesn’t.-paraphrased from Arnold Kling

One of the best books I’ve read in recent years is Nassim Taleb’s Fooled by Randomness. It’s one of those rare books that can forever impact the way you think about the world. In a nutshell, it talks about the fundamental role that random events play in every aspect of our lives, and how people are blind to that randomness. In particular, how successful people are blind to the role that randomness plays in their success.

It turns out that successful people attribute their success to their own choices and abilities to a much greater degree than is warranted. Further, other (less successful) people assume that successful people got that way because they are smarter, more experienced, somehow better, than they.

I was thinking about this in context of my assertion that a product manager is judged based on the success of the product being managed. Perhaps this isn’t true; there are simply too many variables to account for a product’s success. A product manager’s ability should be judged based on the efforts made to improve the likelihood of success, but this is something that’s much more difficult to measure. Besides, I’ve presided over some failures myself; surely these were random events that occurred despite my world class abilities and heroic efforts.

A corollary to this line of thought is that all the “best practices” and checklists associated with a particular activity (including the ones I write) are, at best, activities meant to reduce risk of failure. More to the point, they are activities that have reduced such risk in the past, and so it seems like a good idea to keep doing them.

Or have they? As Arnold Kling points out in this interesting TCS article “best practices” typically are regurgitated, repetitious, and have questionable value.

Articulating what works [...] can have surprisingly little value. Taken out of context, what works will seem obvious. What readers need to know is the larger context, especially what ought to work, but doesn’t.

 “Making the simple complicated is commonplace; making the complicated simple, awesomely simple, that’s creativity.”
- Charles Mingus

I was thinking today of the ideal product management team structure, building on my assertion that the product management primary role is to define successful products. I tend to agree with the “Triad” structure promoted by the Pragmatic Marketing folks, in that this structure provides for a manager of each of three important elements of successful product definition: a person to guide overall strategy (in my mind this is the leader of the team), a product manager to define requirements, and a product marketer to tell the world about the product.

So far so good, but I think there’s an important role missing within the triad; namely, a person responsible for ensuring the usability and overall look and feel of the product — a product designer. This person is responsible for defining the experience of using the product, for building prototypes, for conducting usability tests, and for acting as a counterweight to the person defining the requirements. This last is particularly important as it sets up a healthy discussion within the product team, testing whether important requirements are missing (”if we don’t have a breadcrumb, the user gets hopelessly lost”), or whether existing requirements are really high priority from a user perspective (”23 options for report generation will only confuse the user, since only three types ever get used”) .

Among the most consistent experiences I’ve had over the course of my career is an organization’s consideration of user experience as a second, third, or last priority. The “hard part” is seen as the development of the features themselves, with user design seen as a trivial exercise to be addressed sometime later. Incredibly, I’ve seen a company ignore user design even after its enterprise customers refused to purchase a product because it was too hard to use.

I’ve got a theory that this attitude is a symptom of “technical bias” prevalent in high tech, which posits that writing code is hard and important, while everything else — interface design, for example, or documentation — is easier and less important. People that write code are smart, and everyone else is less so. Engineering offers real ROI, and other functions don’t contribute equal value for the money.

It’s certainly true that writing code (at least writing it well) is hard, that it takes a certain cognitive acumen to do it, and that an organization will fail without it. But it’s also true that a development team’s effort is worth nothing if people don’t buy it. Seriously, have you seen people try use a product with an interface designed by engineers? “Wow, check out them elegantly coded algorithms” just isn’t typical feedback.

Yesterday’s rather lengthy post on requirements writing is driven by some basic principles that I think are important. These were implied in the entry, but I thought it would be helpful to make them explicit.

• First, I believe that the requirements definition process should be collaborative, open to everyone, and written by beginning at a high level overview and moving to the nuts and bolts details through a series of iterations. Dare I say this is a kind of Agile style of product definition?
• A product steering committee should exist (sometimes called a product council). In yesterday’s post I was referring to the product steering committee for the first, high level, review of the product requirements. The PSC is made up of senior stakeholders in the organization and is responsible for the overall strategic direction of the product (it’s also a key component of my philosophy of collaboration).
• Requirements should be defined using many different techniques working together. Detailed prototypes (working is better than paper), essay-style descriptions, use cases, and traditional “the product shall…” requirements should all be used. Depending on the product, one technique will probably be emphasized over the others.
• Requirements should be maintained in an online format available for anyone to see. There are lots of ways to do this (commercial software, wikis, trackers, blogs, etc.). I have my favorite (alluded to ad nauseam elsewhere).
• Requirement definition has a finite time line. You can’t succeed by arguing endlessly about a requirement, and it is very easy to fall into this trap (By the way, did you ever notice that the first 10% of requirements in a review get 90% of the time, with the remaining requirements getting rushed through as people get tired? Put really important requirements toward the end if you want to improve the odds of avoiding an argument about them) . They must be a well understood deadline, after which requirements are “frozen.” “Frozen” means that any changes to the requirement must be conducted through a change control process.
• Finally, and this isn’t mentioned or implied in my previous post, but it’s important: the test cases built for QA must map to the requirements. Product management is responsible for making sure that this happens (because, believe me, no one else will bother). If a feature, failure scenario, or edge case behavior isn’t part of the test case, there is high risk that it won’t be in the product, either.

A product manager’s raison d’etre is to define requirements that the design and development teams can subsequently implement as a successful product. Superficially this seems simple enough, but it implies a great deal. The first, and most obvious, implication is that the product definition must meet certain business goals: the product must align with the company’s overall business strategy, it must fit within the company’s resource capabilities and time lines, and it must ultimately generate revenue.

For the sake of this discussion, however, imagine that you already have solved these problems. You have, whether by flash of inspiration or painful research, conceptualized exactly the product that meets all your business and customer needs. The problem now is how to effectively communicate this product so that engineers can build it.

There is a catch-22 to writing product requirements documents. On the one hand, the document must be detailed enough to define all the features and functionality you are looking for, all inherent (but non-user facing) capabilities of the product (availability, scalability, redundancy, etc.), corner cases, failure scenarios, installation procedures, etc.

On the other hand, people need to read and understand what you are asking them to build. And the more detailed a document you write, the less likely it is anyone will bother to carefully read it. This results in painful meetings in which the document is projected onto a wall to be read and discussed in real time, lots of misunderstandings, increased functional bugs, and lots of wasted time.

For example, the first product requirements documents I wrote was a carefully researched document with more than 200 pages of entries that looked like this (taken verbatim from my effort):

ID: 379
Priority: 1
Requirement: The EMS shall support ITU X.733 based fault processing
Additional Details: The ITU X.733 specification (see appendix D) defines the core approach to fault management and specifies the classes and probable causes of faults.

Not only is this just one of many, many requirements, but understanding the requirement forces the reader to research the ITU X.733 specification. I worked long and hard on this requirements document, and I naturally assumed that everyone else in the organization will have worked just as long and hard to read it. Entering that first PRD review meeting I expected some short discussion about the requirements, with frequent exclamations about how good a job I had done. In fact, no one had even read the document, and the meeting became a good lesson in product management.

Thus the catch-22: requirements need to be specified in detail to enable the product to be developed correctly, but a detailed requirements document isn’t effective communication — it doesn’t foster shared understanding.

So how to solve this catch-22? All stakeholders must understand and accept the product to be developed, but the painful details are important — the ITU X.733 specification really did matter to my product!

The first order of business is to make it easy for people to find and read the requirements, which is why I advocate writing them in an on-line tool (I’ve discussed the tool I use in in a previous post).

Then, I try to follow the following steps (acknowledging that it’s a little more messy in practice). In a nutshell, I use a iterative series of increasingly detailed requirements and meet with stakeholders at each step:

1. I organize the product requirements into high level themes and build a short document (actually a page in my online requirements tracker) that lists these themes and provides a paragraph of verbiage explaining each one. The themes usually include high level sketches of use case (just defining a user and the user’s goal related to the feature)
2. I email the link to this page to the product team and organize a meeting with team leaders to review the page and discuss the themes.
3. I iterate the requirements by expanding on the user/goal lists with use cases for each theme. If the product is web-based, I’ll build prototypes of the functionality to complement the use cases. Again,all this work is available on line.
4. I email the link(s) of my updated requirements to the stakeholders, and schedule meetings to review the use cases. Depending on the number and complexity of the themes, I might schedule a different meeting for each theme. During these meetings we:
   • Discuss the use cases and identify corner cases
   • Brainstorm failure scenarios that need to be defined
   • Identify areas that need specific definition (for example, if a use case involves the generation of a report, a requirement must be written that defines the content and structure of the report).
5. I iterate the requirements by filling out the details per the discussion, defining the failure cases, corner cases, and additional requirements
6. I call a final meetings to review and “freeze” the requirements, which places them in change control.

I know, that’s a lot of meetings. The thing is, this method almost always results in fewer and more productive meetings than would otherwise be the case. Too, they are necessary to ensure everyone reads and understands the requirements.

Following this process has many benefits, the most important of which is that it maintains a common understanding of how the product is evolving across the product team. All stakeholders (including executives and field personnel) have at least a high level understanding of the product direction. Engineers have an early view into the product and can start preparing and designing. Perhaps most important, little time is wasted while everyone waits for the perfectly detailed comprehensive requirements document.

Everybody hates meetings. Meetings are the bane of all office workers, denigrated as a staggering waste of time. So, duly acknowledged. But some meetings are an important, and often neglected, aspect of good management: the weekly team meeting, and (especially) the weekly one-on-one with each direct report.

In my mind, the weekly team meeting is not an individual status meeting in which the boss begins by saying a few words followed by each participant speaking in turn about their specific area. In such meetings there are two types of people: those that have not yet spoken (they are ignoring the speaker and noting what they will say when it’s their turn), and the people that have already spoken (also ignoring the speaker, they are in a state akin to catatonia waiting for the meeting to end.) Instead, the team meeting should focus on working together toward a set of common goals (or even a single goal), with the objective toward sharing progress toward the goal, obstacles, challenges, suggestions, etc. That the team is physically participating in the same meeting should not be incidental.

Individual goals and accomplishments should be discussed in a regular one-on-one. In my experience, it’s very rare that a manager will schedule these meetings. Some feel that such a meeting is a waste of time, that the close day-to-day interaction of working together is sufficient. I disagree.

One-on-one meetings enable a focus on issues that are relevant to the individual, such as progress against action items, without unnecessarily using other people’s time. They create a natural forum for coaching and mentoring, and foster an environment in which negative feedback is much easier to provide (and much easier to hear). One-on-ones should hold to an agenda so the person knows exactly what to expect. I usually start positively with general comments about how the persons activities are contributing, and bring up any negative or controversial feedback that I might want to give (and allocate time to discuss it). I then discuss the person’s specific action items and deliverables (this isn’t an opportunity to micro-manage; the emphasis is on uncovering problems that I can help solve), then invite conversation about the person’s general professional goals. I finish the meeting by invite the person to bring up any items they wish to discuss and always end with a positive remark and a “thank you.”

Particularly with many direct reports, it’s true that regular one-on-ones take a lot of time. This is the number one reason they are so often neglected — who can stomach yet more meetings?! Combined with team meetings, however, I believe the reward is significant — a greater awareness of the day-to-day activities of everyone on your team, better responsiveness to their issues, improved team “chemistry,” and greater efficiency.

At the beginning of my career, I visualized product management as a set of serial tasks. I was to conduct market research, write requirements, submit the requirements to engineering, build collateral, define pricing, train, promote, then start all over with the occasional pause for a huge promotion and fat raise.

These activities, designed to lead to product success and eventual early retirement, did not at all correlate to my actual experience. Product managers live a very non-serial life. Every activity is urgently needed at once, and there’s never enough time to do any particular activity as well as I would like. This was irritating.

If I had a better grip on best practices, I thought, or had a deeper understanding of technology, things would get less messy. I was partly right. I did need a better understanding of best practices, and my efforts to understand various technologies have paid dividends (if not royalties, as in the case of a book I wrote about the mobile internet). Sadly, the messiness continued.

In the fullness of time, however, I came to accept two fundamental truths: First, making software is hard, and you just can’t fit the process into a neat series of boxes — activities will bleed together. Second (really a corollary to the first), trying to achieve perfection in any one stage of a process will cause neglect of other stages, and is thus an enemy of success.

This means that a good strategy lies in ensuring product management activities complement one another instead of competing for time and bandwidth, and that each activity gets enough attention to achieve success.

The best single way to do achieve these goals is to have an open information policy. I ask my team to post everything (work related) they do in a wiki created for just for the product team, and I encourage everyone in the company to do the same. Product requirements are written using an online tool that everyone can access; the entire requirements-writing process is available for all to see (and comment on) in its painful glory.

In this way, my team has the benefit of everyone’s thoughts and input throughout the entire process. The engineering team is better prepared for product requirements, and can get a jump start on design and feedback. The sales team can see product direction and can provide suggestions related to their geography or to a customer. Since everything is online and updated in real time, material is immediately available to anyone who deems it “good enough” for their purpose.

Some folks think that an engineering background is a requirement for product management. I agree that technical acumen is important. But a specific degree? Experience as a developer? Nah.

Given two equally smart people, it isn’t true that the one with the MS is automatically the better product manager than the one with the MA. For one thing, and this doesn’t color my opinion at all, I don’t have an engineering background. I have a masters in Journalism and my first career was as a comedian (now retired, and no longer funny).

The notion that an engineering background is the best foundation for product management has two drivers. First, it seems to provide proof of technical chops. I suppose this is true. Thing is, though, all software efforts are unique. A background developing a software product isn’t necessarily relevant to the management of a different product. I’m more interested in experience successfully managing products that depend on different technologies than a background writing code.

Second, there’s the notion that an engineer will be more successful working with the developers that will ultimately build the product. I dunno. Claiming that a person will be more successful brokering relationships by dint of an engineering background seems a stretch to me. Besides, a product manager has to successfully form relationships with many different stakeholders. It’s not enough to be “respected” by engineering. You also have to work well with the sales organization, the marketing organization, the operations folks, and, most of all, the customer.

To me, there’s no specific background or degree that’s better or worse for a product manager. What matters is intelligence (both academic and emotional are equally important). Proven technical acumen — not a degree, but a demonstrated record of successful management of software products. A strong, palpable passion for creating products — show me a person that talks with excitement and passion about previous projects. Communications acumen — an ability to speak well in front of others, to effectively present, and to write well. Demonstrated leadership — I’m leery of candidates that break out the old saw about how the most difficult part of product management it is to “be responsible for the behavior of people over which you have no authority.”

To boil it down: hire people that are smarter than you, and that aren’t assholes.

The product management function can be described as a “bridge” between sales and engineering; responsible for helping make sales successful by providing a product that customers want to buy, and helping make engineering successful by defining the requirements for such a product.

In Silicon Valley, reqs almost always ask for “strong communication skills” and “solid writing ability,” but in the end its the acumen for technology that matters. What people ask about is whether the person is sufficiently “technical.” So how technical is technical enough?

The answer is that it depends. A product manger’s technical depth should be sufficient to enable them to innovate, to think creatively about how the technology could be used to solve customer’s problems.

Sometimes, this don’t mean a person has to be particularly technical. Web technology, for example, is mature enough for people to speak about it abstractly; to talk about features and functions without knowing or caring how it happens. A product manager for an MPLS router deployed in 10GigE networks, on the other hand, needs solid geek credentials.

A good way to gauge if a person is technical enough for a particular product management role is to ask about how they have innovated in the past. For example, in the context of your particular product, ask the candidate to “give me a couple examples where you were creative in defining product features to solve a customer’s problem, or tackle a market opportunity.”

Not only will this help you measure if the person has the appropriate technical depth, but whether they are too technical. After all, someone with a background developing compression algorithms might not be the right choice to manage a social networking site for pre-teens.

In a previous post I’ve mentioned my position that product management should not be part of an engineering department. Some folks have said that my argument is too academic and doesn’t have relevance in the real world. Fair enough. I’ll try again:

A product manager is measured by the success of the product in the market. An engineer is measured by the extent to which the developed product aligns with the requirements developed by the product manager. A product manager reporting into engineering is set up for failure: product requirements will be developed with an eye toward helping the engineering department succeed, not success in the market.

To be fair, there is one benefit of placing product management in engineering: When the company goes out of business and everyone is saying their goodbyes in the parking lot, people will feel a little better knowing that they consistently developed a product exactly according to spec.

James Grunig is a noted public relations theorist best known for developing the “situational theory of publics,” which defines a method by which a population can be segmented (into “publics”) based on their understanding of a particular problem and the likelihood that they will change their behavior to address the problem.

Segmenting a population this way is a useful exercise for public relations practitioners because it helps predict the effectiveness of communication aimed at a particular group of people. It’s a useful exercise for product managers as well, because it can provide a foundation for a messaging strategy and help define what kind of collateral is needed and what it should say.

The situational theory provides for a number of variables that describe an individual, who can then be classified into “publics” based on commonalities. For example, an individual can be measured by the extent to which they:

Further, these variables affect the degree to which a person is likely to:

To a product manager, the population that matters is the group of people that can perceive a benefit from the product and are therefore likely to purchase the product. The initial stage of developing a messaging strategy, then, is to identify that group of people. For example, an application that helps restaurants manage their reservations has a fairly well defined target population — you aren’t likely going to market the application to Carphone Warehouse franchisees.

However, within this well defined population exist separate publics. The goal is to communicate with each of them. This requires the creation of multiple messages, each specifically tailored to a particular group. For example, you might segment your population as follows:

1. An information seeking public that already understand the problem, feel the problem affects them, and are seeking to solve the problem. They are looking for information about your product, and are best served by messaging that emphasizes the various features and functions of your product that differentiates you from the competition.
2. An information consuming public that is aware of the problem, but may not appreciate how it affects them. They aren’t looking for information in particular, and are best served by messaging that emphasizes the many ways they specifically benefit from solving the problem (e.g. an ROI study), or the many ways their competitor is stronger having already solved the problem.
3. An information consuming public that is aware of how the problem affects them, but isn’t aware of any way they can solve the problem. This public is best served by messaging that emphasizes how easy your product is to deploy, how inexpensive it is (in both CapEx and OpEx), and how effective it is.
4. An ignorant public that has little awareness of the problem your product solves. This public is best served by messaging that emphasizes the problem itself, and the many benefits that come from solving the problem.

The point isn’t to develop these messages exclusive of one another, the point is to develop a variety of collateral with different emphasis, designed for different publics. An information seeking public, for example, isn’t interested in wading through verbiage that describes a problem they already fully understand. Similarly, an ignorant public will ignore verbiage that describes how throughly your product solves a problem they’ve never thought about.

Ever wish there was an easy way to ensure your sales force (or anyone else representing your products) was able to receive consistent, high quality training on presentations or other product collateral? There’s no substitute for face to face time, but you can’t be everywhere at once. For an easy and effective solution, I recommend using Cam Studio (http://www.camstudio.org/). It’s free.

Cam Studio is simple, but incredibly cool: it records the audio and video on your computer screen, and delivers the result it in streaming flash videos that anyone can watch. Create a video of yourself demonstrating your product (speaking into a microphone attached to the computer) and send the video to anyone on your team that might give a similar presentation.

You can do the same for anything that you might otherwise present in person; PowerPoint charts, for example. You can make a video of yourself explaining specification sheets or architecture diagrams. Anything at all. Easy to make, easy to send, easy to watch, and free.

Ah, the Waterfall method. For 40 years software companies have attempted to implement a pure Waterfall method, without much success. Even the paper most often (inaccurately) attributed as the origin of the method (the 1970 essay “Managing the Development of Large Software Systems” by W. W. Royce”) describes the Waterfall as prone to error and cautioned against using it. And yet it remains very popular. What’s going on?

To review. The Waterfall method is a software development process in which a product is created in a series of discrete stages. For example, a set of software requirement are written, then the product is designed, then built, then tested, then installed and maintained.

On paper, it’s rational. This rationality is key to its continued popularity: the many milestones and associated deliverables (requirements documents, design documents, test plans etc.) make people comfortable. There is a clear road ahead, a discrete series of steps toward success, all of which can be measured.

Unfortunately, development just doesn’t work that way. Software is hard, and it’s messy. For example:

• Requirements are incomplete when design and development begins. Feature requirements written at the beginning of a project will always be incomplete because the design process will dig up a many “derived” requirements that were not initially obvious. It’s not possible to think through every iteration, use case, and failure cases of a complex software product in the abstract — things become clear with time.
• Development estimates are wrong. Software estimates (i.e. the amount of time a project will take) are typically performed at the beginning of a software life cycle. Unfortunately, this is when the project is least well understood. Designs aren’t fully worked out. Complexity isn’t fully appreciated. Optimistic assessments are made relating to the eventual quality of the code and the amount of time that will be required for testing and debugging. A corollary to this rule is that once an initial estimate is made, it’s rarely updated as the project wears on.
• Requirements change. Customers change their minds. They add new requirements, they modify old requirements. Often they don’t really know what they want, don’t know how to prioritize, and don’t fully appreciate the impact a change can have on the development process. These requirements changes require time to document, design, develop and test, and out of this process even more derived requirements emerge.

Truth is, I don’t believe the Waterfall method really exists. I’d bet that no software project of any meaningful size has ever been developed in discrete stages. A good product manager understands this, and implements process to accommodate randomness, to anticipate chaos. This flexibility anticipates incomplete requirements, poor development estimates, and changing feature sets.

I don’t mean that a product manager should attempt to overturn process within a company committed to the Waterfall method (by insisting that an Agile process be adopted, for example, or a rational unified process). That’s not usually realistic or possible. You can borrow techniques from other methods, however, and integrate those techniques into the existing process.

For example, I’ve had success implementing a daily “semi-Scrum” meeting with all the stakeholders working within a Waterfall-style project. The meeting fostered a common understanding of every detail affecting the project and forced an action toward resolution. It doesn’t matter what specific methods you use, as long as you can answer the following questions in detail:

• How do we decide what to do with a change request? That is, how do we determine whether or not a change request (a new feature, or a altered requirement) meets business goals and therefore should be integrated into the project, deferred, or discarded?
• How do we ensure that development estimates are accurate?
• How do we manage potential delays in the project, or make decisions in terms of trading quality, feature depth, or delivery time.

Incidentally, understanding these issues is a basic measure of an experienced product (or project) manager. It’s amazing how many people I’ve interviewed that present themselves as experienced and savvy, and can about deliverables, document templates, and milestones, but are unable to meaningfully discuss how to manage the problem of unexpected change.

More than 10 years ago I moved from Washington DC, where I was communications director for a lobbying firm, to the media relations department at Netscape. The Netscape communications team were consummate professionals, very skilled at marketing and public relations, and I learned a lot from them. Being new to software, however, I was amused by the use of language that struck me as, well, odd.

One never spoke of using something; rather, it was “leveraged.” Software was never built for a particular purpose; rather, it was “architected.” Being the best was never good enough; one had to be “best of breed.”

No matter. This is the language of software marketing, and I got used to it. Besides, Netscape messaging may have popularized many of what became high-tech marketing cliches, but these phrases were never the focus of the message. Certainly never the entirety of the message. This, sadly, is no longer true.

Messaging in the software industry, by and large, sucks. Probably (and I mean this only in the most constructive possible way) even yours. Consider the following, taken verbatim from a brochure:

[Our company] develops flexible, best-of-breed intelligent software and services for the telecommunications industry and enterprises that accelerate convergence by leveraging communications networks, technologies and applications.

Wow!  Well.  Now that’s something. Except, what the hell does the company do? More to the point, what problem does the product solve?

Can you guess the most common phrase used in technology related press releases? It’s “next generation.” This is followed closely by “flexible,” “scalable,” and “robust,” among a host of others. Please. Marketing leaders must avoid architecting their messaging by leveraging these terms, if you’ll forgive me. Write to the customer. What does your product do?

But first, take a look at your website. At your collateral. Does it say “next generation” anywhere? Are you scalable, available, robust, flexible? Are you a platform? Do you feature an enterprise-class (or carrier-class) engine? Are you cutting edge? Easy-to-use, user-friendly, integrated, or interoperable? Tell me, do you leverage a bunch of industry standards?

Here’s the rule: when writing any marketing material, consider your customer first. Write for them. Start with them, and with their problems, first. Write about that for awhile. Then consider what your product does for the customer. What problem does it solve, what pain does it assuage, what pleasure does it provide, what would move someone to pay to experience your wonderful next generation product? Write all that down, then go back and edit and massage. Maybe even throw in a “leverage” or two, just to show you’re a team player.

Once you do that, that’s probably enough to stand out. You won’t have to go into why your product is differentiated from your competitors — you’ll be differentiated because your customers will understand what it is your product does. And your competitor’s product? Your customers won’t be sure what it does, except that it does it in a “next generation” kind of way.

Most companies with which I’ve worked use Microsoft Word documents to manage their requirements. In my experience, the process usually goes something like this: the product manager sits down and writes a PRD over the course of some weeks (how the PM arrives at the specific features is the topic of another post) . Triumphant upon completing the onerous doc, the PM emails the completed PRD to the various stakeholders (executives and engineering, primarily), none of whom read it.

A review meeting is scheduled. If inexperienced, the product manager imagines a meeting in which people will alternatively praise the PRD and say things like “I don’t fully understand requirement number 344, can you elaborate?” The meeting, it’s imagined, will take an hour or so.

The experienced product manager girds himself for the wrenching, grating, contentious, plodding marathon that awaits. Each person in the review meeting is reading the document, projected onto the wall, for the first time. Some participants have an idea what the goals of the next generation product are, none of which align with the PM’s vision. Most participants don’t really know what’s going on. Hours later, the meeting adjourns having discussed only a few requirements.

And so it goes, meeting after meeting. Multiple revisions of the PRD are generated, each emailed about. Soon everyone has a different version. Documents that have the same version number have different content. And so on.

Okay, so a lot of things are wrong here, but I don’t have the energy to address them all in a single post. I’m talking today about doing away with multiple iterations of word documents to manage requirements. Instead, move them all onto a centralized online system. (Make sure it’s backed up regularly).

There are a few commercial systems for online requirements management, but I use trac (http://trac.edgewall.org/). It’s a open source bug tracking system similar to bugzilla or mantis, but it’s easily customized for requirements tracking. After many, many false starts with various solutions, Trac seems to best fit the bill. It isn’t perfect, but it’s pretty good. Here’s what I like about it (I use the development version, 0.11):

• You can enter requirements individually and sort them any way you wish. Want a list of the next project in order of priority? Boom. What the same list according to engineering resource required? No problem. What a list of requirements specific to an individual component in your product? One click away.
• Anyone can ask questions or make comments about requirements, and everyone can see other’s comments so there is a positive feedback loop with little redundancy.
• You can label entries any way you wish. My system has categories for requirements, requirement candidates, feature requests, change requests, and use cases.
• You can build custom fields so that requirements can be categorized as many different ways as you please. I’ve created custom fields for “estimated engineering effort,” “customer,” “project name,” and many others
• You can identify milestones, associate requirements with them, and build a roadmap with a single click.
• It has a built-in wiki. I use it wiki pages as a project home page, with links to sets of requirements and use cases.
• You can embed images into requirement listings (my team often creates flow charts illustrating use cases and embeds it in the requirement).
• You can upload any kind of attachment
• You can view all changes to a requirement made over it’s lifetime, with a chart showing the differences between one iteration and another.
• You can integrate the system with CVS, subversion, or perforce so that you can directly associate code with the requirements.

What don’t I like about it? Hm.

• There’s no WYSIWYG interface; product managers must use wiki syntax to enter requirements. This can be a problem when entering complex tables and such. Usually the team just attaches a document if necessary (or embeds HTML).
• I cant’ think of anything else.

It’s a great collaborative tool that centralizes all requirements and does away, once and for all, with the stack of paper that no one reads anyway.

Being a product manager is challenging. The role requires an understanding of customers, competitors, market trends, analyst opinions, and technology. It requires an ability to focus on the minute details of product requirements while simultaneously guiding those requirements in support of a high-level strategic vision. Product managers are held responsible for the actions of persons in different cross-functional teams; they are responsible when a product fares poorly, and give accolades to others when things go well.

Successfully managing a product team requires the creation and maintenance of an atmosphere in which product managers can be successful. Primarily, this means fostering a strong sense of collaboration — a certain positive chemistry. Creating an atmosphere in which the team “gels,” working together to ensure the success of all it’s members. It sounds like something of a platitude, I know. But every successful product team with which I’ve ever been involved displayed a strong degree of camaraderie.

To build such a team, I follow a basic rule: I make sure everyone I hire is smarter than I am, and I make sure they are not an asshole. A corollary to the rule: if I make a mistake and hire someone that doesn’t meet either of the two standards, I immediately help that person find a new role in which they will be more successful.

That bears repeating, although it’s the topic of another post: if you make a hiring mistake, address the mistake immediately.

Once the team is built, the challenge is to nurture and grow a team that works together in such a way as the whole is much stronger than the parts. There are many tactics to accomplish this, most of which are rely on physical proximity.

But what if you are building a team that is geographically dispersed? For example, it’s becoming quite common to lead a product team based in India, or to manage a team with members telecommuting from multiple locations worldwide. How to best build a team out of a group of such geographically dispersed people? It’s certainly possible, as is demonstrated by every open source project.

Turns out that there’s no difference between managing a geographically dispersed team and one that sits together in a bullpen. Physical proximity makes managing a team somewhat less challenging in terms of focus and effort, but the rules are the same:

1. You can’t rely exclusively on email, emailed documents, IM, and conference calls to communicate. Nor is it enough to version control documents in a CVS, subversion, or Perforce. There’s nothing wrong with these tools, but you must also implement an online collaboration tool to centralize and track communication across many different time zones. There are many, some suited to particular projects better than others. Basecamp (http://www.basecamphq.com/) is a popular commercial solution, but there are free options ranging from wiki software to combination wiki/tracking systems such as trac (http://trac.edgewall.org/).
2. Make sure people use the collaboration tool. Any tool is ineffective if it’s ignored or (worse) half-used. Getting people to use a new system is difficult; you must be prepared to insist.
3. You must have a clear, specific product strategy. What is the long term strategic goal, the vision, toward which the team is working?
4. You must have a clear, specific set of tactics to meet the goal.
5. You must have a clear idea how each team member will contribute to meeting the various tactical objectives.
6. You must make sure that every team member is clear on all of these messages. Each member of the team must be able to comfortably answer: What is our goal? How are we reaching the goal? What is my role? How will my success be measured?
7. You must carefully, daily, painstakingly, work with each member to ensure they remain clear — not only on the overall vision and tactics, but on their individual contribution.

In a global economy, geographically dispersed teams are more and more common. It takes effort to lead a such a team, but it can be done successfully.