Abstraction

If you haven’t seen David Pogue’s article about product manager’s it’s worth a read.  Money quote:

Good P.M.s, like good criminal lawyers, must sometimes be actors, making their case with conviction and passion when they’re representing a loser.

In the most highly stressed projects, people at all levels talk about the schedule being “aggressive,” or even “highly aggressive.” In my experience, projects in which the schedule is commonly termed aggressive or highly aggressive invariably turn out to be fiascoes. “Aggressive schedule,” I’ve come to suspect, is a kind of code phrase — understood implicitly by all involved — for a schedule that is absurd, that has no chance at all of being met.

Tom DeMarco, Slack

Many people organize the various types of software into three general buckets: shrinkwrap software (that’s sold in retail stores), enterprise software (that’s sold directly to a business), and web-based software (usually consumer oriented such as eBay or Yahoo).

Some years ago Joel Spolsky expanded on this in a great essay about the “five worlds” of software, in which he describes the how the context for a particular software project defines many aspects about the nature of the project — from how requirements are gathered, to how the project is managed, to the relative importance of getting it right the first time:

I think there are five worlds here, sometimes intersecting, often not. The five are:

1. Shrinkwrap
2. Internal
3. Embedded
4. Games
5. Throwaway

When you read the latest book about Extreme Programming, or one of Steve McConnell’s excellent books, or Joel on Software, or Software Development magazine, you see a lot of claims about how to do software development, but you hardly ever see any mention of what kind of development they’re talking about, which is unfortunate, because sometimes you need to do things differently in different worlds.

I think there is another world of software development, one that somehow seems hidden from the mainstream: telecom software development; that is, software developed specifically for carriers such as Sprint, AT&T, Verizon, Deutsch Telecom, etc. Here beats the true heart of geekdom; here are the systems that make up the fantastically complex networks at the heart of the Internet and of cellular telephony systems.

I’ve been thinking about the best way to describe how and why software development for carriers is different, when Marc Andreessen wrote a blog post that did the job much more eloquently than I ever could. Marc was writing about the challenges of working (as a start up) with large companies, but his insights are perfectly applicable to small companies that aspire to sell to carriers:

There are times in the life of a startup when you have to deal with big companies.

Maybe you’re looking for a partnership or distribution deal. Perhaps you want an investment. Sometimes you want a marketing or sales alliance. From time to time you need a big company’s permission to do something. Or maybe a big company has approached you and says it wants to buy your startup.

The most important thing you need to know going into any discussion or interaction with a big company is that you’re Captain Ahab, and the big company is Moby Dick.

The gist is that large companies do what they want, and you (as an Ahab-like small company) are totally helpless to control them, predict what they will do, or even make sense of what they have done.

A small company attempting to sell software to carriers (and there are many), this problem is magnified many times over. Not only are your customers akin to Moby Dick, but you are often working with (or attempting to work with) the other huge whales that keep Moby Dick happily swimming along.

For example, imagine you are trying to sell British Telecom (or whomever) some content, or services, or mediation, or analytics, or OSS/BSS system, or whatever. Of course you have to contend with the mind bending bureaucracy of huge carriers, their unique software requirements (NEBS compliance, 5-9 availability, scalability to 100s of millions, n+1 failover and geographic redundancy) , and their endless sales cycles. But you also have to manage relationships with the huge equipment providers that are often your best channel into carriers (Ericsson, Nortel, Nokia, Siemens, etc.).

Unusually difficult, onerous requirements. Huge, fickle customers. Huge, fickle partners. Grinding, painful, glacially slow sales cycles. Not for the faint of heart, and worthy of a special category all its own.

Interesting essay from Andrew McAfee about Tom Malone’s Future of Work. Future of Work talks about how information flow was once associated with decision maker; that is, because information was expensive to gather and transmit, it was made available only to the persons that needed it to make a decision. With the emergence of internet technology, the cost of distributing information is effectively zero. With huge amounts of information available to anyone within an organization, the organization becomes more decentralized, less hierarchical.

McAfee points out a flaw in this argument, essentially saying that a general availability of information is not necessarily correlated with decentralized decision making:

Let’s say that a mortgage company realized that a few of its loan officers were just better at assessing credit risk than all the others. For whatever reasons (intelligence, experience, intuition, etc. ), they just had superior specific knowledge. In that situation, it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers. All the general knowledge (income statements, credit histories, etc.) would be sent to these few people, who would apply their specific knowledge to it and made decisions. In this example low information costs are still important; they allow all the general knowledge to be zipped to the few good officers. But the effect of low information costs isn’t decentralization and greater empowerment. Instead, it’s centralization of an important decision right and reduced autonomy for most loan officers.

Thought experiments like this one indicate to me that the net result of disappearing information costs won’t necessarily be decentralization. It will instead be the decoupling of information flows and decision rights. Organization designers will be able to allocate decision rights without worrying about how costly it will be to get required information to deciders. Leaders will be able to ask “Who should make this decision?” without adding “Keeping in mind that it’s going to be slow, difficult, and expensive to get them the general knowledge they’ll need.”

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case. I agree with him that we’re at a very interesting point in the history of technology and the economics of information, but I’d label it a great decoupling (of information flow and decision rights) rather than a broad decentralization (as decision rights lateralize along with information flows).

I’m a big proponent of making information available to anyone in an organization; I have posted before about the importance I place on an online product requirements tool and a product information wiki to encourage and enable collaboration. I do this because markets are dynamic and technology is complex, and I believe that multiple inputs on product definition is larger than the sum of it’s parts. Certainly of a much greater benefit than can result from the efforts of a single centralized product “decider.”

To me, the mortgage example given above doesn’t hold the same implications for organizations as it seems to for McAfee

Will this work always, or even usually, lead to more decentralized organizations? I find myself less confident than Malone that this will be the case.

I think it is true that some decisions will always be centralized because it requires tacit knowledge that only a few possess (as in the mortgage example). But strategic decisions, such as a product evolution, will always benefit from the input of multiple perspectives.

Further, efficient dissemination of information enables the development of tacit knowledge and enables contributions from persons that would otherwise not have the opportunity. In this sense, too, the mortgage example seems to fall short: common information flow enables the development and identification of more people that happen to be very good at a particular role. McAfee’s comment that

…it would make good sense not to decentralize, but instead to centralize that decision right within the company, taking it away from the other loan officers.

It’s important to place decision making responsibility in the hands of those that will make the most effective decisions. But it’s also important to nurture superior decision making skills so that the decision workflow avoids a single point of failure. Instead of taking away the decision making rights of lesser-skilled workers, why not leverage the information flow to enable a sanity check of their decisions? The burden on the more-skilled worker will not increase, and the organization benefits from growing the (forgive me) “competence footprint” associated with a particular skill.

I was recently re-reading Jeff Bigler’s funny essay about why engineers and “normal people” can have trouble communicating.

It would be nice to install tact filters on my Outlook. Certainly it would make reading email more pleasant. More importantly, it could nicely transform email sent after grumpily returning to my hotel room following 12 hours chirpily repeating the same spiel on some convention floor.

“Goodness knows,” the newly-tactful email would begin, “I would love to participate in the 9-11 pm meeting you scheduled at 8:51. I thank you for the opportunity to contribute; sadly, I may be unavailable…”

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.