Other day, I was talking to Jon Hirschtick (founder of SolidWorks and my previous employer) and we were talking about positioning statements. Jon had an interesting way to put it - he said words in any messaging consists of three types of words:

1. Blather words: In other words, marketing buzzwords - integrated, extensible, scalable, value added, synergy, paradigm, value added etc. - so commonly (mis-) used that it adds no differentiation to your message
2. Glue words: Words that you are forced to use such as “and, or, the, with” etc. Does not add to your message but necessary to hold your message together
3. Keywords: These are the real things. This is where you need to spend your most time carefully picking them. Choose simple words that communicate the essence. Use what will resonate with the audience, words they can associate with, words that will stick with them.

Jon has put this out in very simple terms that this will be my guideline in all messaging that I do from now - positioning statements, key messages in my presentations, marketing material etc.

Have you seen the latest HP’s TV ad that features Burton snowboards? In the ad, the narrator  says ” … it still did not catch on, people just did’nt get it. Maybe it was not what we were saying, but how we were saying”. This is true with many products. Positioning messages are key for successful products. You got to simplify it so that someone who does not know much about your product, gets it.

McKinsey recently published an article on  “Crafting a Message that Sticks: An interview with Chip Heath” that talks about how executives spend months developing a great idea, but then just hours as to how to communicate the idea to their employees, customers or partners. Chip says “It’s worth spending time making sure that the lightbulb that has gone on inside your head also goes on inside the heads of your employees or customers.” Simplifying a message does not mean dumbing down a message, but capturing/highlighting the core elements of what you have to offer in a simple message that will stick.

How simple is your message for your products? Will it stick?

I was involved in a conversation last week where we were trying to unearth customer pain points. One of the product managers explained that main pain points were integration and scalability. This is what set me thinking about the difference between pain points and requirements. The  two are not interchangeable - in fact there is a parent child relationship here which if you ignore, you could end up building the wrong or a less preferred product.

Pain points are what customers are going through because they do not have a product that solves their problem. For example, before the advent of wireless devices, a customer pain point could have been that he cannot make a phone call while he was in the car - notice that nowhere in this pain point is wireless mentioned. Putting wireless into this sentence would be jumping to a solution as to how to solve the pain point. It is extremely important that product managers understand the real pain points. Here are some other examples - all cooked up for illustration.

1) I am in sales and I get a lot of customer queries via email. I need to respond to these quickly to close the deals. This is especially true towards the end of the quarter. But given that I am travelling and in meetings at customer sites, I am unable to do this because I cannot get to my email unless I am in the office and this costs me time and money. For example, in one instance last quarter I missed closing a deal worth $1M by one day. (I guess RIM probably heard this a whole lot and came up with the Blackberry - but do you see anything about a Blackberry or a mobile device in the customer’s description of his/her pain point? - does it say anything related to integration or scalability or ease of deployment in the description?)

2) I usually get out of the office after the banks have closed. Hence I am unable to get to the bank before they close to withdraw money from my account. Hence I have to remember to withdraw money on Saturday mornings, enough to last me one week. I feel uncomfortable carrying all that money around where ever I go.  BTW, this is still true in a lots of places in India (what do you think could solve this? I can think of two - ATMs, credit cards)

3) I end up paying a lot of late fees because I forget to mail my payments on time or because the postal service takes more time to delivery my check to the credit card company. For example, last month I ended up paying $58 in late fees. It is hard to predict when exactly to mail the payment. I cannot afford to send the money way ahead of time because I have to wait for paychecks to get deposited (Could very well have been one of the pain points that created online banking)

You get the idea. It is very easy to fall into the trap of starting to describe product requirements and not pain points. It is not easy to do tjos because the creative part of our brains loves to start thinking about how to solve the problem. But take control - make sure that you understand the pain points very clearly before you start listing requirements or evaluating product ideas.

Product Managers are responsible for managing the business of their products. This requires one to have a product strategy to ensure that the product continues to remain relevant to the marketplace in midst of new market trends and changing customer needs and also continues to provide a good size market opportunity so that the business can remain profitable.

But once you have come up with a decent product strategy that is well grounded in reality, flawless execution of the strategy is even more important. Strategy does not win customers, the product executed based on the strategy does. It is like a football game. The coaches can devise the best strategy that accentuates the strength of the team and one that exploits the weakness of the opposition, but unless the players execute flawlessly on the strategy, strategy means nothing.

All of this may sound common sense, but who was it that said that common sense is not too common. I have been part of some long drawn discussions which have involved debates about perfecting the strategy and spending countless hours trying to hone on the right strategy. I would rather have flawless execution based on a good but less than perfect strategy than having less than perfect execution on a perfect strategy (because I do not think one exists). Flawless execution can many a times can cover up weaknesses in strategy, provided one learns to adapt as one goes along. It is important to start rowing along a rough direction that you think makes sense and then iteratively steering the boat in the right direction as one goes along. You will come out a lot ahead this way compared to staying on the shore and refusing to row until you figure out the absolutely perfect direction to row in. This is an easy trap to fall into, especially when you get involved in workgroups, strategic initiatives etc. By the time you get something accomplished via such initiatives (read “a long time”), the strategy could be outdated by the market changes that took place in the mean time.

Winning your first customers who will help you improvise is extremely important. When in doubt, lean towards execution than strategy because execution is progress, while purely devising strategy with no execution is nothing but stagnation. As a product manager, especially in the high tech market segment, stagnation is death !!

Now, do not mistake the above to be saying that it is OK not spending time setting a product strategy or to have an ever changing strategy - one that changes based on the latest fad or what you heard at the last customer visit. No that is not the point. Take time to devise a strategy, once it is good enough, stick to it and execute as hell. Once you have the product ready, sell it, get feedback from the customers and then figure out what you need to do next. Your strategy may still be sound or may need adjustments, but this is whole lot better than doing nothing and waiting to get your strategy right before you start executing.

Product Managers are all familiar with writing MRDs (Market Requirements documents) and PRDs (Product requirements documents). Are these enough to communicate to engineering all the customer requirements that would result in engineering building a product that is usable by customers to solve their problems? Unfortunately in my experience, a PRD is not enough.

PRDs are very good high level documents that communicates to all stakeholders what one needs to build - new products, key elements of a new product release etc. But when it comes down to detailed customer expectations of the individual features called out in the PRD, there is nothing in the PRD that helps out the engineering teams understand the customer requirements and expectations. This is not a fault of the PRD but calls out for the existence of a supporting document that builds upon what is stated in the PRD. Such a document is well known as the functional spec.

But after talking to my friends and acquaintances from different companies, I am surprised to find that many companies do not invest the time and energy in creating the functional specs upfront. The net result many times, is a product that does not meet the customer needs/expectations/requirements and one that sometimes is unusable and hence not sellable. Lack of a functional spec essentially makes a product manager hope and pray that engineering has exactly understood what needs to be build from one sentence/one paragraph describing the feature in the PRD. To have this happen, you either need very smart developers who can put themselves in the user’s shoes (and there are very few of these) or you have to get outright lucky (I think winning a lottery has better odds). This becomes even more important if you have globally distributed development teams who may not have the luxury to talk to your customers.

So what exactly is a functional spec and what does it need to contain. I was asked this the other day and I put the following FAQ together.

1) What is a functional spec?
Functional specification is a document that lists the requirements for a single item (project) listed in the PRD. It lists all the minimum requirements and the interaction requirements for any new feature including all graphical user interface elements being introduced by the new feature.

The functional spec is typically written by someone who intimately knows the user needs and user expectations. In many cases, this happens to be the Product Manager since he is expected to best know the user’s needs.

2) Why do need a functional spec when we already have a PRD and engineering design documents?
Functional spec is more detailed than a PRD. For example, a PRD may call out for a search utility or for a migration tool. There are multiple ways to solve this problem. A functional spec on the other hand would detail out all the solution requirements and also how the user interface should be presented to the user and how the user would interact with the UI.

Engineering design documents are documents written to design the internal architecture of the system such that the minimum requirements and the user interface called out in the functional spec can be implemented.

3) When is a functional spec written?
Functional spec is written before engineering embarks on the implementation of a new feature. The functional spec is reviewed, iterated and agreed upon before the start of implementation of the new feature.

4) Do all items in a PRD need a functional spec?
Not necessarily. This is something that has to be decided by the Product Manager and Engineering. For example, a project titled “Ensure that the new release supports backward compatibility - new client works with a old server” does not require a functional spec since this is a system requirement that does not have any new user functionality. But all projects that introduce new User Interface elements should have a functional spec.

It is also possible that in some cases, one item listed in a PRD may get broken into multiple projects by engineering. In these cases, one item in a PRD may end up having multiple functional specs associated with it. This is something that needs to be worked out between the engineering and the person writing the functional spec.

5) Who needs to review a functional spec?
The functional spec needs to be reviewed by the Product Manager, Engineering Managers, developer who will code the new feature and the QA engineer who will test the project.

6) What can a functional spec be used for?
Once agreed upon, the functional spec becomes the driving document for all downstream tasks including:

· Generation of any internal design documents

· Creation of test plans by QA

· Reference document for Tech Pubs to create product documentation

· Reference document for the field (system engineers, support staff, professional services) to get more details on any new feature

Having been a product manager for the last 12 years and having written functional specifications for products used by hundreds of thousands of users, a functional spec is one that I think is an absolute must. Just like how a business plan would have detailed financial projections and assumptions, items in a PRD should be supported by a functional spec. It is the document that explains to engineering the “devil in the details”. It is one thing I cannot comprehend product managers not writing early in the development cycle. Not writing it is leaving too much to chance !!