Abstraction

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.

There’s a well-known (but probably apocryphal) story about Larry Ellison being introduced to the first product manager hired by Oracle. “I don’t get it,” Larry supposedly told the hapless new employee. “You aren’t building something, and you’re not selling something. So tell me again why you should be working for me?”

As Ken Norton points out in his excellent essay, a product manager is the one job that an organization can get along without. Without product managers, sales people can still sell products, and engineers can still develop products.

So what good is a product manager? Truth is, if the company is very new, very small, and has a very specific and well understood product and target market, a product manager probably won’t add a lot of value. In such a company, keeping customers happy by getting builds done, tested and out the door is all the matters.

It’s the next step that matters. Problems begin when an established technology company wants to move beyond their initial success and grow the business. So much effort has been placed nurturing initial customers and growing the customer base, so much blood sweat and tears have gone into developing the first product, that it becomes difficult to see the big picture and recognize opportunities for growth. This is especially true if the initial product launch was very successful.

The more successful an initial launch, the more likely the executive team will develop an unrealistic view of their powers and their market knowledge. They believe that they can will markets into being; they believe that a product strategy is a good one because they thought of it. It’s just not true, though. Research has shown the second and third products introduced after an initial success almost do poorly. The company has stopped listening to the market in favor of listening only to their own customers and to their own ego.

This, then is what product managers do. They bring balance to a company and help guide product strategy by listening to the overall market with an understanding of the potential for technology to address that market. They help a company grow to the next level.

Incidentally, this requires an unusual balance of skills. A product manager must have the ability to understand both a market and how technology can be used to solve problems within that market. A person that can do this well is rare, and makes hiring a challenge (see Ken Norton’s excellent post referenced above).

Software is abstract. From a product perspective it doesn’t exist in the sense that, say, an automobile exists, or a laundry detergent.  Software is ephemeral—so we can’t touch it, we can’t directly measure it, and we can’t see it.  This makes marketing and managing software products different from managing “traditional” products; it’s much more challenging, especially if the product is new or if it performs behind the scenes (such as a middleware product). The challenge means that product management or marketing is a rewarding career. It also means you’re probably going to screw up a lot.

This blog is about the things I’ve learned over the course of more than a decade of screwing things up.