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

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

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

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

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

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