I get several emails every week from readers with excellent questions on product management related topics. I try to answer as many as I can. Recently I received a nice email from a reader, Kim, that asked "Michael... What do you feel are the most important professional characteristics of a Product Manager?"

This question got me thinking. I started writing down the characteristics of excellent product managers I've had the good fortune of working with. Then I picked the seven traits that are most common among these folks - I summarize them in this article in order of priority.

By the way, I recently watched the movie Borat - in honor of that movie, I'm using the following subtitle for this article!

Observational Learnings of Traits for Make Benefit Glorious Craft of Product Management

Seven Traits of Successful Product Managers

1. Communication Skills

   Successful product managers are excellent communicators.

   This is the most common characteristic shared by all excellent product managers I've worked with - written and oral communication skills. Why is this important?

   At most companies, a critical role product managers play is acting as a communication hub on product-related matters - as shown in the figure below.
   
   
   
   This means - a successful product manager not only has the ability to communicate effectively with different roles, but also has the ability to:

   • Communicate with different personality-types.
     • For example, majority of engineers tend to be "introverted", while majority of sales/marketing folks tend to be "extroverted".
   • Speak different "languages" when communicating with different roles.
     • To communicate effectively, it is important that you speak the "language" of your target audience. This means you have to use a "different language" while communicating to marketing personnel, as opposed to engineers. Likewise, when communicating with executive management, you must focus more on "forest level" than "tree level" - this is a mistake I see many product managers make.
2. Leading Without Authority

   Successful product managers are excellent leaders, even when they have no formal authority.

   At most companies, product managers are expected to play "leadership role" in several areas. These include leading project teams, leading product strategy and roadmaps, leading cross-functional product initiatives, etc.

   Yet, in most of these situations product managers don't have any formal authority. This means, you have to be really good at "leading without authority" to be a successful product manager.

   How do you lead without authority? I'd say - using a combination of influencing, negotiating, relationship building and other similar skills.

   Is it possible to lead without authority? My thought on this is summarized well by the question Tom Peters, the popular management author, asks:

How much formal authority did Mohandas Gandhi and Martin Luther King Jr. have?

3. Learning Skills

   Successful product managers have the ability to learn fast - even in relatively new areas.

   In most segments of the high-tech industry, markets change fast. New technologies are always right around the horizon. What is a "differentiated product" today becomes a commodity within 6 months. Sometimes even faster.

   A successful product manager must have the ability to learn fast - even in areas that are relatively new to them. If a product manager has this ability - it is relatively easy to manage products in new markets.

   One mistake that I think most companies make when hiring product managers is - they look for "strong subject matter knowledge". For example, if a company makes security software - they look for product managers with "5+ years experience" in security software. I think this is a misguided approach. A far better approach is to look for a product manager with experience in the software industry, and the ability to learn quickly. This approach has worked well for me - some of the best PMs I've hired had no "subject matter knowledge" prior to hiring!

4. Business Acumen

Successful product managers have a good understanding of the fundamentals of business.

Like This Article? Why not share it with friends and colleagues? Just click here...

They understand how to identify market opportunities, importance of competitive differentiation, creating winning product strategy, pricing and promotion, partnerships, analyzing P&L statements, and so on.

This doesn't mean they need an MBA. As a matter of fact, most of the successful product managers I've worked with don't have an MBA - but all of them have a strong grasp of business fundamentals.

5. Love for Products

Successful product managers have an inherent love for products.

They delight in kicking the tires of new products in the market - as many as they can get their hands on. They sign up for a ton of "betas", check out the latest web sites, download trial versions of software just to check them out, and so on.

They delight in well-designed products - even if not made by their own company. They loathe poorly-designed products - even if made by their own company.

Above all, they love creating great products - whether it is a brand new product, or enhancements to existing products.

6. Eye for Details

Successful product managers have an eye for details.

Focus on details is an essential pre-requisite to creating great products - as I mentioned in my previous article and Steve Jobs mentions in the following quote:

The iMac is not just the color or translucence or the shape of the shell. The essence of the iMac is to be the finest possible consumer computer in which each element plays together.

On our latest iMac, I was adamant that we get rid of the fan, because it is much more pleasant to work on a computer that doesn't drone all the time. That was not just "Steve's decision" to pull out the fan; it required an enormous engineering effort to figure out how to manage power better and do a better job of thermal conduction through the machine. That is the furthest thing from veneer. It was at the core of the product the day we started.

This is what customers pay us for--to sweat all these details so it's easy and pleasant for them to use our computers. (emphasis mine)

Successful product managers focus on details not only when it comes to product features - but also in competitive analysis, project plans, and in pretty much every major activity that they are responsible for.

7. Routine Product Management Skills

Successful product managers have good "routine product management skills".

These are the skills needed to perform the routine tasks of a product manager job. They include writing MRDs & PRDs, performing competitive analysis, creating product roadmaps, creating presentations that communicate product features & benefits, defining user interfaces, and so on.

This set of required skills varies from company to company. I put this characteristic last, since I think most of these skills are easily learnable by product managers who possess the six earlier skills.

There you have it. My list of seven traits shared by successful product managers:

1. Communication Skills
2. Leading Without Authority
3. Learning Skills
4. Business Acumen
5. Love for Products
6. Eye for Details
7. Routine Product Management Skills

I know I have seven areas to improve - how about you?!

I find that this list is not only useful in self-improvement, but also when interviewing candidates for the product manager position.

Does this list make sense? What are the other skills you would add? Let me know by clicking the 'Post Comment' link below.

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 03:22 PM | Permalink | TrackBacks (0) | 5 Comments | Post Comment

As you might recall, in my last article I made a very convincing (ha!) case that Design is the Soul of Products. And I finished that article by saying that most high-tech products totally suck at design.

There were excellent points made by several commenters, including Scott Sehlhorst who wrote a great post in his own blog.

In this article, I will outline five tips to help Product Managers and Product Marketers create products with "Kick-Butt" design. Let us get started.

Five Tips for Kick-Butt Design

1. Start With the User Interface

   Right after gathering and prioritizing high-level requirements, get to the User Interface (UI) design. Do this before you complete your MRD or PRD. Yes, before! You may be wondering "Michael, is that not like putting the cart before the horse? Why should I do this?". Wonder no more - here is my answer!

   Because the UI is the only thing your end user sees of your product. The only thing!
   
   Yet, most high-tech companies I know of first create the product. Then they throw together a UI before releasing the product. The UI is an afterthought. And it shows.

   I believe the UI should be the first thought. The most important thought. Remember - the UI is the only thing your user sees. This leads to my Tip #2.

   Like This Article? Why not share it with friends and colleagues? Just click here...

   

2. Work Closely With UI Designers

   If UI is so important, it follows naturally that Product Managers should work very closely with UI Designers to achieve kick-butt design.

   Yet, in most companies the relationship between product managers and UI designers tends to be an "arms length" relationship. Especially in large companies, these two departments are practically silo'ed. The PM throws the MRD or PRD over the wall. The UI designer creates the UI to fit those requirements.

   I believe this is the wrong model. Actually, exactly the wrong model - if what you want is kick-butt design.

   I'd go so far as to say that you should have PM's and UI Designers under one department. I have tried it. They are under one department in my company. And, it works great!

3. Pay Attention to Details

   Remember the Steve Jobs quote in my last article:

   The iMac is not just the color or translucence or the shape of the shell. The essence of the iMac is to be the finest possible consumer computer in which each element plays together.

   On our latest iMac, I was adamant that we get rid of the fan, because it is much more pleasant to work on a computer that doesn't drone all the time. That was not just "Steve's decision" to pull out the fan; it required an enormous engineering effort to figure out how to manage power better and do a better job of thermal conduction through the machine. That is the furthest thing from veneer. It was at the core of the product the day we started.

   This is what customers pay us for--to sweat all these details so it's easy and pleasant for them to use our computers. (emphasis mine)

   Want kick-butt design? One absolute pre-requisite is "sweating the details". Without it, kick-butt design is just not possible.

   One common comment I've heard in bug reviews is "But, this is just a cosmetic flaw. It is low priority, and given the time pressures we can't fix it".

   Well, here is my take - no such thing as "low priority cosmetic flaw". Cosmetic flaws are high priority. Very high priority. Often, they are easy to fix to boot.

   Try this next time: Insist that all cosmetic flaws be fixed. It may be a hard sell at first, it certainly was for me. But insist on it nevertheless. It works wonders. Mostly!

4. Simpler is Better

This is one of the most important tips to achieve kick-butt design. Keep your product, and its design simple - as simple as possible.

Design for the 80% use case. Do not fall prey to "Featuritis" - more features are not always better. More often than not, more features are worse. Much worse, in fact. Don't believe me? Well - at least believe Kathy Sierra, will ya?!

Check out my earlier article for further thoughts on this very important idea. It is a simple idea - but not an easy idea. At all. This leads to my last tip.

5. Be Brave

To achieve kick-butt design you gotta be BRAVE. This is an absolute must. Why?

Because most folks in your organization would want to water down the design to make it more like competitors'. A superset of features seen in competitive products.

Be brave - just say "No". Kick-butt products are created by saying "No". More than anything else.

iPod has no FM/AM radio. No voice recorder either. In spite of the fact that 95% of competitive products do. GMail has no folders, even though every single other email product I know of has folders. Think it was easy for their designers to pull these off? No way - they had to be brave and say "No".

There you have it. My five tips for kick-butt design:

1. Start With the User Interface
2. Work Closely With UI Designers
3. Pay Attention to Details
4. Simpler is Better
5. Be Brave

I fully understand that none of these five tips are easy to practice. Heck - if they were easy, everybody will be designing kick-butt products! But we know that not everybody does - as a matter of fact, I think about 94.79% of high-tech products suck at design. Yes, I measured it using a highly scientific process!

Be the other 5.21%. Practice these five tips. Persist even though it is hard - it will pay off in the form of products with Kick-Butt design. Well, at least Sucks-Less design!

What do you think? Do these tips make sense? Let me know by clicking the 'Post Comment' link below.

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 11:09 PM | Permalink | TrackBacks (0) | 6 Comments | Post Comment

"Soul" is a powerful four-letter word - as powerful as any in the English language! Whenever you hear that word, it evokes strong emotional feelings - but what exactly does it mean?

Merriam-Webster Dictionary defines it as:

Soul noun

1. the immaterial essence, animating principle, or actuating cause of an individual life

2. the spiritual principle embodied in human beings, all rational and spiritual beings, or the universe

The great ancient Greek philosopher Plato, influenced by his teacher Socrates, wrote of soul as the essence of a person, being that which decides how we behave.

Okay, we're getting somewhere with our question. "Soul" seems to be the essence or the actuating cause that decides how someone or something behaves.

Does Your Product Have a Soul?
This brings us to the single most important question in this article:

Does your product, whether it is software or hardware, have a soul? If so, what is it? (Okay, two important questions!)

To answer these questions, let us turn to a great 21st century philosopher. A man named Steve Jobs! As many of you know, Steve is the founder & CEO of Apple, and the guy who gave us humans such great products as Apple computer, Mac OS, iMac, iPod, Toy Story, Finding Nemo, and of course, the ubiquitous Microsoft Windows.

I can hear some of you asking "Wait a minute, didn't Bill Gates give us Microsoft Windows?". Well, if you're one of those folks with that unfortunate misconception, you must not have listened to any of Steve's speeches. As he incessantly reminds us, Apple created Microsoft Windows - or most of what is in it anyway. Gates & co just copied it shamelessly (shamefully?) and distributed it widely to the masses!

Kidding aside, Steve is one of my favorite "builders". He just knows how to create great products. Wonderful products. Beautiful. Functional products. Elegant. Simple. Products that break the mold...

In his interview with Fortune magazine in 2000, Steve said:

Design is the fundamental soul of a man-made creation that ends up expressing itself in successive outer layers of the product.

There you have the answers to those two questions we posed earlier:

Yes, your product does have a soul. That soul is, DESIGN.

Alrighty then, we have resolved this, haven't we? Well, if only it were that simple! Now we're left pondering the question "What exactly is Design?"

What is DESIGN?
Ponder no more! In the same interview, Steve says:

In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains of the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product.

Okay, so Design is that thing that expresses itself in the successive outer layers of your product. But it is not the veneer.

What does "successive outer layers" mean when applied to your product? I'd say it is not just the look and feel - the colors and images, although they're a part of it. It is the user interface - the whole of it. The way the outer layers of your product interact with the user - the only things your user sees. That is Design. Right?

Steve continues:

The iMac is not just the color or translucence or the shape of the shell. The essence of the iMac is to be the finest possible consumer computer in which each element plays together.

On our latest iMac, I was adamant that we get rid of the fan, because it is much more pleasant to work on a computer that doesn't drone all the time. That was not just "Steve's decision" to pull out the fan; it required an enormous engineering effort to figure out how to manage power better and do a better job of thermal conduction through the machine. That is the furthest thing from veneer. It was at the core of the product the day we started.

This is what customers pay us for--to sweat all these details so it's easy and pleasant for them to use our computers.

Like This Article? Why not share it with friends and colleagues? Just click here...

There you have it. Great design is about sweating all the details - so that when your users interact with the outer layers of your product, the experience is as easy and pleasant as possible.

By this measure - I think most high-tech products suck! They either don't have a soul, or the devil has stolen them!!

Wondering what are some of the ways to get your product a soul, or to even steal it back from the devil? I'll cover that in my next article. Until then, here is to products with great soul...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 09:10 PM | Permalink | TrackBacks (0) | 7 Comments | Post Comment

Earlier this week I got a friendly email from a reader. She asked me whether I could write an article comparing the different requirements document formats used in the software industry. You know - BRD, MRD, PRD, FSD, PSD, SRS, IRS, etc.

I'm frequently asked many variations of this question - so I'll try and explain all of these briefly in this article. Well, all except that last one!

Alphabet Soup
If you're like me, you grew up with a variety of alphabet snacks - alphabet cereals, alphabet biscuits, alphabet soup, and many other snacks shaped like alphabets. I guess most of us must have really liked them - or were really tormented by them! I don't know which one for sure - but the net effect is they seem to have had a deep influence on most of us.

Now we're all grown up and rarely eat those alphabet snacks any more - but in nearly every profession, the industry jargon is an alphabet soup overrun by TLA's (three letter acronyms). FBW (for better or worse)!

Product management and product marketing is no different - especially when it comes to requirements documents. We have BRD, MRD and PRD; we also have FSD, PSD and SRS; and many different variations of these.

As if that is not enough, all organizations do not use these terms in the same way. What one organization calls MRD, another may call PRD. Sometimes I can't help but LOL (laugh out loud) when I see yet another new TLA. That said, let us try and get our hands around these.

Useless Trivia Question: Using only the uppercase alphabets in English, how many different TLA's can you create?

P.S. If you got this far and don't know what TLA stands for, shame on you! Please reread from the start, will ya?

All The News That's Fit to Print - About Requirements Document Acronyms
Let us take a quick look at the most common acronyms used while referring to requirements documents:

1. BRD
2. MRD
3. PRD
4. FSD
5. PSD
6. SRS

1. BRD - Business Requirements Document

   A Business Requirements Document (BRD) focuses on defining the business needs of a project. The BRD identifies one or more business problems faced by customers that can be solved by the company's product. It then proposes a solution - usually a new product or enhancement to an existing product to address these problems.

   It may also include a high-level business case -- such as revenue forecast, market & competitive analysis, and sales/marketing strategy.

   It is usually written by someone with the title of Product Manager, Product Marketing Manager or Business Analyst. In small companies, it may be written by senior execs or even founders.
   
   It is usually a Word document running 1-3 pages, or a PowerPoint document running no more than 10 slides.

   ---

   Example:
   Let us assume your company is developing a customer relationship management (CRM) software.
   
   The BRD may focus on problems faced by sales managers in keeping track of all ongoing deals and being able to create reliable forecasts. It may identify:

   • Who have the pains
     • Sales Managers at Fortune-500 companies
   • What the pains are
     • No real-time visibility into deal status
     • Inability to create reliable forecasts
   • Proposed solution
     • Create web-based software to track deals and create forecasts

2. MRD - Market Requirements Document

   A Market Requirements Document (MRD) focuses on defining the market requirements for a proposed new product or enhancement to an existing product.

   Whereas the BRD identifies business problems and solutions to those problems - the MRD delves deeper into the details of the proposed solution. It may include some or all of these details:

   1. Features required to solve the business problems
   2. Market and competitive analysis
   3. Functional and non-functional requirements
   4. Prioritization of features/requirements
   5. Use cases

   It is usually written by someone with the title of Product Manager, Product Marketing Manager or Business Analyst.
   
   It is usually a Word document running 5-25 pages, or even longer in some organizations as described later.

   ---

   Example:
   Let us continue with the above example of a company developing a customer relationship management (CRM) software.
   
   The MRD may focus on identifying and prioritizing requirements, as well as describing use cases. Requirements include functional and non-functional requirements such as:

   • Functional Requirements
     • Must work in Internet Explorer (version 6.0 and above) and Firefox (versions 1.5 and above)
     • Must use SSL to ensure security
     • ...
     • User should be able to enter data through browser interface for: customers, companies, contacts, opportunities, deal size, etc.
   • Non-Functional Requirements
     • Must be able to support up to 100,000 simultaneous users
     • Must have uptime of greater than 99.9%
     • ...
     • Need comprehensive user guide in English, German and Japanese

   Please check out this article on writing MRDs for further details.

   ---

   Alert: Some organizations combine MRD and PRD as described here into one document, and call the resulting document MRD. In this case, the MRD will include what is described in this section as well as what is described in the PRD section below - and may run more than 50 pages.

Like This Article? Why not share it with friends and colleagues? Just click here...



3. PRD - Product Requirements Document

   A Product Requirements Document (PRD) focuses on defining the product requirements for a proposed new product or enhancement to an existing product.

   Whereas the MRD focuses on requirements from the perspective of market needs, PRD focuses on requirements from the perspective of the product itself. It usually delves into more details on features and functional requirements, and may also include screen shots and user interface flows.
   
   In organizations where the MRD doesn't include detailed requirements and use cases, the PRD covers those details.

   It is usually written by someone with the title of Product Manager, Business Analyst or Product Analyst.
   
   It is usually a Word document running 20-50 pages, or even longer for complex products.

   ---

   Example:
   Let us continue with the above example of a company developing a customer relationship management (CRM) software.
   
   The PRD may focus on detailed requirements such as:

   • Login screen should include username and password fields. It should also include a 'Forgot Password' link.
   • 'Contacts' screen should include fields for first name, last name, phone, email,...
   • ...
   • 'Forecast' screen should have a 5-step wizard that walks user through the steps required to create annual forecasts. Each step should be as described below...

   The PRD may also include detailed use cases.

   ---

   Alert: Some organizations combine PRD and MRD as described here into one document, and call the resulting document PRD. In this case, the PRD will include what is described in this section as well as what is described in the MRD section above.

4. FSD - Functional Specifications Document

A Functional Specifications Document (FSD) defines the complete details of a product's functional requirements with a focus on implementation. FSD may define the product specifications screen by screen and feature by feature. This is a document that can be directly used by engineers to create the product.

Whereas the MRD and PRD focus on requirements from the perspective of market needs and product, FSD focuses on defining the product details in a form that can be implemented by engineers. FSD may also include complete screen shots and UI design details.

It is usually written by someone with the title of Product Analyst, Engineering Lead, or Program Manager - the author(s) usually belong to the engineering department.

It is usually a Word or similar document running several dozen pages.

5. PSD - Product Specifications Document

   Product Specifications Document (PSD) is a less popular acronym, but in organizations that have such a document, it is by and large the same as the Functional Specifications Document (FSD) described above.

6. SRS - Software Requirements Specification

   A Software Requirements Specification (SRS) is another less popular acronym. In organizations that create an SRS, it has contents and details somewhere close to what is described above for PRD or FSD.

Okay, there you have it - 6 requirement document acronyms deconstructed and explained. Just want to alert you again - all organizations do not use these terms in the same way. Think of these documents as points on a spectrum. Each organization defines which documents to create and where in the spectrum those documents fall - depending on what best fits their unique needs.

Useless Trivia Answer: Using only the uppercase alphabets in English, the total number of TLA's (three letter acronyms) you can create equals:

26³ = 17,576.

You know what this means, right? Be mentally prepared to learn another 17,570 TLA's related to requirements documents.

Alrighty then - our tour through the wonderful land of requirements document acronyms is over. As Tigger would say, TFN (ta-ta for now)!

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 05:30 PM | Permalink | TrackBacks (0) | 3 Comments | Post Comment

I was going to write an article titled "The Soul of a Product" this week emphasizing the importance of design. But then, my plans changed as I went to an event organized by the Silicon Valley Product Management Association this past week.

In that event, Michael Sippey, the VP of Products at Six Apart (a blogging software company whose product 'Movable Type' powers my blog) gave an excellent speech on product management.

The best way I can think of to summarize his speech is: "Get everybody in the van, and do a DILO"! Actually I can think of better ways - but this is a pretty catchy way (I think!) to get you to read further so you can understand what the heck that means.

It is well worth it, so let us get going.

Getting Everybody in the Van
Michael's speech was focused on how things have changed dramatically from the beginning of his career at companies that made packaged software, to now - where he is managing a hosted software product (TypePad).

Michael talked about how much many of the product practices have changed - such as 24-month release cycle vs 2-week release cycle, extensive specification documents vs lightweight specifications using wikis, building a product vs iterating a service, etc. He said the one thing that hasn't changed at all is "Getting everybody in the van". What did he mean by that?

When he started his career in a successful financial software company, one of the key lessons he learned was the importance of understanding customer needs. The way that company did this is by visiting customers at their offices and observing them work. They would get the product manager, engineering manager, and other relevant personnel into a van and drive to the customer sites.

Once there, they would watch them work and ask them questions to understand what needs they have - which ones are being met by their products and which ones are not. This practice enabled them to constantly enhance their products to keep their market lead, as well as create successful new products by unearthing unmet needs.

When they had a new idea, Michael said (I'm paraphrasing):

When we had a new idea, we had to call and set up meetings with 30 prospects. If you don't get 30 prospects to agree to a meeting about a product idea, you don't have much of a product idea.

Well said Michael! All high-tech companies would be well advised to practice this.

I've seen many high-tech companies, both startups and large companies, first create a product because a VP or founder thought it was cool ("I want to do something that uses AJAX"), and then start looking for a problem it happens to solve! Then many of their competitors copy it and pretty soon all of them have got a product looking for a problem.

What is a DILO?
Now to the bonus part of this article, where you will be learning a cool new thing called DILO. What is it, you ask?

Well, it is a totally cool sounding FLA (which itself stands for 'Four Letter Acronym'!) guaranteed to impress your friends! And if you happen to be in consulting, it is guaranteed to pull in 2X hourly rates. I'm so confident about this that I'll refund 100% of your subscription fee to my free blog if you don't get this result, okay?!

DILO = Day In the Life Of

It refers to understanding the "Day in the life of" a customer. The best way to do this is to "get everybody in the van" - and observe customers using your product in context, and asking them questions.

Get the Van Started
Now that you know what "Getting everybody in the van" means, start implementing this into your own product practices. Those of you in product management and product marketing should especially spearhead this. Check out this earlier article for some concrete steps you can take, and get the ball rolling.

As Thomas Huxley, the 19th century British biologist wrote:

The great end of life is not knowledge but action.

Here is to better products, happy customers and more success...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 02:42 PM | Permalink | TrackBacks (0) | 7 Comments | Post Comment

When I first started this blog half a year ago for product managers and product marketers, I never thought I'll be writing an article titled "Don't annoy your customers".

Why didn't I think so? Well, we all know we shouldn't annoy our customers, right? It is stating the obvious - like telling an adult "Don't put your hand in the fire". You already know you will get burned if you do so - unless, of course, if you are Superman!

Adobe Teaches Us What NOT To Do
Well, I got to give "credit" to Adobe for inspiring this "stating the obvious" article. Adobe, as you know, is one of the largest software companies in the world. It makes, among other products, the ubiquitous Acrobat Reader - a free software used to read PDF files.

A few days ago, I was surfing the web. On a journey through the mysterious paths created by this little invention we all love - hyperlinks - eagerly awaiting where each click might lead me - and hoping it is not to yet another site promising "Enlarge your breasts three cup sizes in just two weeks using natural pills extracted from rattlesnake venom". I'm really not that much interested in this sorta thing, given that I'm a guy and all!

In any case, I happened to run across a blog post by Des Traynor titled The Screaming Child of Software. I usually don't like posts that are a bit "ranty", but this one struck a chord right away. Des writes:

Last monday I updated Acrobat, because I accidentally clicked a PDF link. My desktop was hijacked, and basically Adobe decided that it wanted to install the Yahoo! toolbar, update its updater, and update itself. Then, upon rebooting, it all happened again.

I can see you wondering "Why did it strike a chord with Michael?". Wonder no more, the answer is below!

Don't Annoy Your Customers
While the older versions of Acrobat Reader (before v5.0) were very user-friendly, I have noticed that v5.0, v6.0 and v7.0 have become increasingly annoying. First, if you happen to click on a link to a PDF file - the whole browser freezes while Acrobat Reader loads itself.

The latest version (v7.0) takes so long to load, I can go get coffee at Starbucks in the meanwhile - a cup each at all five of their stores located within 2 miles of me!

Why does a software which is just a document reader take so long to load? I guess it is the good, old feature bloat. But this is the least of my concerns about Acrobat Reader.

You see - several times a month, it very intrusively insists that I need to update it without even giving me an option to tell it to go away and never bother me again. I can understand when my OS asks me to update it - after all, it is essential for security. I can even understand when the web browser tells me to do so - as it is a networking and communication software.

But Acrobat Reader? Come on - it is just a document reader. I have another document reader on my computer that does way, way more than Acrobat Reader - at least I think it does. It is called Microsoft Word - and it has never once asked me to update it, let alone doing so in a highly intrusive fashion. That is not all, either.

Check out the comments at the bottom of Des' blog post for even more Acrobat user complaints, including this one from Riley:

I'm a tech writer so I need to generate PDFs. I use Acrobat 5 to do that because it does everything I need it do.

Unfortunately, I need to test view the PDFs in "Free" Acrobat Reader 7. And here's where Adobe's obnoxiousness kicks in.

Reader 7 overwrote my file associations in such a way that I couldn't simply use the Windows' file associations tool to reset them. Instead, I needed to (a) remove the PDF-to-Reader 7 file asociations, then (b) reinstall Acrobat 5 and the 5.5 update to same.

As if that wasn't enough of a problem, Acrobat Reader periodically tries to force feed me "important" updates to itself. Each update, in turn, roughly shoves my existing configuration aside, obliging me to repeat steps "a" and "b" above.

Why Does Adobe Do It?
This brings us to the question of why Adobe might be doing this. After all, they are a successful company full of smart people. The best answer I can think of is the following. They must think since their Acrobat Reader is a "FREE" software, it is okay to annoy the freeloading schmucks - aka Acrobat Reader users. If so, this is a very flawed thinking. Here is why.

Adobe made ~ $400 Million in sales for their Acrobat product family (used to create the PDF files) in the last year - based on their public filings. This is only made possible by all those "freeloading schmucks". Without them, those customers who paid $400 Million to buy the Acrobat products wouldn't have.

I think Adobe should take a page from Google's playbook, another company which has "free users" (visitors to Google.com) as well as "paying customers" (advertisers on Google.com). Google makes the "free user" experience as good as possible - fully understanding those "free users" are the foundation for attracting "paying customers".

Just Don't Do It
Okay, what can we learn from all this? Here is my take:

The customer's (whether paying customer or free user) computer is her home. Our software is but only a guest. Let us create software that is courteous and behaves itself. Or else, sooner or later it will get kicked out and never let in again - usually as soon as they find a half-decent replacement.

I personally happen to like Adobe very much - I hope someone at Adobe reads this article (and Des Trayner's article too) and puts an end to this practice before Acrobat Reader users start defecting in droves. They are headquartered in my hometown and I want them to continue to be very successful.

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 07:32 PM | Permalink | TrackBacks (0) | 16 Comments | Post Comment

Welcome to the first article in the "10 Commandments of Product Management" series. I promised this series about a month ago - or as one of our commenters (Josh) put it, "pre-announced"! The article is finally here, so you can't accuse me of selling vaporware!

Okay, the first question you may be asking is - "Why a series with this title?". Fair enough. Let me start by telling you what is *NOT* a reason - It has nothing to do with religion. I'm not very religious, I certainly don't consider myself the "Moses of Product Management" and I've never even been to Mount Sinai! Now to the why...

My goal in this series is to distill the core essence of product management into ten (or so) commandments. I find top-ten lists to be very useful to grasp the basics of various subjects - so I hope this list will be useful to product managers everywhere and those who work with them.

What does a Product Manager Do?
Here is a question for you. Can you summarize what a product manager does in two words - by filling the blanks in the following sentence?

A product manager is a _____  _____.

Wait, don't read further yet. Fill in the blanks above before proceeding further, will ya? I will wait here.

Okay, ready? Does what you wrote down match what I wrote down (shown below)?

A product manager is a Customer Expert.

If it matches - that is awesome news. It further proves the saying "Great minds think alike"!

If not, let me explain what I mean. As I mentioned in a previous article in this blog, a product manager's roles and responsibilities could vary widely from company to company. But what is the single, most important, common denominator?

To me - it is the ability to understand the customer needs deeply and translate them to requirements. This is what I mean by Customer Expert - an expert about the customer: what the customers' needs are (relative to your product), how those needs are met by your product today, how they could be met better, etc. This brings us to the First Commandment.

First Commandment of Product Management

Know Thy Customer

In a highly competitive marketplace, the company that "knows its customer" better will beat those that don't. I believe one of the top priorities for those of us in Product Management and Product Marketing should be to enable our companies to get better at this.

Here are some steps you can take to "know your customer" better:

1. Listen to Customers:

   The easiest way to know your customers is to listen to them. Talk to them on the phone, communicate via emails, interact with them in discussion forums, etc. The goal is simply to understand what pains your product solves (or pleasures it provides), how they use it, what value they see, etc.

2. Usability Tests:

   Usability tests enable you to observe customers using your products in "simulated real life" situations and give you tremendous insight into how you can make your products better.

3. Follow-Me-Home:

   Popularized by Intuit, this takes the usability tests to your customer's workplace (for B2B products) or home (for B2C products). This gives you even better insights as you're observing them in "real life" situations rather than in "simulated real life" situations.

4. Walk-a-Mile:

   Use your own product as often as you can - i.e. walk a mile in your customer's shoes. This is especially effective for B2C products, as all of us are consumers too.

5. Customer Surveys, and Focus Groups:

   I don't consider these to be as good as the previous steps, as they tend to be more error prone - but they can provide valuable insight into your customers when done well.

There you have it, the First Commandment of Product Management and some steps to help you follow it. Here is to better products, and more success...

What are your thoughts and comments on this topic? Let the world know what you think by clicking on the 'Post Comment' link below!

Posted by michael at 12:17 AM | Permalink | TrackBacks (0) | 5 Comments | Post Comment

The year was 1928. Paul and Joe, two brothers in Chicago, decided to go into business for themselves. They incorporated their business under the name Galvin Manufacturing Corporation - and launched their first product.

It was a battery eliminator - something that was "high tech" in those innocent*, bygone days. After all, it made battery-operated radios run on household current. No small feat, that. They sold a whopping $63,000 worth of it in their first year, booked a tidy profit of $6,015 and employed five people. Life was sweet and all was peachy.

* P.S. I have no idea whether the 1920's were really "innocent days" or not - but a book I read recently claims they were. Proof enough for me!

Over the next couple of decades, things would get much better, well beyond the wildest imaginations of Paul and Joe. Their little company would become the #1 player in a big market - radios. Car radios, home radios, two-way radios, you name it - they owned it. In 1950, they totaled sales worth $177 million - no chump change, even in today's dollars. Then disaster struck.

Actually it didn't (But saying "Then disaster struck" is good way to end a paragraph. Yes, I read that in a book too!). Paul and Joe's outfit was really just getting started. Over the next 40 years, it would become one of America's largest and most successful companies - booking a revenue of $11 billion (with a "B") in 1990 and going onto capture the #1 market share by the latter part of that decade in a hot market - cellphones. Then disaster struck. Really, it did.

Between then and the middle of the current decade, Galvin Manufacturing Corporation (now known by the name of its first car radio product - "Motorola") would steadily lose market share to a startup from Finland - and would go from more than 150,000 employees to about one-third of that.

Success by Ignoring Market Research?
In 2003, in the midst of seemingly never-ending market share loss to Nokia, a veteran engineer named Roger Jellicoe would embark on a "top secret" project guided by an executive named Rob Shaddock. This project would change the fates of Motorola - for the better.

A team of 20 engineers led by Jellicoe worked under secrecy - not revealing the project to carrier partners, industry analysts and even their own colleagues. Their mission was to create the "thinnest phone" possible. The team designed it painstakingly, overcoming many obstacles and poring over minor details. All the while Jellicoe and Shaddock practically lived with the various prototypes of the phone and provided constant feedback.

In the fourth quarter of 2004, the team launched their phone - the RAZR. Within the next two years, RAZR would go on to sell 50 million units and become the best selling cellphone. To put things in perspective - Ed Zander, the CEO of Motorola, recently said:

We'll sell more RAZRs this year than Apple will iPods.

You may be thinking - "Well Michael, that is a good story - but how is it relevant to the subject of this article i.e. Market Research?" Great question and good timing, let us get to that pronto.

See, the whiz-bang team that created RAZR decided to intentionally violate a couple of key Motorola market research data - data that were simply not violated in their company:

1. Motorola's market research had concluded that phones cannot be wider than 49 millimeters, because they wouldn't fit well in a person's hand. No team in Motorola made phones wider than 49 millimeters.

   The RAZR, whose goal was to be the "thinnest phone", ended up being 53 millimeters wide.

2. Motorola market research team also said that customers would object to the "side keys" being in the top half of the phone (see image below) - instead of the bottom half as in all the other phones Motorola made.

The RAZR team successfully argued and convinced the powers-that-be at Motorola that they should launch the phone even though it didn't meet these important "market research" criteria. Because based on their own testing as users, they had found it worked very well.

Hindsight is indeed 20/20 - and it says the RAZR team was right and the market research was not-so-right. What can those of us in Product Management and Product Marketing learn from this? Do I hear "With a carefully picked story, we can prove anything we want"? Okay, that was very smart of you - but what else can we learn?

Market Research is Not Inviolable
In order to create commercially successful innovations, we must deeply understand customer needs and preferences by observing them using our products in real life. Even better, by putting ourselves in their shoes and walking the proverbial mile - or two, or ten. As the RAZR team did.

Based on this insight, we should define innovative products. In doing so, if we run afoul of formal market research data - so be it, as long as we're convinced that customers' needs and preferences are being met. We should be confident enough to make our case to the powers-that-be why we should be allowed to go forward with our plan. After all Shaddock, Jellicoe and their team did. Look where it got their company!

Here is to better products, and more success...

P.S. Check out this excellent Fortune article by Adam Lashinsky for a detailed story on how the RAZR came to be.

What are your thoughts and comments on this topic? Let the world know what you think by clicking on the 'Post Comment' link below!

Posted by michael at 11:18 PM | Permalink | TrackBacks (0) | 8 Comments | Post Comment

Welcome to the first article in a series I'll be writing titled Sun Tzu on Product Strategy.

Okay, the first question you may have is "Who in the world is Sun Tzu?". Let me start by answering that. First, Sun Tzu was *not* a sissy - in spite of what this book claims! He was a 6th century, BC Chinese military strategist who wrote a very influential book called The Art of War.

The next question you may have is "Why should we care about his thoughts on product strategy?". Fair enough. While his book was about ancient military warfare, the ideas in it have been found to be eminently applicable in many modern endeavors including business, government, and yes even 21st century military combat. In this series, I will highlight what we can learn about product strategy from the ideas in The Art of War.

The next question you may have is... Wait a minute, that is enough questions for now - let us move on to the article, shall we?!

Strength Against Weakness - Always
Sun Tzu says:

His offensive will be irresistible if he plunges in the enemy's weak points... Avoid that which is strong and attack that which is weak.

What can those of us in Product Management and Product Marketing learn from this? Many things, actually. But I'm going to focus on one thing in particular. Let us start with a fictional example. (Disclaimer: Any similarities to actual companies is purely coincidental - and may not be that hard to find!)

SuperDuper, TotallyCool & Integrated-Bug-Tracker
SuperDuperCRM and TotallyCoolCRM are two companies that make customer relationship management (CRM) software. Their software is used by sales reps in medium-sized companies to keep track of data on customers and prospective customers.

One fine day, SuperDuperCRM decides to build a new feature for its next release - an integrated Bug Tracker. Why did they decide this, you ask? May be their CTO thought of it while he was taking an aromatic Eucalyptus steam bath in a spa resort in Palm Springs!

In any case, SuperDuperCRM builds this Bug Tracker feature and releases it with much fanfare - including a big trade show booth with a giant poster of a ladybug, full-page magazine ads and reviews in trade magazines (same ones that ran the full-page ads!).

Now - this feature was never really requested by any customers. While sales reps (the end users of SuperDuperCRM) do many things - such as dine at expensive restaurants, go to Las Vegas for monthly meetings, go on Pebble Beach golf outings, and yes even sell software - they just don't do bug tracking. So no one really buys this integrated Bug Tracker despite the aggressive sales pitches by SuperDuper.

Meanwhile the sales reps at TotallyCoolCRM have been antsy ever since they saw the press release that pre-announced SuperDuperCRM's integrated Bug Tracker feature. They immediately asked Cathy, the product manager at TotallyCoolCRM, to add this feature in the next release.

Cathy was initially reluctant - but changed her mind when several sales reps complained that they're losing deals to SuperDuper because their product didn't have this feature. It is not really true - but they feel much better walking into a meeting with a prospective customer and proclaiming "We do everything they do, only better and cheaper". As you know, Sun Tzu wouldn't agree with this strategy of strength against strength.

The next quarter TotallyCool makes a big press release announcing its own integrated Bug Tracker. The other competitors look at this - and figure there must be a need after all since two companies in their space have built it. So they build it into their products too.

Eventually the vendors find out that the customers really don't want this feature. As a result, these days the vendors just bundle it for free with their CRM software. By the way, now they're all focusing on integrating to Google SketchUp. This brings us to 'Michael's Product Strategy Rule #1'.

Michael's "Product Strategy Rule" #1

Don't mindlessly copy features that competitive products have. Focus instead on features that competitive products don't have, but customers need.

Instead of copying features of competitive products to compete head on against them - strength against strength - take the road less traveled.

Only consider those features that the customers ask for and/or need. Among those features, give the highest priority to those features that customers really need, but competitors don't have. That is - "avoid that which is strong and attack that which is weak".

Here is to better products, and more success...

What are your thoughts and comments on this topic? Let the world know what you think by clicking on the 'Post Comment' link below!

Posted by michael at 06:02 PM | Permalink | TrackBacks (0) | 13 Comments | Post Comment

In my previous blog entry titled 10 Tips for Writing Better MRDs - Part 1 - I covered five tips for writing better MRDs. I know you've been waiting with bated breath for the next five tips. Wait no more, I've covered them below!

Here, I use "MRD" to collectively refer to all documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

If you haven't read the first five tips yet, please read them first. I will wait here. Okay, you are ready?

Here are tips 6 through 10.

6. Specify What & Why - But Not How

   Product managers are responsible for understanding customer needs, and using this understanding to define what should be developed and why.
   
   The one thing, more than anything else, that causes developers to get mad with steam flowing out of their ears so fast that the accompanying whistle can be heard miles way - is an MRD that specifies *HOW* to implement each and every requirement in excruciating detail.
   
   Consider the following two approaches for specifying "Login" functionality for a customer relationship management (CRM) software that your company is developing.
   
   

   ---

   
   Recommended - Specifying *What*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - our software will remember and auto-fill his username the next time he comes to the login screen.
   
   Not Recommended - Specifying *How*:
   Mike is a sales manager. When he opens our CRM software, he sees the login screen. (...) The login screen also provides a "Remember me" checkbox. If Mike checks this checkbox before clicking the 'Login' button - a cookie will be written to his PC hard-drive using Javascript to save his username. Username/password will be sent to server only after this cookie is written to the PC hard-drive. The next time Mike comes to the login screen, Javascript will be used to read his cookie. After successfully reading it, Javascript will use the appropriate DOM command to prefill the username in the login screen.
   
   

   ---

   
   Just as good product managers are experts at understanding customer needs and specifying what needs to be done, good engineers are experts at deciding how to achieve it. Good engineers want the freedom to decide the best how to achieve the desired what.
   
   I've noticed that product managers with technical background are especially guilty of specifying how. If this describes you - just say no to it from now on. Engineers will thank you.
   
   P.S. There are some rare exceptions to this rule - instances where it is necessary to specify how along with what, as the best and/or the only specification of what in these instances is the how.

7. Cover Non-Functional Requirements

   Whereas "Functional" requirements specify the features of the product, "Non-Functional" requirements specify system characteristics such as:
   
   a) Performance
   b) Scalability
   c) Availability
   d) Internationalization
   e) etc...
   
   I've noticed that these are often omitted from MRDs as many product managers and product marketers consider these "technical details". I've found these to be very important part of my MRDs and engineers have really appreciated these requirements being defined in MRDs.
   
   Important: When writing non-functional requirements, make them easily measurable (testable) whenever possible. Otherwise, QA cannot test it and you will have no way of knowing whether the finished product meets these specifications or not.

   

8. Review & Update

   I have a friend - we will call him Matt (his real name is Steve). Matt works as a product manager at a successful company in the valley. He had an interesting story to tell when I met him for lunch recently.
   
   They had hired a new product manager with about three years experience. Within a few months of being hired, he had somehow managed to alienate many of his fellow product managers as well as engineers.
   
   His crime? He basically considered his MRDs to be sort of like decrees. He wrote them, but did not want to review with anyone or modify it based on feedback. He just wanted the engineering team to take it and implement it without asking any questions!
   
   Don't be like Matt's coworker. Make sure to review your MRD with your fellow product managers and the development team. Keep an open mind and update the MRD based on the feedback in these reviews. This will help you create better MRDs, engineers will like you more (or at least hate you a lot less!), and your team will create better products.

9. Define Target Market & Positioning

Most MRDs I've seen do a pretty good job of covering the Target Market (who will buy and use your product) and Positioning (how your product will be positioned versus competing products).

I have seen some MRDs that don't and the argument that I usually hear in these cases is along the lines of: "Why do engineers need to know this? Isn't defining what needs to be done enough?"

While that question certainly has some face value, I've found that many engineers want to know why a certain product or feature is being developed, who will be using it and what are their alternatives.

This information helps them and other members of the product team visualize the end users and as a result do a better job of creating winning products. My suggestion is to include this information whenever possible - it doesn't have to be very detailed, just a couple of paragraphs will suffice.

Like This Article?

Why not share it with friends and colleagues? Just click here...

10. Include a Glossary

    If your MRD uses new terms or common terms in an uncommon way - make sure to include a Glossary at the end.
    
    This will help ensure all of your readers (some of whom may not be technical) understand what you mean when you say things like "Our software will provide SME users the option to be billed a MRC via WAP or PSMS".

There you have it - tips 6-10 of my ten tips for writing better MRDs. I've shown the entire list below for easy reference as well:

1. Write From User's Perspective
2. Use Screen Shots
3. Write Using Simple Language
4. Use Templates - But With Care
5. Prioritize Requirements
6. Specify What & Why - But Not How
7. Cover Non-Functional Requirements
8. Review & Update
9. Define Target Market & Positioning
10. Include a Glossary

Here is to better MRDs, better products, and more success...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 08:31 PM | Permalink | TrackBacks (0) | 6 Comments | Post Comment

An MRD – "Market Requirements Document", is a document written by Product Managers or Product Marketing Managers to specify the requirements that a product must meet. This document is used to propose a new product or to revise an existing product. It is used by the engineering team to develop the product.

At some software companies in Silicon Valley, MRD only covers high-level features. In such cases, product managers create another document - usually referred to as PRD (Product Requirements Document) to define more detailed product requirements.

In this article, I use the term "MRD" to collectively refer to all such documents created by product management and/or product marketing teams for the purpose of conveying product requirements to engineering team.

Ten Tips for Writing Better MRDs (Part 1)

1. Write From User's Perspective

   Write requirements from the perspective of users. Make use of 'Use Cases' and 'User Personas' to achieve this. Consider the following two approaches for specifying "Login" functionality for a sales force automation (SFA) software that your company is developing.
   
   

   ---

   
   Approach "A":
   Software shall allow users with privileges to log into the system through a login screen which shall ask the user to provide credentials to login. Software shall authenticate these credentials and upon authentication shall permit the users to access sections of the software that they have access privileges for.
   
   Approach "B":
   Mike is a sales manager and Cathy is a sales rep. When they open the software, they see the login screen. They enter username and password in this screen. If the username/password is correct, they are able to log in. Once logged in, Mike can access all sections of the software. Cathy can only access those sections of the software available for sales reps.
   
   

   ---

   
   Which approach is easier to read and understand? In my opinion, without any doubt, "Approach B". Plus, it is also much less boring to read!

2. Use Screen Shots

   Use screen shots or mockups to explain what you mean. Most of us have heard the saying "A picture is worth a thousand words". When it comes to writing MRDs, a screen shot is worth a thousand words!
   
   For example, look at the following screen shot - how many words do you need to describe this? I'd guess probably more than a thousand.

   

3. Write Using Simple Language

   One thing I've noticed often (much to my chagrin!) during my 11+ years in the industry are MRDs that use a very contrived language. I think this is primarily caused by the misconception that MRDs need to sound formal and professional.
   
   Instead, imagine that you're writing the MRD for your friend who works in the engineering team. Your goal is to help him understand what you need so that he can develop the product to meet those needs. This will help you avoid falling into the trap of contrived language that turns off the readers - sometimes to the point where they shred your MRD and feed the shreds through the shredder again!
   
   Plus:
   a) Keep sentences short. Break up long sentences into smaller ones.
   b) Avoid large blocks of text. Break them into smaller paragraphs.
   c) Break up large bodies of text with screen shots, tables, bulleted lists, etc.

4. Use Templates - But With Care



I've found MRD Templates to be very useful. They offer several benefits including:

a) Templates provide a standard format that makes it easier for readers who have to read multiple MRDs.
b) Templates make it is easier to bring new product managers up to speed in writing MRDs - as MRD contents vary from company to company.
c) Templates help ensure you don't forget to cover all aspects that need to be covered in MRDs.

However, some companies go way overboard in using templates. One of the largest companies in Silicon Valley has a template that runs about 60 pages and in which all sections are mandatory. I've heard that it feels very oppressive and has several negative effects:

a) Product managers dread having to write MRDs - almost as much as having to go on a south Texas quail hunting trip with Dick Cheney!
b) Engineering teams dread having to read MRDs.
c) It takes a long time to write as well as read the MRDs.

I recommend you to use MRD templates, but make sure they're not overly long. Plus make sure that the product managers have the leeway to skip sections that are not applicable and to create new ones if needed.

Like This Article?

Why not share it with friends and colleagues? Just click here...

5. Prioritize Requirements

   In all these years, I've never worked on a full-scale project where the engineering team was able to implement all the features that were included in an MRD - often due to factors beyond the control of any of us!
   
   This means product managers, as MRD authors, should provide a way to help the engineering team decide which features to implement and which to defer when the need arises to make this determination.
   
   This is best achieved by prioritizing the requirements. I've found that classifying requirements into categories like P1, P2, P3... works just fine. In this categorization - P1 is the highest priority, P2 is the next highest and so on.
   
   The best way to decide the priority of a given requirement is the benefit of implementing that requirement - both to your customers and your company. In practice, other factors come into play as well.
   
   I recommend that you only include P1, P2 and P3 requirements in your MRDs, as lower priorities are unlikely to get done in most projects anyway. Plus it makes the MRD easier to read.

There you have it - the first five of my ten tips for writing better MRDs. I'll cover the rest of the tips in my next article. Until then...

Like this article? Then you will love my FREE monthly email newsletter - loaded with useful information for Product Management & Product Marketing professionals. It is FREE - get it now!

Posted by michael at 09:35 PM | Permalink | TrackBacks (0) | 5 Comments | Post Comment

Rudyard Kipling was a popular author and poet who lived during the turn of the 20th century. Born in India to British parents in 1865, he would go on to win the Nobel Prize for Literature in 1907. This author of The Jungle Book couldn't have known much about High-Tech Product Marketing, could he?

Come Again, Please?!
In my previous blog article titled Product Management & Product Marketing - A Definition, I defined Product Marketing as:

Product Marketing refers to the activities of outbound messaging - telling the world about your product. This includes creating collateral such as datasheets, brochures, website, flash presentations, press packages, trade shows and more.

One of my pet peeves is that most high-tech companies come up way short when it comes to effective outbound product messaging. Often their product descriptions - as seen on their website, datasheets or brochures - are so vague that most readers will be hard pressed to make much sense out of them.

The following is a slightly edited product message that I got from the website of a software company I recently came across. This is the text they led off with, I've removed the actual product name.

<Product Name>, the industry's first integrated planning and delivery solution that spans the entire lifecycle: from strategy to plans, from plans to launch, and from launch to re-generation. With <Product Name>, product and service companies can break free of spreadsheet gymnastics, stop making ad hoc decisions in hallway meetings, and take control of planning and development – with dramatic results.

After reading this passage, do you know what the product actually does? Who it is targeted at? Why you should get