Ten job hunting tips for a product manager

I had mentioned in my last post that I would post tips from my experience looking for a job as a product manager – in fact I had to do this twice in the last 7 months. So here is what worked for me … Remember one thing – job hunting is nothing but a marketing and sales job of a single product – You !

1) Don’t respond to job postings unless you want your resume to end up in a pile.

2) Get your foot in the door: Instead, if you find a job in a company X that you want to apply for, use social networking sites such as LinkedIn (this is the only one I use) to see if you are connected to someone who works there or if one of your connections knows someone who works there – then get recommended. You are looking to get a foot in the door and get the first phone call. Candidates who have been recommended by internal sources will at least get the first phone call – it is up to you to take it from there. If you know someone at the company, it will also give you an inside scoop – what is the real story, how is it to work there, anything about your future boss you need to know about – his/her management style etc.

3) Call the hiring manager: If you are not connected to anyone, again use LinkedIn to see who the hiring manager could be – I look for titles such as VP of Product Strategy, VP of Marketing, VP of Product Management etc. If LinkedIn does not have it, look at the company’s website under the Team/Management section. Then call the company and ask for that person – if you do get the person on the line (tough because people are travelling or are in meetings), tell them who you are and why you are calling. If you get the standard response of apply for the job and send it to HR, be frank and tell them that you are trying to get your resume visible and ask if you can send the resume to him/her so that he/she can send it to the hiring manager. There is nothing wrong in asking, worst response you can get is a No. A lot of times this will work and it also shows your initiative and strong interest. Then email your resume within a day so that your name is still fresh in the other person’s mind. Followup with the person via email (no phone calls) after a week if you have not heard anything.

4) Email the hiring manager (long shot): If you do not get hold of the hiring manager over the phone, then try the long shot – you need to figure out if you can get his/her email address. How do you know if it is roberts@xyz.com or robert.smith@xyz.com or smithr@xyz.com – look at the bottom of the press releases at the company X’s website. The company’s contact for the press release typically puts his/her email address at the bottom – this will get you the syntax. Again, sending a cold email is a very long shot and may get you a response only if you are a very strong candidate. I will not follow up on such an email because you don’t want to spam the person.

5) Work your network – there is a great book of “Dig the well before you are thirsty” that is worth reading – basically don’t try to create the network just when you need it – keep your network alive, help others when they are in need and they will help you when you have a need.

6) Get involved in local product management associations – present at conferences on product management topics – you want to be seen as a subject matter expert – you need to do things (good things !) that will let you stand out in the crowd.

7) Always keep looking for a job – you never know what opportunities come along your way – but you don’t want to be switching too often either – pick a job that broadens your experience, stay there for a while, succeed and then think about making a career move.

8. Research, research, research – Get to know about company X as much as you can – as if your life depended on it – you need to comb through its website and know everything about them – where have they been (look at company history, look at old press releases), where are they going (job postings may give you an idea about their future direction), read about the company in the news – what else are others saying about the company (don’t just believe what the company says about itself). Last thing you want to be is a candidate who is not prepared.

9) Company cheat sheet – Prepare on companies you have applied to as if the phone could ring at the very next second for an interview. I created a 1-2 page cheat sheet on each company I applied for so that I can have this information at my finger tips (in case the phone rang).

10) Company’s customers – Can you find a way to talk to some of the company’s customers? If the company has a discussion forum, you may be able to find customers there – what do they think about the company? How are the company’s products perceived? What is the future of the company in the eyes of the customer? If you do talk to their customers, mention this during your interview – it shows how well you research something, how comfortable you are talking to customers etc. – good companies value this and if they don’t, it may not be the right place to work after all.

What about recruiters? I did not have good luck with recruiters – not that they are bad – but they are hired by companies when their own recruiting efforts have failed and hence recruiters only look for a round peg in a round hole – their clients give them specific requirements and recruiters cannot flex them too much to accomodate a candidate’s qualifications.

Tools that I used effectively:

1) LinkedIn
2) Indeed.com – it compiles jobs from different job boards and emails you a digest daily.

I did not find ladders.com useful – it costs a whole lot ($30/month) and it was not of much help.

There is nothing called “too much preparation” in job hunting. So prepare, prepare, prepare ….

Joined salary.com

After 6 months of working at RSA, I decided to pursue another career opportunity that came my way. On Friday, I joined salary.com as Director of Product Management. I find it very refreshing to get back into the internet space. So for the second time in 6 months, I am going to be drinking from a firehose, but something tells me that this time it is going to be easier and more fun than last time where I had to come to terms with encryption, cryptography and enterprise software. I am very excited about this new position. Given that I successfully found two jobs in the last 6 months in product management, I intend to write about some job hunting tips that I found useful. So stay tuned. I expect to write about it in the next week or so.

Email and 7%

I happened to come across the notes taken during the Effective Networking seminar (run by Diane Darling) that I attended a year back. One of the things that was mentioned was that communication power is based on:

  • 55% body language
  • 38% voice/tone
  • 7% words
This means, whenever you send an email, you have just thrown out 93% of your communication power. If you pick up the phone instead, you get 45% of it back. And what are we so used to doing these days – sending emails. Is the world now full of lousy communicators? BTW, I learnt a lot in the above seminar and would highly recommend it and I have no vested interests in making this recommendation.

Love the customers who hate you

I have been a big proponent of online communities and social media – I have written at least two blog posts on this. So when the latest Business Week arrived with the main section titled “Consumer vigilantes” I could not put it down. The most interesting article among many dealing with social media was titled Love the customers who hate you. This is a must read. The net net of the article is captured in “…… Now don’t get mad at these people. Instead, help them get even with you. These angry customers are doing you a great favor. They care enough about your product or service to tell you exactly what went wrong. Other customers may just desert you and head to the competition. But these are telling you what to fix. Listen to them. Help them. Respond to them. Ask their advice—and they’ll give it to you.” – Enjoy reading.

Passion vs. decibels – How to manage vociferous customers

In my product management career, I have always had some users who were more vociferous than most of the others. Their decibel level when they asked for new enhancements or yelled at you for the bugs in the software was orders of magnitude higher than majority of the users. The vast majority of these users were loud because they cared, they were passionate about your product. Hence, don’t discount these users – listen to them, allow them to vent and take action to fix their problems if appropriate.

However, you as a product manager need to do a fine balancing act you – some of the feature requests from these vociferous users could be for functionality that applies just to them, because of what they use your product for or the unique way in which they do a common task. You have to listen to them, but also be willing to say No with a justifiable reason. All of us ask for more, but not everyone expects to get everything they ask for (if you don’t ask, you don’t get – so there is not much downside to asking). As long as you tell them why you would not do something, they will understand – getting back to them tells them you care.

I remember an instance where I was reading through the enhancement requests we had received when I came across a tirade from a user. It was an email bomb filled with expletives how our product sucked and how he thought we were all a bunch of idiots. I picked up the phone and called the user. I introduced myself and told him that I was calling him about the enhancement request he had send in. First thing he said was a sincere apology for having writing such a tirade (I don’t know if he thought I was going to sue him) and said he was having a bad day and the software was not working the way he wanted to get his job done. I asked him not to be apologetic and asked him to help me understand the deficiency in the software. We spend a good 20 minutes on the phone understanding the issue.

Guess what likely happened after the call – I created a passionate user for our product because I took time to read what he had written (however unpleasant),  call him and discuss the issue to see how we could improve our product so that he can be successful with what he does. Do you think he would have shared this experience with his colleagues or other users in his community? I absolutely think he would have. What happens if he encounters someone else who has a similar gripe – he is going to tell them we care and to talk to us. I created another big proponent who is going to spread the word about our product and about us as a company.

Creating passionate users and listening to them is one of the most important parts of your job as a product manager. After all, the answer is not in the building – it is very important for all of us to get out of our busy schedule of internal meetings and take the time to talk to real users.  After all, they are the ones who buy our product.

Help your customers buy …

I bought a new car last week. I was very clear what I needed – a Toyota Camry Hybrid and knew the exact options I needed. I did all my research on the web in reading user generated reviews, dealer invoice prices and so on. After spending about 3 hours doing all this, I was ready to buy. I wanted the car in a day because my previous car was giving me trouble.

I started making phone calls to Toyota dealers. I told them right upfront:

1) Here is the exact car I need – color, options etc.

2) I don’t have time to haggle

3) I am shopping around calling dealers

4) I am looking to buy tomorrow.

The sales person at the three dealers I called listened and they told me their best price and they had the car – they asked me if I would like to come in to test drive the car – no pressure, here is what you need, here is what we want – none of the traditional pressure tactics that auto dealers are well known for.

I ended up buying the car from Bernardi Toyota because they not only had the lowest  price but they also worked with me respecting my intelligence to come up with a win-win situation regarding my trade in. So what two lessons did I learn as a product manager from this personal experience?

1) Get real users to write reviews about your product. This is much more reliable than what you as a vendor can put out there. I went to the Toyota website only to look at the specs, colors, options etc. I did all my research on sites such as edmunds.com. Organizations always worry about user reviews because they fear bad things will be said about their products and that the competition will get hold off these reviews. Think about it, by promoting candid feedback from your user base, you are actually raising the bar for your competition. Everyone has skeletons in their closets – you are forcing the competition’s hand to do the same. My advice – forget about the competition – be more concerned about what your customers have to say – if they have bad things to say, you should be the first one to know because you are in a position to fix the problem. No matter what you put out, you cannot satisfy everyone – there will be someone who will say something bad about your product. If all you get are bad reviews about your product and you choose to ignore it, you are only buying time before the inevitable happens.

2) Teach your sales people to listen to the customer’s needs and to respect the customer as an intelligent human being. Help the customers buy what they want rather than trying to sell to them. We all love to buy and don’t want to be sold to.

Based on this very positive experience, I recommended Bernardi Toyota to my friend who was also looking to buy a new car and he is buying from them today. “Word of mouth” pays.

Avoid excuses for not conducting customer visits

Customer visits have always been one of my pet subjects because the only way I have learned to deliver good products is by getting out of the building and talking to real people who buy or will buy my products. At SolidWorks, customer visits was ingrained into our working culture and all of us had an MBO of conducting six customer visits every quarter.

Jeff Lash has written a very good article on his blog titled Avoid excuses for not conducting customer visits. It is definitely worth reading.

Free products like gmail – do users have a say?

For the last week, gmail has just stopped working for me. Boy, it has not been fun, being locked out of your personal emails. I also use google docs and the story is no different here – I am locked out of my documents as well. I have tried everything that Google has recommended on their discussion groups but to no avail. Initially I thought the problem appeared to be related to accessing gmail from web browsers on a Mac but now I am finding that this problem exists on Windows as well – web browser does not matter. Speculation on discussion groups is that this was caused by Google’s latest update. I have seen reports of this issue as early as couple of months back and to this date, there has not been a fix?

This raises some important questions about free products: Because it is free, does that mean users do not have much say – after all beggars cannot be choosers, they say. There is no customer support number to talk to a human, you can send an email to google, but it says there will be no response from them. All this from a company who has grandiose plans to replace archrival Microsoft from its stronghold position in business apps? I think Google is going through growing pains of delivering its once well known Saas solutions of gmail.

I was one of those users who did not care about ads pasted within my email, but I cannot live without my personal email. Is this what we get for using free products? Do we have any say or are we left on our own?

Are you agile?

I have heard this question being asked a lot of times – do you use agile development methodology? How about scrum, how about spikes? I heard this asked yesterday. To tell you the truth, I have some idea what agile is but to me it sounds very much like the latest buzzword to me. In my product management career spanning 12 years, I have really not paid too much attention to what software development process my team uses. Instead what I have focused on are things like –

1) Is my development team delivering functionality that solves customer problems that customers care about?

2) Are they delivering it on time so that it satisfies my existing customers and can help the business meet the revenue projections for this year?

3) Is the team receptive to iterative input or to customer’s new requirements during the development cycle to change the functionality based on customer feedback during alpha and beta testing – without telling me that “hey it was not in the spec and it is too late to make changes” (I fully realize to meet schedules and quality, there is indeed a point where it is too late to make changes)

4) Does my development team create very frequent and usable builds (not fully tested and hence buggy in some respect) so that QA and product management get to play with it early to ensure that what is being built is what customers want and to provide iterative feedback (Believe me, I do not think there is anything called a complete spec because have written so many functional specs over the years, I consider it difficult to foresee all the different permutations and combinations when writing the initial spec)?

5)  Are they delivering functionality of good quality that customers can use?

To me, delivering usable products to customers  that help the customer be successful and helps my business to make more money, is all that matters. What you call the process, agile, scrum, spike, non-agile does not matter.

Like anything else, if your development team does not have the right skill set, no development methodology stands a chance to do what is needed to sustain and grow your business. So before one starts using the latest fad in development methodology or starts saying things like – if you are not using agile, you are doing something wrong – it would be better to ask the question – why do I need this new methodology? what current development problems will it solve? What benefits would it bring to my customers or to the business.? Such an assessment would be well grounded in objectivity and reality rather than getting carried away by this hype.

I am not saying “agile” is bad or wrong (I don’t know enough about it) but no process can fix a problem if you don’t know the root cause to the problem.

Customer Service Experience

How often have you called customer service at credit card companies, airlines, medical benefits and you have been asked to enter information such as your credit card number, your zip code, your social security number, your frequent flyer number etc. and then finally when you get to a live person, the first question is what is your XXXX – the same information that you had entered using the keypad …. Huh!!

Do these folks ever try out their own systems to check out the customer experience? Or is just a tactic to balance the call volume – benefit for them and none for the customer.

BTW, if you want to spare yourselves of this torture, check out gethuman.com

The beloved “Nano”

Last week, Indian automobile industry took a major step. Tata Motors, one of the companies in the revered Tata conglomerate unveiled “Nano” – the long talked about 1 lakh car (1 lakh = 100,000 and 1 lakh rupees = $2500 US). This was a dream come true for Ratan Tata – Chairman of Tata Motors.

It was a proud moment for all Indians including me. Someone had pursued his dream, in spite of all the naysayers who said that a car could not be built at such a price point. He persevered, motivated his team to create something what others called unachievable and succeeded. That is the hallmark of a true leader. He had two important criteria that he would not compromise on – the car had to look attractive and had to meet safety standards. It sure looks cute if you ask me – looks something very much like the smart car popular in Europe.

Tata Nano and its creator - Ratan Tata

There are some very valid concerns in the general public around this announcement – impact on already congested Indian roads and the impact on increasing pollution. But let this not take away from what was achieved and how one man persevered to make his dream come true.

To me this car is going to make millions of people in rural India (where majority live) achieve their dream of owning a basic transport. Mr. Tata has changed the rules of the game needed to sell into this market segment. This is going to give a major boost to industries such as car repairs, car accessories, car parts etc. in rural India. This in turn will create more jobs and this can have nothing but a positive impact to the Indian economy.

This creation has more impact in revolutionizing the transport industry than any other product that I know. Oh by the way, remember how much hoopla was created in the US around the product codenamed Ginger what is now a failed product called Segway.

Mr. Tata, you have made a billion people proud last week. I hope that this turns to be the tipping point that makes more entrepreneurs worldwide – not just India – to believe in themselves, dream higher, persevere and succeed. I hope this car achieves market success and this becomes a tipping point that also forces the corrupt Indian politicians to wake up and fix the infrastructure problem that India desperately needs.

How best to ask for resources?

Imagine that you have to make a business case to your upper management for a product/project you want to get funded. There are two ways a product manager can ask for this:

1) I need $$$$$ and XXXXX number of people to do this project?

2) I have this idea that I have vetted with customers and prospects, here is the total size of the market, this will help us move the business forward, this would establish us as a market/thought leader, here is potential revenues we could bring in, what do you think and do you agree we need to do it?

Which do you think is going to be received well? Of course answer 2 (provided you have done enough research). The obvious question that will be asked would be – what would it take? And the answer is 1). But going in there with guns loaded just with 1) is not going to get anywhere.

The other benefit with 2), is you are asking for input whether it is the right thing to do – you are engaging your management to help you make the decision. Once you have the buy in that the idea/product is worth doing, they will open up for your justification for resources. But the common mistake made by product managers is doing 1) with no luck.

State of You?

As a product manager, you are quite busy doing product roadmaps, gathering requirements, working with cross functional teams, getting the messaging right,writing positioning statements etc. You are busy trying to do all the work with less time and resources available at your disposal. In the midst of this chaotic professional life, have you taken the time to evaluate how well you are doing growing your career, building value for yourselves such that your market value is increasing? Yes, the first and foremost thing we should focus on is building value to our employers (that is what we get paid for), but it is also important that you spend time adding value to yourselves. After all, I doubt that most of us want to do the same thing and work for the same employer for the rest of our working lives .

One technique that is useful is creating an honest assessment of the one product you are in full control of – YOU!!. The way I did it the other day was to create a list of all the skills an ideal product manager should have (if you don’t know the full list, read a bunch of job descriptions for product managers in your industry and look at the requirements or skills being asked for and then create the list) and then made a honest assessment of where I currently stood on a scale of High, Medium and Low (High = strong, Low = weak). I also did an assessment of what my personal interest is for each of these skills. For example, as a product manager, one is required to help legal with contracts – I consider this as a necessary evil that I as a product manager has to live with, but not something I want to get very good at. On the other hand, product positioning or market sizing is something I have great interest in and should have a strong skill.

Once you do this exercise, your strengths (High skill set, high interest) and weaknesses (low skill set, high interest) is going to stare at you. Now you need to create a roadmap on how you are going to work on your weaknesses and figure out what projects you may want to take on (read “initiative”) at your current employer to add more value to your employer and yourselves.

I have done mine and found this very useful and I intend to use this once a year to evaluate my progress and analyze the State of “Me” going forward. The above technique can be used by anyone – engineers, scientists, doctors etc. and not just product managers.

3 types of words in positioning statements

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, next generation, flexible, configurable 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.

It is not what you say but how you say it !!

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?

Pain points vs. Requirements

I was involved in a conversation last week where we were trying to unearth customer pain points. One of the software 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.

Balancing Strategy vs. Execution

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.

Need more than a PRD? Functional specs to the rescue

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 !!

How useful are the error messages?

Have you got error messages when using applications that have made you wonder whether a real person wrote these messages? It has happened to me numerous times. The best error message I have ever seen is when Pro/PDM, a CAD data management product from PTC once crashed with the error message – “Gastronomic error occurred, exiting” – I am not making this up – this was in 1996.

Though software development has made great strides since then, the usefulness of error messages have not changed that much. I was visiting one of the websites today (I cannot reveal the site name), when this information message caught my attention.

error-message.jpg

I was quite happy to notice that they wanted to improve my shopping experience, but look at the message. I am left to figure out when the site would be down. What would it have taken to say the exact date and time when the site would be down – nothing. But I speculate that some web developer discovered a cute little function that could update the number of hours and minutes to shutdown real time and he/she would have said”Wow, cool”. If the person who put this message together had stopped to think for one second whether the message provided the useful information he/she wanted to convey (the information that his/her customers could process), he/she very likely would have changed the message.

Think about all the information you put out there for your users and think about how much of it would make sense to them. Your users don’t have your product as the center of their universe, they are using it as a tool to get their real job done. Do all the messages that your product puts out help them get their job done? – that is the only benchmark that matters.

It is up to us as Product Managers to emphasize to our documentation/development teams that error/informational messages put out by the product has a significant enough influence on usability and user perception of your product that enough attention should be put in writing user friendly messages (and not one that makes great sense to developers alone).

Apple customer service complaints!!

My previous post was about the horrible customer experience at the Apple store. I find out that I am not alone – there are more and more stories on the internet how their customer service is bad. Here is a recent post on San Jose Mercury News – very much along the lines of my experience.

Apple’s So-Called Geniuses Can Do Better: In order to fix my daughter’s iPod, a staffer at an Apple store wanted me to request an appointment with one of their ‘geniuses’ — their word, not mine – San Jose Mercury News 10/15/07