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) | 8 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 it?

Rudyard Kipling to the Rescue!
Kipling couldn't have known much about the high-tech industry - the first Model-T car wouldn't be sold until a year after he won his Nobel Prize, and the color television wouldn't even be invented during his lifetime!

However, one of Kipling's poems is very educational in creating effective product messaging for high-tech products. He writes:

I keep six faithful serving men
Who teach me well and true
Their names are What and Where and When
And How and Why and Who.

When creating your product message, put Kipling's "six faithful serving men" to good work. They will help improve and sharpen your product message:

1. "Who" Are You Marketing To?

   While creating your product message, first clearly identify who you're marketing to. Then write your message for this audience. Don't write a message that tries to appeal to everyone - it is highly likely it will end up appealing to no one.

2. "What" Does Your Product Do For Them?

   Tell your target audience what your product does for them in plain English. Do not use jargons or unnecessarily complex language - many B2B software companies are especially guilty of this.

3. "Why" Is Your Product Better Than Other Solutions?

   Odds are your audience has several other means to achieve the same thing that your product does. Tell them why your product is better. Why they should consider your product instead of the other solutions.

4. "How" Can You Prove Your Points?

Provide concrete, tangible information that proves your points about what your product does and why your product is better. Often companies make vague statements that cannot be proven. Instead, use concrete data - such as customer testimonials, success stories, third party surveys, etc.

5. "Where" and "When" Is This Message Being Delivered?

   When creating your product message, take into account where and when the message will be delivered to your target audience. For example - a message on your website will be delivered to any visitor to your site, whereas a message in a direct mail will only reach the intended audience during the intended timeframe. Tailor your message accordingly.

There you have it. Get as friendly with these faithful serving men as you can and lean on them to help make your product message clearer and more effective!

Until next time...

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

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

This morning I got an email from a friend of mine who is in the venture capital business. It had an attachment to a very interesting article in the April 2006 edition of Business 2.0 magazine.

In that article titled "Simple Minds", the author Paul Kedrosky criticizes what he calls the "Simplicity Cult" and makes a case that, in general, products should have more features, not less.

Paul on "Simplicity Cult" & "More is More"
In his article, Paul says that the "simplicity cult" has been made more powerful by three "coincident market and technology forces":

1. Most people use only a fraction of the features of their software. For example, an average Microsoft Word user uses only about 10% of its features.
2. We're all overloaded with information and "pessimists think... (we) need someone to take the info-candy away".
3. iPod has made playing songs so simple and easy that the "cult" wants everyone to simplify their products.

Then Paul gives the example of airbags in cars which he correctly points out as a feature that "most people will... never once" use. Then he wonders why the "simplicity goons" aren't going after airbags!

He says: "What we learn from airbags... is that the solution isn't to eliminate features from products... The solution is to have more features... in ways that are less intrusive and more carefully prioritized".

Paul concludes:

The current obsession with simplicity... (is) built on at least one false premise, that less is more. More is more, and it always has been and always will be. [emphasis added]

Kathy on "Happy User Peak" & "Featuritis"
Paul's article got me thinking. I've believed for some years now that simpler is better - in almost all cases. Did I have it wrong? Is it time to revisit my belief system?!

Finding myself paralyzed with this almost metaphysical question, I did what any self-respecting Silicon Valley techie would do... I Googled it! To be technically correct - I searched in Yahoo 'My Web' where I keep an electronic copy of all the good articles & blogs I read.

In a few short seconds, the Gods who reside in Yahoo's servers found the answer for me! It was in a blog article by Kathy Sierra - one of my favorite bloggers - titled Featuritis vs. the Happy User Peak.

In it Kathy shows a totally cool chart which I have reproduced below (Many thanks to Kathy, chart reproduced under Creative Commons license by-nc-sa-2.5):

This chart is one of those cases where I feel that the saying "A picture is worth a thousand words" is totally true! In her blog, Kathy argues that all too often companies push their products too far past the "Happy User Peak", driven by fear:

1. Fear of being perceived as having fewer features than their competitors.
2. Fear that their products won't be viewed as complete.
3. Fear that customers are making purchase decisions off of a checklist, and that the product with the most features wins.
4. Fear of losing key customers who say, "If you don't add THIS feature... I'll have to go elsewhere."

Kathy concludes by saying:

Be brave. And besides, continuing to pile on new features eventually leads to an endless downhill slide toward poor usability and maintenance. A negative spiral of incremental improvements. Fighting and clawing for market share by competing solely on features is an unhealthy, unsustainable, and unfun way to live.

My Take on Simplicity
After reading Kathy's article and thinking some more, I felt more at ease! No need to change my belief system just yet. But I did remind myself of something important.

It is very important to first understand customer needs and then create a product that meets those needs in an easy-to-use fashion. For example, say you had learned your customers need a Swiss Army knife with a blade, nail file and scissors. Which product is better: The one shown below? Or the one at the top of this article - it has all three features and many more?

Now what if you had learned that your customers need a blade, nail file and corkscrew? Which one would you sell to them? Or would you design a brand new product?

Simpler is indeed better, as long as your product meets your customers' core needs. You may lose some customers because you don't have some non-core features, but in most cases - I believe - that loss will be more than made up by those customers you gain since your product is simple, easy to use and yet meets their core needs.

Let me conclude by quoting Kathy:

Give users what they actually want... And whatever you do, don't give them new features just because your competitors have them!

Be the "I Rule" product, not the "This thing I bought does everything, but I suck!" product. (See chart above)

I could not put it any better!

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

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

In my 11+ years in the high-tech industry, the least well-defined job that I have come across is that of the... drum roll please... 'Product Manager' (and the closely associated role of 'Product Marketing Manager'). The role of a Product Manager (PM) varies quite widely across different segments in the high-tech industry, and even across different companies in the same segment.

In this article, I'll try to shed some light on the role of a PM by summarizing their major responsibilities. But, first an anecdote!

It Is What You Define It Is!
About a year ago, I interviewed at a startup that makes software in the 'human resources' field - let us call them Scooby-Doo, Inc (not their real name!). They were looking to hire someone who can build their product management team. The two founders were the Chief Technology Officer (CTO) and VP of Engineering. They had secured about $10 Million in funding from two venture capitalists in Silicon Valley just a couple of weeks earlier.

I arrived on time at the well appointed offices of Scooby-Doo, Inc. First up was the CTO, a very pleasant guy dressed in Scooby-Doo T-Shirt, shorts and funky sandals! During the interview, I asked him what was the main reason he wanted to build a product management team.

He said he wanted someone to document all the features in their product (which had already been created) in one Word document so that they can understand what features were in their product. He also said he didn't want the PM team to "muck around with defining features or product strategy" because between him and the VP of Engineering, they had it covered.

Next up was the VP of Engineering. I asked him the same question - "What is the biggest reason you want to build a product management team?". He told me that he wanted someone to create UML diagrams of the current product as well as for all the new features that he planned to come up with so that developers could implement them.

What Do Product Managers Do?
While the role of a PM varies widely depending on the company, there are several key responsibilities that product managers usually undertake at a vast majority of successful high-tech companies - based on my own experiences as well as conversations with friends in the industry. I've grouped them into the following six categories:

1. Market Research:

   This refers to the activities of studying a market to understand the customer needs, competitive landscape, and market forces - with the ultimate goal of uncovering opportunities for creating product enhancements as well as new products.

   This is done via conversations with customers or potential customers, talking to customer-facing teams such as sales and support, studying reports and articles on the marketplace, test driving competitive products, keeping tabs on customer behavior, and other such activities.

   This culminates with the PM preparing a business case, product strategy and/or business requirements document (BRD) detailing how to capitalize on the uncovered opportunities.

2. Product Definition and Design:

   a) Product Definition refers to the activities of specifying what a product needs to do. This is usually done via what is referred to as Market Requirements Document (MRD) or Product Requirements Document (PRD). This document may include information such as product vision, target market, competitive summary, detailed description of product features, prioritization of features, use cases, system requirements, performance requirements, sales and support requirements, etc.

   b) Product Design refers to the activities of specifying the look and feel of the product including the user interface (UI) and the user interaction with the product - covering the whole spectrum of user experience. In larger companies the PM works with UI designers or interaction designers to create this, while in startups the PM may do all of these.

   I consider this to be the most valuable among a PM's activities - so much so that I actually think product manager jobs which don't include this responsibility are really not product manager jobs at all!

3. Project Management:

   This refers to the activities of leading cross-functional teams including engineering, QA, UI design, marketing, sales and support to develop and launch the product on-time and on-budget. This may include securing resources, creating project timelines, tracking progress against timeline, identifying critical paths, getting additional resources when needed, and communicating status to the executive team.

   In larger companies, Project Managers actually perform most of these activities with the support of PM's. In very small startups, the PM may be asked to do these by herself. In some companies, the Engineering Lead may do most of these activities as well.

   

4. Evangelizing the Product:

This includes the activities of communicating the product benefits, features and target markets, and in general championing the product to internal teams such as sales, marketing, support and executives. This also includes evangelizing the product to external audience such as press, analysts and customers.

In larger companies, the PM is supported by the Product Marketing, Marketing Communications (MarCom) and/or Press Relations (PR) teams in evangelizing to external audience.

I consider this to be the second most valuable among a PM's activities - especially evangelizing to the sales & marketing teams, and the executives to create excitement around the product.

5. Product Marketing:

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

   In larger companies, the product marketing activities are almost always separated from the PM. They're instead performed by the Product Marketing Manager. The biggest shortcoming of this arrangement is the resultant inefficiencies in communication and the weakening of outbound messaging.

   In some companies the terms 'Product Management' and 'Product Marketing' are used synonymously and one person is responsible for all activities. In companies where there are separate 'Product Management' and 'Product Marketing' groups, the latter group performs all the activities mentioned in this category. They may also perform some of the activities in categories 1, 4 and 6.

6. Product Life Cycle Management:

   This refers to the activities of managing a product as it goes through its life cycle from ideation to launch to growth to maturity, and eventually to decline.

   This includes tasks such as product positioning, pricing and promotion, product portfolio management, competitive strategy, making build/buy/partner decisions, and identifying and developing partnerships. The PM works with Product Marketing, Business Development and MarCom teams on many of these activities.

There you have it - my attempt at demystifying the role of product management (and the associated role of product marketing). I hope this helps product managers and product marketers as well as those who work with them - including a certain friendly CTO who likes cartoon T-Shirts!

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:45 PM | Permalink | TrackBacks (0) | 21 Comments | Post Comment

This company has achieved 32 consecutive years of profitability in an industry that regularly loses billions of dollars. It is valued higher than all of its major competitors combined. While its competitors go bankrupt with alarming regularity, this company keeps on growing. Can you guess which company we're talking about?

This Is No Peanuts!
More than 34 years ago, in Texas, two guys named Rollin King and Herb Kelleher decided to start an airline. They began with a simple idea: If they get their passengers to their destinations on time, at the lowest possible fare - people will fly their airline.

What began as their little Texas airline has grown to become one of the largest and certainly the most successful airline in the U.S. They have reinvented the way an airline business is operated with innovations such as point-to-point flights, no assigned seatings, high-frequency/short-haul routes - and of course, the famous peanuts instead of meals!

In 1992, Southwest became the first airline in history to win the annual Triple Crown - Best On-time Record, Best Baggage Handling, and Fewest Customer Complaints - a feat no other airline had been able to match in a single month! Since then, they have won the annual Triple Crown many more times. But that is not all.

In the last year, Southwest achieved bottom-line profits of more than US$500 million - this was higher than the combined profits of all the major carriers in the entire airline industry in the U.S. Surely, this is no peanuts!

What Can We Learn From Southwest?
I believe Southwest Airlines has a lot to teach product management and product marketing professionals in the high-tech industry. The top three lessons, in my opinion, are:

1. Think Different:
• In an industry where every major airline operated in the hub-and-spoke model, Southwest went with the point-to-point model. While all the major carriers used assigned seating and preferred long-haul routes, Southwest again went against the grain. In a nutshell, Southwest dared to think different to provide unique value to their customers.
• Lesson:
  • Don't just settle for an established way of doing things - whether it is feature set or pricing models.
  • Don't fall for "That is the way every one in our industry does it".
  • Find a different, better way and provide unique value to your target market - a value that will create loyal customers.
2. Focus - Do One Thing Well:
• Southwest's express goal is to be the leading shorthaul, low-fare, high-frequency carrier in America. They have a laser focus on achieving that goal and don't get distracted by trying to be all things to all people. They are willing to sacrifice those travelers (including some of my friends!) who will never fly Southwest since they prefer assigned seatings, first class section, full meals, etc.
• Lesson:
  • Carefully pick a well-defined target market for your product and a compelling value proposition for that target market.
  • Then focus on delivering that value for that market. Don't get distracted by trying to be all things to all people - usually resulting in feature bloat, confusing product messaging, etc.
3. Teamwork:
• Kelleher says his days playing high school football and basketball taught him how a team should work.

If you play football, you don't say to the tackle, 'That's your territory, I'm not going to make that tackle.' Teams don't function effectively under those circumstances - Team play is a fundamental concept, and playing team sports brings that home to you very strongly. If you want to succeed, if you want to win, you have to play as a team.

• Lesson:
  • In most companies, a key responsibility of Product Management and Product Marketing is to lead cross-functional product teams. Make it a high priority to create and foster team spirit in your product teams by clearly communicating the product vision and getting buy-in from every one.
  • Lead by example by assisting in areas outside your normal job functions whenever possible.

Flying In The Face of Conventional Wisdom
Southwest has achieved incredible success by focusing on seemingly simple goals - but many of which go against the so-called "conventional wisdom". Kelleher says:

The... thing that was important was not accepting the conventional wisdom that it wouldn't work. I think probably only one in four people in Texas thought Southwest had a chance of flying, much less of being successful. I say, 'If it's conventional, it ain't wisdom, and if it's wisdom, it's not conventional.' (emphasis added)

Don't fall prey to the conventional wisdom in your own marketplace - ignore comments like "But all our competitors have those features" or "But that is the only pricing model in our industry ". Think unconventionally to find ways to set your products apart and achieve success in your marketplace.

When you do achieve this success, go ahead and treat yourself to some Wild Turkey, Kelleher's most favorite drink - and send me a bottle too!

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

About a year ago, I had the pleasure of attending a speech by Scott Cook, the founder of Intuit and one of the best business minds in Silicon Valley. During his speech, Scott discussed what he called "the best barrier-to-entry" that any company can have - something that results in the most powerful competitive advantage. Can you guess what it is?

eBay Has It. But Not Google!
It is something eBay has but Google doesn't - any guesses yet?!

Scott was talking about "Network Effect". This is a term that was grossly misused by many dotcoms during the boom days of late nineties. What exactly is "Network Effect" then?

Network Effect is the phenomenon whereby a product or service becomes more valuable as more people use it, thus encouraging ever-increasing numbers of users.

According to Metcalfe's law, the total value of a product/service that possesses a network effect is roughly proportional to the square of the number of customers already using that product/service.

How eBay Benefits From Network Effect
eBay's online auction marketplace is a great example of a service that benefits from network effect.

• As more and more buyers use eBay's auction marketplace, the value of the marketplace increases for sellers...
• causing more sellers to join which in turn increases its value for buyers...
• causing even more buyers to join...
• and so on...

When a competitor starts a new online auction marketplace, it is very hard to break the dominance of the incumbent. Reason: In the beginning, there are few buyers in the new marketplace - as a result of which few sellers join which in turn discourages even more buyers.

A proof of this plays out in almost every mature internet market today. Whether it is the US, Japan or Germany - one company has the dominant share of the online auctions marketplace, while all others lag far behind.

In the U.S., even when competitors like Yahoo make their auctions free - they still cannot make much of a dent in eBay's dominance despite the fact that eBay itself is raising prices! Network effect can be that powerful.

How Common Is Network Effect?
Although many of the now defunct dotcoms claimed to create network effects, network effect is not very common. Some products/services naturally lend themselves to network effects, while most do not.

The products/services that have inherent network effects usually fall into one of these categories:

• Marketplaces & Trading Exchanges:
• Physical/virtual gathering places and exchanges that enable buyers and sellers to come together and engage in trade
• Examples: eBay, Paypal, New York Stock Exchange, NASDAQ
• Platforms & Standards:
  • Frameworks upon which multiple vendors in a marketplace create products to ensure compatibility and interoperability
  • Examples: Microsoft Windows, CDMA, DVD
• Communication Tools:
• Tools that enable one person to communicate with another person who has the same tool
• Examples: AOL Instant Messenger, Skype, Microsoft Word, Adobe PDF
• Social Networking (Community) Applications:
• Tools that enable friends, business partners, or other individuals to connect and/or share information over the Internet
• Examples: LinkedIn, Friendster, Flickr, Del.icio.us

Most of the other products/services do not have network effects. An online portal doesn't create "Network Effect" by acquiring eyeballs - this was one of the popular (and incorrect) claims by dotcoms. I don't gain more value from Yahoo.com just because more and more people use it.

A search engine doesn't have network effect either - again I don't get any more value from using Yahoo Search just because many others also use it. I believe this is one of the major reasons Google was able to so easily take away Yahoo's leadership in online search.

Likewise, I don't believe Google Search itself possesses any network effect today. If a new entrant provides a significantly better search experience than Google - I believe that they can, over time, take the market leadership away from Google.

Can You Build Network Effect For Your Products?
In his interview with HBS in 2001, Scott Cook says:

I also think that a fundamental understanding of network effects is very important. ... Network effects are a fundamental characteristic of certain technology businesses. When network effects are possible, it is the most important thing in the world to follow, to understand, and to make happen. (emphasis added)

While not all products/services lend themselves to network effects, analyze your products and services thoroughly and often to see whether you can build features that result in network effects similar to the products/services in the examples above.

If you're able identify any such possibilities, make it the the most important thing in the world for your Product Management and Product Marketing teams "to follow, to understand and to make happen". You will be glad you did.

When you hit it big by doing this, don't thank me - just send money! :)

Until next time...

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:51 PM | Permalink | TrackBacks (0) | 12 Comments | Post Comment

Intuit is one of the very few desktop software companies to stare down Microsoft at high noon with guns blazing, and live to tell their story. They went head-to-head against Microsoft on three of their flagship products and beat them resoundingly all three times! Quicken beat Microsoft Money, QuickBooks beat Microsoft Profit, and TurboTax beat Microsoft TaxSaver.

How did they do it? I was recently re-reading Inside Intuit, an excellent book by Suzanne Taylor and Kathy Schroeder that chronicles the exciting and educational story of Intuit.

Intuit Had The 47th Mover Advantage!
In that book the authors recount a joke by the founder of Intuit, Scott Cook, who says that they had the 47th mover advantage in their category ('personal finance' software) when they launched Quicken in 1984! That is, there were 46 other vendors selling personal finance software largely similar to Quicken in functionality.

"First-mover advantage" is a term widely used in the high-tech industry, especially by those in product management and marketing. This advantage is often presented as one of the most worthwhile goals to shoot for.

The pitch goes something along the lines of - "By releasing product (or feature) XYZ by Q2 of 2006 we will achieve the first-mover advantage. This will enable us to capture the largest market share, tie up partnerships, erect huge barriers to entry and leave the competitors in the dust...".

That sounds reasonable, right?

Who Made the First Commercial PC?
Yet, the annals of high-tech history contain remarkably few companies which translated their first-mover advantage into long-term dominance in the marketplace. Let us look at a few examples.

Do you know which companies launched the first commercial versions of:

• Personal computer,
• Word processing software,
• Web browser, and
• Internet search engine

Today, none of them is the market leader in those categories or even anywhere near the top - despite the fact that all these products were introduced just 15 to 30 years ago.

(In case you're curious which companies were the first-to-market in these categories, please see the bottom of this article.)

How Intuit Succeeded & You Can Too?
A question arises naturally: If being the first-mover in a category can't get you market leadership, then what can? How did Intuit do it?

In Inside Intuit, Taylor and Schroeder recount in detail how Intuit made Quicken into a big success in spite of being the 47th entrant in its category, and how it has since replicated this success with QuickBooks and TurboTax as well. Boiled down to its essence:

Intuit has consistently and cleverly used customer insight to build its breakthrough products, customer service, and marketing communications.  Intuit pioneered customer research in the software industry with methods borrowed from Scott Cook's alma mater Procter & Gamble including: follow me home studies, usability research, and customer advisory panels. (emphasis added)

Customer-Driven Innovation = Success
Intuit has succeeded repeatedly by focusing maniacally on deeply understanding its customers and using that customer insight to innovate in products, customer service and marketing. What can you learn from this?

If your company is not the first entrant into a category - do not despair. Focus on customers, understand their needs deeply, and create products and services that meet those needs much better (in ways that matter to customers) than any of your competitors.

If you can do this repeatedly over time, odds are quite high that you will grab market share at the expense of most of your competitors. And may be even achieve dominance like the market leaders shown below!

First Movers vs Market Leaders

• Personal Computer:
  • First Mover: Altair (1975)
  • Market Leader: Dell (2006)
• Word Processing Software:
  • First Mover: WordStar (1979)
  • Market Leader: Microsoft Word (2006)
• Web Browser:
  • First Mover: Mosaic (1992)
  • Market Leader: Microsoft Internet Explorer (2006)
• Internet Search Engine:
  • First Mover: Excite (1993)
  • Market Leader: Google (2006)

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

Warren Buffett is the second-richest person in the world, just behind Bill Gates. He has built his wealth exclusively through his holding company Berkshire Hathaway - both by buying stocks in companies such as American Express & Coca Cola, and by buying outright companies such as GEICO, Business Wire and See's Candies.

When asked what is the most important characteristic he looks for in a business when assessing it, Buffett says it is:

...the competitive advantage of any given company and, above all, the durability of that advantage. The products or services that have wide, sustainable moats around them are the ones that deliver rewards... (emphasis added)

This brings us to the question for today: What is the biggest competitive advantage/differentiation of your company and its products or services? How durable is that?

How To Create Competitive Differentiation?
In their excellent book The Discipline of Market Leaders, Treacy & Wiersema say that there are primarily three ways in which a company can build competitive differentiation:

• Operational Excellence aka Cost Leadership
  • Provide middle-of-the-market products at the best price and the least hassle.
  • Example: Wal-Mart.
• Product Leadership
  • Provide the best product, period. Continue to innovate year after year.
  • Example: Intel, Nike.
• Customer Intimacy
  • Provide unique solutions to customers by virtue of intimate knowledge of their needs.
  • Example: IBM.

Treacy & Wiersema further argue that every company that is a leader in its market chooses to differentiate itself on one and only one of these three "value disciplines".

I believe this makes a lot of sense. For example, if a company tries to be the cost leader as well as the product leader in its market - over time, it will end up as neither.

Wal-Mart doesn't sell Armanis, Nike doesn't sell cheap shoes, and IBM sells neither the cheapest nor the best products.

How Durable Is Your Competitive Advantage?
While it is often hard to achieve, it is not enough just to have an advantage over your competitors. Even more important, as Buffett points out is the "the durability of that advantage".

If your company chooses to be a product leader, can you continue to innovate year after year in ways that matter to your customers? Can you continue to keep this leadership product cycle after product cycle?

Intel, for example, has sustained product leadership over a very long period by out-innovating competitors. Dell, likewise, has held cost leadership for the better part of the last two decades.

Differentiate or Die?
If your company's products are not differentiated in ways that really matter to your customers, your products may not necessarily die - but they certainly will be commoditized over time and at best will end up as also-ran products.

If you're in Product Management or Product Marketing - I highly recommend that you make one of your top goals this: Identify areas where your products can have strong, sustainable competitive differentiation and execute to make that the reality. This is one of the biggest values you can add to your company.

To conclude - I will leave you with the following simple, yet thought provoking questions from Treacy & Wiersema:

• What unique value do you provide to your customers?
• How will you increase that value next year?

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

In my last blog entry, I wrote about an excellent article by Geoffrey Moore titled "Top 10 Innovation Myths". In it, Moore says:

Innovation that leads to sustainable competitive advantage can be initiated and led by any organization in the company.

This brings us to the question: How is it done in your company?

Who Has the Keys to Innovation in Your Company?
In most high-tech companies, innovation is "assigned to" the R&D department. Is this the best way? Let us hear what Moore has to say about this:

In the first half of this decade, HP invested 15% in R&D and Dell invested 5% and cleaned their clock. How? They out-innovated them in process innovations led primarily by their operations folks. Innovation that leads to sustainable competitive advantage can be initiated and led by any organization in the company. R&D represents the engineering department's lead...

I agree with Moore. In every industry, even high-tech, there are several companies that have out-innovated competition in areas other than what would be traditionally considered R&D. Some examples:

• Dell innovated by creating direct-to-customer sales model for PCs
• IBM innovated by offering IT services custom-tailored for customers
• Intuit innovated by making personal finances easy for consumers
• Salesforce.com innovated via the on-demand business model for enterprise software
• And so on...

This means every organization in your company has the opportunity and the ability to innovate and create strong competitive differentiation.

What Role Should Product Management/Marketing Play in Innovation?
In most high-tech companies, the Product Management/Marketing team has the best view of the cross-functional processes of the organization - across Development, Marketing, Distribution, Operations, Sales and Support.

I think it is incumbent upon your Product Management/Marketing team to identify areas for innovation that create strong competitive differentiation and co-ordinate resources to make that innovation happen.

I'd go so far as to say innovation is the most important responsibility of Product Management/Marketing teams.

If your company is not innovating enough in areas that create strong competitive differentiation - take a long, honest look in the mirror. Then go out and make innovation happen in your company. YOU have the power.

P.S. If you think your department doesn't have any "formal authority" in your company to make innovation happen, ask yourself: "How much formal authority did Martin Luther King Jr., Mohandas Gandhi or Nelson Mandela have?" That always helps me!

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

I recently read a nice article by Geoffrey Moore titled "Top 10 Innovation Myths" after finding the link in Tyner Blain's blog.

Moore Says "No" to Innovation?!
One of Moore's points specifically caught my eye:

Myth-3. "It is good to innovate"
No, it is good to differentiate on an attribute that drives customer preference during buying decisions. Innovating elsewhere costs money and entails risk but does not create competitive advantage.

Reason it caught my eye? I had lunch with a friend of mine yesterday, he's a Product Manager at a medium sized software company in the valley. He was recounting a recent incidence at his company.

Their engineers wanted to do a project - which upon review by the Product Management team (standard practice at their company) was voted down. This caused the person who originally proposed the project to get a little bit mad and claim that they were killing innovation at their company.

Killing Innovation - Good or Bad?
When you vote down a project that has low/no commercial potential, are you killing innovation?

Technically speaking - yes, you're killing innovation. Is this good or bad then?

In my opinion, it is good to kill innovation that has no commercial potential. How so? I think, in most cases (though not 100% of the cases) it is fair to draw a conclusion that lack of commercial value means lack of real value created for customers.

Adding Customer Value via Innovation is Good
Innovation is only good when it creates real value for customers, especially value that they recognize and will pay for. When it does, odds are quite high that it will also be a commercial success. Even better when it also results in sustainable competitive differentiation.

Or as Moore says: "...it is good to differentiate on an attribute that drives customer preference during buying decisions. Innovating elsewhere costs money and entails risk but does not create competitive advantage"

Till next time...

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

In my previous blog entry, I discussed the issue of selling "Features" vs selling "Benefits". I used Socialtext and comments by its founder/CEO Ross Mayfield as a starting point. I'm thrilled to see all the great comments, thanks everyone for sharing your thoughts!

Features or Benefits?
According to Ross - his company sells "Features" of their enterprise wiki software product, and lets the customers figure out the "Benefits" for themselves.

This runs counter to one of the most important high-tech Product Marketing and Product Management concepts - that of identifying product "Benefits" and using that to create marketing/sales messaging (instead of just the "Features").

That being the case, how has Socialtext managed to achieve success so far? Is it an exception to this concept?

First There Are 'Early Adopters'
The answer to this question is found in the popular Crossing the Chasm book by Geoffrey Moore:

In this book Moore talks about what became known as the "Chasm Theory", which is best explained with the image below (this image is loosely derived from the book, but not identical):

When a new technology product is introduced in the market, it is initially adopted by customers Moore refers to as 'Innovators' and 'Early Adopters' - who usually make up ~5-10% of most markets. In order for the product to become a mass market success, it needs to be adopted by customers he refers to as 'Early Majority' and 'Late Majority' who make up ~70-80% of most markets.

Then Comes the Chasm
Moore points out that there is a huge "Chasm" between 'Early Adopters' and 'Early Majority' segments. Why so?

The main reasons are these. 'Innovators' and 'Early Adopters' buy interesting and cool technical tools, and figure out how to use those tools to their own benefit. They don't need to be told what the benefits are by the technology product vendors. They also don't need references from other customers, success stories, etc.

On the other hand, 'Early Majority' customers expect the technology product vendors to tell them what problems their product addresses and what benefits it offers to them. Not just that, they expect customer references and success stories too. And clearly defined ROI (Return on Investment). They buy solutions to business problems, not cool technical tools.

Most Startups Never Cross the Chasm!
Most technology startups never cross the chasm because they never figure out a compelling benefit or ROI for a target market. But many fall under the illusion that they've made it while the small part of the market made up of 'Innovators' and 'Early Adopters' is scooping up the product.

As a result they never master the critical techniques needed to successfully cross the "Chasm", such as choosing a target market, creating the "whole product" for that market, positioning the product, building a focused marketing/sales strategy, etc.

My Take On Socialtext
Coming back to where we started - is Socialtext correct in saying that it can simply sell features and let customers figure out the benefits themselves, because it is a Web 2.0 software company?

My answer to that question is "Not really". I believe that they're yet to cross the chasm - they're selling to 'Innovators' and 'Early Adopters' and hence don't need to demonstrate benefits or ROI.

However, in order to really make it big by crossing the chasm - they must do what every successful "enterprise software" company does. Demonstrate benefits, prove ROI, provide customer success stories, etc - basically answer the most important question the prospective customers have: "What does your product do for me?".

It is still about the "Benefits", not just the "Features". Even for the so-called Web 2.0 class of software which are all the rage these days - expecially in the VC community in Silicon Valley.

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

I attended a panel discussion at a forum event in Silicon Valley last week. The topic was "Web 2.0" - which I think is mostly a meaningless buzzword. In any case, on with the story...

Ross and Socialtext
One of the panelists was Ross Mayfield, founder and CEO of Socialtext a Silicon Valley startup that sells "enterprise wiki solutions" - basically software to create and manage wikis.

A member of the audience asked a very relevant question: "What problems does your software address?". I thought Ross will give a summary of Benefits.

Features, not Benefits?
Instead, he gave a long answer the gist of which was "We sell features. Our customers figure out the benefits".

Really! I was surprised to hear this answer from the CEO of a company that describes itself as an "Enterprise software" vendor. Other panelists, made up of VCs and analysts (not sure any of them had marketing/sales operational experience at a real high-tech company), mostly concurred.

For those of us who have done Product Marketing and Product Management in the high-tech industry, we've always been told that we should emphasize "Benefits" over "Features" when creating product messaging (brochures, sales presentations, etc). Was that wrong? What is the deal?!

Au Contraire!
I discussed this topic over lunch with four friends who have lot of experience in marketing and sales at successful large as well as startup companies in the valley. The unanimous opinion was that it is most important to clearly communicate product "Benefits" if you hope to achieve mass market success.

What about Socialtext then? They have real customers who pay them real money, and real VCs who have given them much much more real money! The answer to this riddle is found in the popular Crossing the Chasm book by Geoffrey Moore. Can you guess what it is? Till next time...

- Michael

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

A common question that comes up in discussions is what qualifies as a Requirement and what qualifies as a Feature.

I've always thought of a Feature as something that would go as a bullet point in a product datasheet or brochure. A Feature is a capability that provides an end user the ability to achieve a business goal.

A Feature then is usually made up of a set of Requirements.

EXAMPLE
A Feature of Amazon.com is "One-Click Purchase".

Some of the associated Requirements may be:

• Software shall check to see whether the user has enabled 'One-Click Purchase' in his preferences
• Software shall retrieve all items stored in the cart
• Software shall process order using default credit card and shipping address stored in the account
• etc...

A Feature thus consists of a set of Requirements that need to be implemented to provide the user the ability to achieve a goal.

Posted by michael at 12:15 PM | Permalink | TrackBacks (0) | 2 Comments | Post Comment

I just read an interesting post by Jason at '37 signals' blog on Essential vs. Non-Essential requirements.

He discusses the process their team went through to prioritize requirements while developing their Campfire software that was released recently. In essence, it involves classifying requirements into Essential (must have) and Non-Essential (nice & cool).

This leads to the question of what is the best way to prioritize requirements? And is there a "best way" really? How exactly do you decide which requirements fall under the "Essential" bucket and which don't?

How is it done in most companies?
Product managers and Product marketing managers routinely go through this exercise of prioritization. For a high-value B2B software, any requirement demanded by a large customer gets Essential status while those that someone at the company came up with get Non-Essential status. In small startups, the requirements the founder(s) really want could end up getting the Essential status.

In other words, which requirements get the Essential status is often decided by the importance of the originator of that requirement! Is this the best way?

What is the best way?
In theory, capital should be allocated to maximize ROI (return on investment). ROI can be defined in many ways - but is usually defined in terms of a financial metric such as NPV (net present value).

If that is the case, requirements should be prioritized in terms of financial return they will generate. We can grossly oversimplify (for the purposes of this discussion) and say that requirements should be prioritized in terms of incremental revenue they can generate. I say "revenue" instead of "profit" (more accurately "free cash flow") since it is usually easier to estimate.

Your customers will pay the highest incremental price to those features that provide them the most incremental value in achieving their own goals.

Once we are able to estimate the incremental revenue generated and incremental customer value added by each requirement, we should be able to arrange them in a prioritized list. Sounds simple enough, right? Wrong!

Some challenges
The most common challenge is: How do you estimate the incremental revenue generated by each requirement?

This is usually done via some guesstimation work by the product/marketing manager. They usually use some third party reports (IDC, et al), data analysis of customers, and some guesswork. Sometimes customer feedback is solicited as well - but could be very cumbersome. Net, this is a very inexact science.

The next common challenge is: Strategic fit. What if a requirement can indeed generate high incremental revenue but does not align with "Corporate/Product Strategy"? This fit is usually decided by someone in the executive team and is the most common means through which execs contribute to prioritization.

Another common challenge is: Technical fit. What if a requirement can indeed generate high incremental revenue but does not fit with the technical expertise of the company? This fit is usually decided by an engineering/development manager. This is the most common means through which engineering management contributes to prioritization.

Final word?
When all is said and done, prioritization of requirements is an inexact, social activity. Lot of things need to be taken into account - in the case of larger companies, even some corporate politics!

Two factors: 1) ROI to company, and 2) Value added to customers should be the dominant factors - but other "soft" factors should be taken into account as well.

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