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 | 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 | 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 | 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 | 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 | 7 Comments | Post Comment