Category: customer needs

Requirements are ….

One of the blogs I read frequently is that of Marty Cagan, the author of “Inspired – How to create products customers love” (one of the books that I strongly recommend to product managers and executives). Often, I agree with Marty on his perspectives, having experienced the many pitfalls he writes about in his posts. A month back, he wrote a post titled “Requirements are not“. In this post, he writes about how different stakeholders such as customers and internal stakeholders mistakenly call some things requirements while they actually are not. No disagreements there. But then he compares defining and creating a product to cooking by saying “I find defining and designing product is more like cooking in this respect in that if an ingredient is unavailable, you can often get creative and substitute something else or a combination of things that aren’t quite the same but may be even better. It’s the result that matters, not our pre-conceptions.” He concludes by saying “Our only real requirement is to discover product solutions that work well for our users, our customers and our business.”. This is where I disagree with Marty or I am confused about what he is saying.

Here are points I completely agree with Marty on:

  1. Customers and other stakeholders often propose solutions and not articulate problems. I have written about this very thing before – the difference between customer pain points vs. requirements
  2. Requirements are unclear at the beginning and take shape as the understanding of the problem becomes more clear.

But saying that there are no absolute functional requirements is just plain wrong. Product Managers need to delve deep into the customer’s problem and at some point come up with a solution that will solve the problem in the most usable, technically feasible and cheapest way – this is all done during the product discovery process that Marty has championed in his book. Such a solution will have absolute functional requirements once it gels into a viable solution. These requirements have to be met when the solution is implemented. Trying to change the requirements as the solution is being built (like you could do in cooking) is costly even in an agile environment where there is utmost flexibility. Yes, you do discover new solutions during implementation, but functional requirements do not change. The functional requirements describe what the user expects to do when all is said and done. For example, the functional requirements of an “authentication mechanism” do not change even if engineers figure out a new way to engineer it. Users still expect to login using their username and password, they will forget their usernames and passwords, they will type in their usernames or passwords wrong.

So, while I agree that requirements are hazy at the beginning, they should be become absolute at some point in time during the development cycle, such that the solution can be built, tested and communicated to the customer. Saying that the only real requirement is to discover product solutions that work well for all involved, is a very generic statement, but not one that product managers and engineers can use to build the product solutions. The word “requirements” are probably misused, but throwing out the whole word from the product lexicon is unwise.

Keep it human

Susan Oakes of M4BMarketingBlog asked me if I would be willing to write a short tip for her upcoming post on “How to Keep your Customers Loyal”. The post outlining some great tips should be coming out anytime now. Here is what I submitted.

Keep it Humantips
In the times we live in, customers are bombarded with marketing messages from all over. In this noisy world, companies that stand out are the ones which retain the human touch. The best way to buy customer loyalty is by treating each one of them as a unique human being at every touch point. Buying after all is a human behavior, so make sure you respect the “human” part of it.

Now what does “keep it human” mean? It could mean any or all of the following:

  1. An introductory greeting and opening the door to the customer when they walk into your store
  2. Helping the customer “buy” the right thing to solve their problem and not just try to “sell” them what you have. In some cases, you may not even have the right thing that the customer wants – recommend where they can “buy” the right thing – it means loss of a sale, but could be earning a longtime “relationship”, people typically don’t forget those who help them.
  3. A thank you card send to the customer after purchase
  4. A follow up phone call to make sure the customer is satisfied a few days after purchase
  5. A website that helps the customer finalize the buying decision and written in a language that the customer understands as opposed to one with marketing gobbledygook where the customer feels stupid
  6. A no questions asked, quality guarantee for all purchases
  7. Reachable customer support and friendly voice of the rep that engages with the customer to solve the problem
  8. A business that the customer would like to associate with and recommend to family/friends thereby putting his/her own reputation on the line
and the list could go on.

If you think about it, many of the above holds good for local businesses – the mom and pop stores in your neighborhood. The owner knows many of his customers by name, he chit chats with them when they come in, helps them solve their problem (not just sell them what they have). This is a relationship that has been painstakingly built over the years. The value of the relationship is not completely based on how much money you have spent in the store, but being respectful of you as a human being. In the good and bad economic times, one scarce resource is “customer’s attention”. Business that win more of the customer’s “attention” will succeed. Customers tend to give more “attention” to those that respect them and keep it human.

Do you agree? What would your tips be on “How to keep Customers Loyal?”

Image Courtesy of: Montgomery Public Schools

If you enjoyed this post, I will be honored if you leave a comment or subscribing to the feed to receive future posts delivered to your feed reader.

Homogeneous or Heterogeneous – What is better?

Which is better? It depends.colors

  1. Southwest Airlines flies only Boeing 737’s to reduce maintenance costs.
  2. EMC wants their customers to buy all of the data servers from them.
  3. Microsoft wants everyone to use IE.
  4. Michelin wants to be the single supplier for all tires for Toyota.
  5. Pratt&Whitney wants Airbus to use nothing but their engines for their jets.

But then…

  1. Boeing cannot survive just making Boeing 737’s.
  2. IT departments don’t want to put all eggs in one basket.
  3. World does not trust Microsoft.
  4. Toyota does not want to single source to Michelin.
  5. Airbus does not want its entire fleet  grounded if P&W engines have a problem.

Isn’t this world so beautiful for the heterogeneity it possesses. So why in business would we ever think we can achieve monopoly? Why do some businesses lull themselves to believe they do not have competition? The question is how much of the pie one can have, you WILL not have the whole pie. Success breeds competition. Otherwise, it may not be a large market after all.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of DragonArtz Designs

Do your customers know?

How often have your customers asked you for functionality that you already have in your product – functionality you have had in the product for a year or two? I have had this happen often enough in my career. There are two causes for thiseducation

1) You forgot to tell the customer

2) Your product is too big that new features are no longer discoverable

I want to spend more time on 1) than 2) because it is the easier problem to solve and I think in my experience more prevalent. You as a product manager identified the customer problems to solve, worked with engineering to come up with the most innovative and easy way to solve the problems, your team is delighted, but all of this equates to naught, if you do not take the initiative to let the world know that you have solved the problem. Often times, organizations get caught up in drumming about this new feature/product with prospective customers (thanks to the zealous salesmen who are looking for the first available opportunity to demo the new wares to prospects), that often educating the existing customers is forgotten.

This is more of an internal organization problem than an external one. It can be easily solved by first educating your internal stakeholders (training, sales, marketing etc.) on the benefits of the new widget, what problems it solves and for which customer profiles. If you do this internal stakeholder education well and carve out the go to market launch plan, then this becomes an easier and accomplishable task. And trust me, only if you do this well, can your external customers know about what you have done for them.

On problem 2) – this one is a harder problem to solve especially for feature rich products such as MS Excel, Oracle etc. Simplification is not as easy to do as it may seem. I don’t know the answer to this problem, in my past experience, we tried many solutions to solve this problem, but nothing I would say worked tremendously well. It was a tough nut to crack.

Thoughts? Comments based on your experience?

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of Connecticut State Board of Education

Understand why your customers buy

I had written a previous post on making it easy for customers to buy your product. If your pricing structure is complex, Product Management - Customer reasons to buya customer who was about to hand over the money to you is going to walk away. I call this the “last mile problem” in selling a product. Pricing structures sometimes are very complex that even sales people have trouble understanding them.

If your folks cannot understand them, do you think customers will get it? It is your responsibility as a product manager to make sure this is executed well. Do you have too many SKU’s that are interdependent on each other with complex discounting structures that your price book looks like a bowl of spaghetti? Time to take action.

But this is the last step. It is even more important to understand all the reasons why your customers buy – what are the rationale and emotional reasons they are looking for a product like yours. Susan Oakes on her M4B Marketing Blog has a very good blog post on the importance of understanding your customer’s buying reasons.

If you enjoyed this post, please consider leaving a comment or subscribing to the feed to receive future articles delivered to your feed reader.

Image: Courtesy of  Lewes District Council, UK.

Customer’s Wants vs. Needs

A customer’s wants vs. needs – This subject has been part of numerous conversations I have had in my working life. Every time I go to India on vacation to visit my family, I always think about this topic. I come back from these trips thankful of what I have and telling myself to appreciate what I have. Whenever I discuss this with friends or whenever anyone asks me what it is to live in India, I draw the following spectrum.

I explain that the vast majority of the US population falls in the WANTS spectrum. We have everything we need, we own/rent a house, we have food to eat, we drive cars or ride a bus, we have TV’s, we have electricity and running water. But we are constantly focusing on satisfying our WANTS with the next better/faster/safer gadget.

India however has a vast majority of its population still living in the NEEDS spectrum. All the IT improvements and the other technology advances that the country has made is still a drop (though a good size one) in the bucket that has made a small chunk of the population to move into the WANTS spectrum. Do not forget that India is a country of over 1 billion people.

So, why does all of this matter to you as a product manager. I liked what Seth Godin said at the Inbound Marketing Summit “We are living in a society where we have everything we need and hence we are left selling what customers want”. It is extremely important for us as product managers to clearly understand what our customers are asking for – is it a real need or is it a want?

Some customers may pay money if you satisfy their WANTS, but more customers will pay a whole lot more money if you satisfy a NEED that is unmet by you or by anyone else in the market place. So whenever you are talking to customers and they propose needed improvements, do the following

  1. First understand the underlying problem
  2. Second find out if it is something they NEED or WANT
  3. Third, is it a large enough NEED/WANT that they will pay you money if you solve them and
  4. Fourth, build solutions for ONLY those problems which a LARGE number of customers are willing to pay you money for.

Liked this article? Leave me comments – I would love to hear your thoughts – or get an RSS Feed to this blog
Bookmark and Share

Benefits of early usability testing

You do not need an Alpha/Beta software product to do usability testing. In fact, if you wait until then to do usability testing, you have waited too long. This late, making changes based on usability feedback will be costly and time consuming and apt to break something else.

The resistance offered by a software developer to change is directly proportional to the number of lines of code he has written. So the best time to do usability testing is before anyone starts coding anything. Make a bunch of images that show the proposed UI and create a click thru either using html pages (drop me a comment if you want to know how) or using powerpoint.

Then test with a bunch of your prospects/customers. Your customers/prospects should jump at a chance to see a preview of what you may be coming out with. Two things will come out of this testing:

1) You have nailed the usability (great position to be in, but very rare)

2) You will uncover some small or large usability issues.

Great! to make these changes is inexpensive, it will involve only your time, not that of your team. I don’t mean you are cheap, but in relative terms it is just your time.

Here are some guidelines to do usability testing with early mockups

1) Think about the main personas and their main use cases

2) Create mockups for these use cases

3) Never lead your audience – ask your testers to tell you how they would do the task given the mockup – if there is a large deviation between how they think they will do the task and how you will let them do the task – you have a serious usability issue.

4) If they tell you that they like something or don’t like something, ask them why – in either case, you need to know why – this is a wealth of information that will help you later when the product is built. You may even uncover some unique use cases by probing your testers here. You may hear things like – “Interesting, wonder if we could use this product to do X, Y and Z” or ” Hmmm, not sure if we would want to do this because later on we may run into problems A, B and C”. – again, great insights to get early on.

As you are doing this, ask them for their value proposition for what they are testing. Do they see value in it, if yes, what and why? If not, why not?

It usually takes only about 5-8 testers for you to see usage patterns and convergence of issues. If you see issues very early, quickly fix them before you continue to test with the remaining testers.

This is something I have successfully done for a long time with great success. Not doing usability testing very early on, is leaving things for chance. All you really need is some jpegs, a web conference tool like webex and 5-10 testers for you to work a lot of kinks out of your product early on.

BTW, invite your developers and QA testers also to these usability tests so that they are participants. This way you will get less resistance later because they will better understand the insights behind the UI that you will be asking them to code/test soon.

Google Chrome vs. Cuil – Product Management Case Studies?

By now, many of you are well aware of two new products that came out this summer (and if you have not, you were probably enjoying the summer a lot more than I was) – a new browser from Google called Google Chrome and a new search engine from a startup called Cuil

I was excited by both of these products and decided to try both of them. I had trouble getting to the Chrome download server but I waited patiently to get to it the next day. I found both the products to be buggy and gave up on Cuil and have never been back to it even once. I found Google Chrome to be buggy as well and uninstalled it because it did not work with my anti-virus software. So the initial product usage experience was the same, but there is one big difference.

I have talked positively about Google Chrome to a lot of people and given it glowing reviews – I have told them it was buggy, how I had to uninstall it and how I expect that these issues will be fixed. I have not talked to as many people about Cuil and to those who I have talked to, I have ridiculed it. I talked about what a joke it was and why I even needed another search engine when Google works so well.

So why am I spreading the positive word about Google Chrome though my first taste of it left lot to be desired? Interesting, isn’t it. Here is my analysis.

What is wrong with Cuil?

Very simple. It does not solve a problem I have. OK, you could say that you index more pages than Google but to me as a user, anything past 20-30 search results is Siberia. So the only yardstick is “Are the first 20-30 results better than what I get on Google” – No. So why do I care. So where is the product differentiation? No reason to switch from the incumbent vendor I use.

What is right with Google Chrome?

  1. Yes, the product is buggy (and aptly called Beta), but I buy into their vision. They have designed the web browser from the groundup to support web apps – at least that is what they claim. I buy into this vision. It does not solve my browsing problems today, but I know web apps are the future. So they are ahead of the game – they are looking out into the future for me.
  2. They released it in a very novel way – using the comic book concept. Very novel, again out of the box thinking.
  3. A company I respect tremendously for past innovations and I use their innovative tools everyday. If they have not got it right yet, I have the confidence that they will. Read “incumbent/entrenched vendors are always at an advantage”.
  4. When I had the issue with anti-virus software, they already knew about it and said on the forums that they were working on a solution – they were listening – they are on top of their game.
  5. They made it open source – they contributed their code base to the software community – I already know about the success of Firefox – they did not beat their chests creating another proprietary product, they are letting everyone use their innovations.

Product Management Lessons:

  1. Solve a real problem customers have (or will have soon)
  2. Incumbent vendors have a big advantage – to make users switch to your product, it needs to absolutely rock. If you are just a “wannabe” or if your differentiation is some metric which no one cares about, users will not switch.
  3. Past vendor success generates respect. Once you gain that respect, you will get a longer leash from your users (same applies to product managers too).

Does a vendor being #1 matter to buyers?

10 years back in Chicago, a colleague of mine was shopping for a Honda car. He went to one of the Honda dealerships. The salesman started giving him the standard pitch about the car and then told him that he should buy from him because they are the biggest dealer in Chicagoland and sell more cars than any other dealer. My colleague listened to all this and finally had it – he told the dealer – “I don’t really care how many cars you sell or if you sell the most, I only need one.”

So when a vendor spouts that they are #1 in some field, do you think buyers care? Why not tell them how you can solve their problem better for them than any other vendor – don’t you think that might work? Customers care about their problem being solved, not what your product is called or how many you sell. Yes, they do want to do business with a vendor who is financially strong and who will be around, but just being #1 will not cut it if you don’t have the best solution to back it up. If financial strength or the revenue size was the only metric, then do you think any of the startups that became juggernauts would have had a chance during the early days?

Why customers walk away?

Kristin Zhivago has an awesome post on her blog titled Gone! The reason customers leave. I would strongly recommend that anyone who touches a customer (sales, tech support, product management, professional services, executives) read it.

I had written last year about how customers are lot more tolerant of a vendor’s mistakes or shortcomings if the vendor keeps them informed. It is nothing but courtesy, professionalism and respect. One of the companies that I respect a whole lot in this regard is CitiCards. Twice in the last 5 years, my credit card has been compromised because of data theft at two retail stores. They proactively called me up, put my account on hold so that no fraudulent charges get made using my credit card. Do I sleep well that they are looking out for me? – oh ya ! Do you think I will ever switch credit card vendors? – oh No! Do you think I will talk great about them and recommend them? – you know the answer to that.

Doing this takes a whole lot of effort and the will to make it happen. Unfortunately companies are busy chasing new dollars, that they forget the adage “Bird in hand is worth two in the bush!”.

Product Manager’s key to success

I just happened to see this quote from Bill Cosby.

“I don’t know the key to success, but the key to failure is trying to please everybody”

How appropriate for product managers?

All product managers should have this quote stuck next to their desks so that it is in your face as a reminder. We cannot build a product that is good for everyone – pick the target buyer (who will buy) and then execute like hell. Use the target buyer to handle all the “what if we do this …” or “what if the user wants to do this …” ideas people throw at you.

Don’t know what I am talking about? Google “personas” and read all about it.

Software Product Managers – What are you selling? Product, category or need?

Everything that one tries to sell, in my opinion, starts or ends in one of three buckets.

  1. A need sell
  2. A category sell
  3. A product sell

Let me explain in more detail on what I mean.

1) A need sell is the worst place for a product long term. If your product is here, you are essentially trying to convince the customer that he has a need and that he needs your product or service. You cannot sell to someone who won’t buy. Products that remain here either are:

  • Products that are typically technology driven and hence looking for a problem to solve or just plain stupid products – someone told me that there was Sharper Image tire pressure gauge that had a clock built into it – yah, right I was missing that – guess where Sharper image ended up to be.
  • Products that are way ahead of their time – the market is just not ready for it or the technology has not matured enough that the initial implementation is just not the right way to do it.

You may be able to sell a few of these products via lengthy sales cycle, but nothing to keep you going long term – the very existence of a product should be to solve an existing need and not to convince the customer that they have a need.

2) A category sell to me is where the prospect knows that he/she has a problem, but does not think it is possible to solve it and is skeptical whether the problem can be solved. New products that solve an existing problem in a very new way (pragmatic shift) could remain here for a little while. There are many examples that come to mind:

  1. Salesforce.com comes to mind during its early days. The dotcom bubble had burst, people were just wary of anything related to the internet, internet connectivity was sketchy and here was a company that wanted to do salesforce automation on the web. I am sure it was a tough sell in the beginning.
  2. “Data loss prevention” products – large corporations are always wary of insiders leaking confidential information to the outsiders accidentally or intentionally. Technology exists to solve this problem, but it is a little bit of a hard sell. This is not only because of the sophisticated technology, but also convincing someone that the technology actually works.

Many products/services could end up in a pilot and a longer sales cycle. You may not be able to convince everyone and hence you may sell less especially in the early days. Once enough people buy it and the product becomes mainstream, it will move into the “product sell” category. Such products/services follow the classic product adoption cycle made famous by Geoffrey Moore in “Crossing the Chasm” as long as the product can cross the chasm.

3) A product sell is basically where a prospect walks in and says “Give me this product” – the customer knows that the product solves a well known problem. You don’t have anything to sell, you just have to let the customer buy it from you. This is the sweetest spot you want to be in. You sell a ton (yes, there will be competition, but you still could do very well) at a very fast pace. This is where successful products eventually end up.

Salesforce.com is currently in this category. Microsoft Windows ended up here. Apple iPhone and iPod are here. Getting here should be every product manager’s dream. But products don’t end up here only by luck – they ended up here because they solved a real problem, solved it in the most innovative way and also enjoyed some luck by being at the right place at the right time. But products cannot be complacent once they get here, because there could very well be a competing product currently in the “category sell” that is solving the same problem in a whole different way, just waiting in the wings to take off.

As a software product manager, it is extremely important that you know where your product/service lies and then try to see how you can move quickly to a “product sell” as soon as possible. If you are stuck in the “need sell” category, you may want to rethink your strategy, reinvent your product or call it day and cut your losses.

Product Management Tips

Liked this article? Leave me comments – I would love to hear your thoughts – or get an RSS Feed to this blog at https://productmanagementtips.com/feed


Bookmark and Share

How would your future users behave?

Product Managers pay (or should pay) a lot of attention to finding out more about why people are NOT buying their product more than why people are buying their product. This can be framed based on the current population of users.

But we are at a tipping point in history where a large number of baby boomers are approaching retirement and their places are being taken by a wave of new entrants. Many of these new entrants are currently in colleges. So if you are planning to develop a long term roadmap, make sure you are taking into account the behavioral aspects of the new generation.

I thought that the survery results shown below (Source: eMarketer.com) was very interesting in understanding the adoption of the latest technology by age (Low adoption of RSS feeds in the younger age group was a surprise to me). It is important that we pay attention to this because these represent the future users of our products.

The full article is titled Baby Boomers and Social Networking and is worth a read. Pay equal attention to some of the similarities called out in the full article.

Liked this article? Leave me comments – I would love to hear your thoughts – or get an RSS Feed to this blog at https://productmanagementtips.com/feed

Build products that customers will buy ….

We as product manager are well tuned with doing a market read, determining the unmet needs of the market and then getting someone to build products that will satisfy the need.

But there is an important trap that product managers should avoid. History is full of examples of products that fell into this trap. You want to build products that customers will BUY and not JUST LIKE. You could build a product that satisfies the unmet need in the best possible manner, but if it is not something that the customer is willing to pay for, you are out of luck. Your product will languish on the shelf and it will join countless number of other products that have met a similar fate.

We have four different scenarios of Like vs. Buy as shown below.

Obviously, the two categories you want to avoid are the red ones and the places where you want to be are the green ones.

You may wonder how you could ever make a customer buy a product that he does not like – there are many classes of products that fit the bill here. For example, insurance products – not that I like them, but I have to buy them – isn’t this such a sweet category to be in? Other examples include anything related to taxes (Turbotax for example), funeral planning products (that one needs no explanation) etc.

The biggest trap among all this is the Like and Don’t Buy category. Lot of customers may tell you how much they love your new product idea, but you absolutely need to find out if they will put their money down to buy it – or in other words, is the painpoint you are attempting to solve painful enough that they will be willing to spend money on it? If not, it is not worth pursuing.

Beta programs kind of fall into this category – everyone is all excited to be part of your Beta, but not many give you feedback. It is OK to have this happen on your Beta, but you don’t want this to happen to your product.

One way to avoid this trap is to try to get customers to buy the early version of your product at a heavily discounted price – you would get them the Beta version, they will give you the feedback and then you would ship them the real product at the very low price that they paid you. If you run a subscription model, you could offer the customer a heavily discounted price upfront and the opportunity to lock down the price for say the first 2 years. If you cannot get enough customers to bite on this and sign on the dotted line, then the writing is on the wall – your product is in the trap category – how are you ever going to sell at the full prize?

Having said this, I would love to hear from my fellow product managers on other techniques that could be used to avoid falling into this trap.

Liked this article? Get an RSS Feed to my blog at https://productmanagementtips.com/feed

PS: I have to thank my mentor Jon Hirschtick, founder and ex CEO of SolidWorks for having drilled this into me whenever I have had different product discussions with him.

Customer motivation to buy your product?

There is a great article on Business Week titled Johnson & Johnson’s Big Design Challenge which talks about how their design director Chris Hacker is promoting sustainable design.

I thought the key sentence was when he says “The key to growing sales is not to load up the packaging with “marketing bullets,” but to “think about what motivates the consumer to take the product home.”

So well said. Always challenge your team to answer the question “What is the Customer Value?”. Agreed that you also need to appeal to the emotional side of the customers and do need to have some sizzle features or demo candy that makes the customer buy your product – but if it is all sizzle and no steak, the product will not have sustainable sales.

Product Review – Service Magic rocks

Last week, I had to get a tree cut in the yard and then my garage door broke down with the door bent and the rollers popped out. Not knowing who to call, I checked out ServiceMagic. What an awesome experience that turned out to.

Within minutes, they send me names of three pros rated very high by their customers. I called the pro, got a quote, scheduled the job and got both of these issues taken care of in a hurry. Their customer service is outstanding – they called me to find out how the project was going, they send me thank you notes via email after I had rated the pros – they did not have to do any of this.

This is one of the rare occasions in the recent past where I could say that I have received just an excellent service. We hear all the time about service is being shortchanged by companies due to the current tough economic times, but here is a company that has figured out how to use technology to the hilt to provide such a great service – their website is awesome with easy navigation, customer ratings and reviews of their pros, the results of their 10 point screening etc. They use email communication very well and as a result take many of the pain points involved in finding/hiring a contractor off their customer’s chests. Think about the effort it takes to make sure that the contractors you want to hire have the necessary license, insurance etc. to do the work? All this is done by ServiceMagic for you. Dealing with contractors has never been easy and they seem to have made this easy.

ServiceMagic sets the benchmark against which other service companies should be considered. If you have not used them, I would strongly recommend that you give them a try.

Their success is because they have thought through the entire user experience from the usability of their website through every touch point with the customer either via email or phone. Plus, their service is absolutely free for consumers, they make their money from the pros who get referrals.

Thank you ServiceMagic.

9 elements of a good functional spec

A while back, I had written why a functional spec is needed in addition to a PRD. So what does a good functional spec need to contain?

Here is what I consider elements of a good functional spec. I tend to use smaller paragraphs or bullets to make it readable. People tend not to read lengthy sentences or large paragraphs.

1. Problem statement: This section should clearly explain the problem you are trying to solve. This should not contain anything about the solution to the problem. You want readers to clearly understand the problem first.

2. Proposed solution: Now briefly explain the solution you are proposing to solve the problem.

3. Marketing Information/Justification: Things such as how big is the customer base that has this problem and why should we solve this problem (differentiation, tablestakes etc.)

4. Target Users: Who are the typical users who will use this? Internal to your company? External users? Experienced users? New users? All users?

5. Committed or Minimum Requirements: The requirements that have been reviewed and committed by Product Management and Engineering should be listed here. Unless all of these requirements have been implemented, the project will not solve the problem it is intended to solve to customer expectations. Or in other words, the new thing cannot be shipped in the product. Number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.

6. Requirements under Consideration: The requirements that needs to be considered by Engineering for implementation should be listed here. These are not committed to make this release. If time permits, Engineering will try to implement these in the current release (this never happens by the way). However, more importantly, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future. Again, number the requirements instead of using bullets so that it is easier to refer to them during reviews, in emails, during discussions etc.

7. Out of Scope Requirements: These would be requirements that have been agreed upon by Product Management and Engineering as out of scope for the current implementation. However, Engineering has agreed to take them into account such that the current implementation will be able to support these requirements in the future.

8. Proposed User Interface: This is where you would propose as to what the user interface needs to look like, what the interaction needs to be. This section will be written by an interaction designer or a graphics artist and if you don’t have such people, you should write them. I would not leave it to engineering to design the UI, you very well know what that will end up to be.

9. Typical Use Cases: Here you should list the most common use cases that should be supported by the current implementation. QA should be able to generate test plans based on these use cases. Flow charts are a very nice way to document use cases because it would mimic the workflow you expect the user to experience and are also very easy to understand. Doing flow charts also makes you realize the requirements you may not have accounted for.

I have used such a format for about 14 years now and engineering have always liked them because it tells them why to do something, how it needs to work etc.

Five guidelines to prioritize feature requests

As a product manager, you are very likely to have more feature requests than what you can put out in a given release. In my case, a good product manager’s job at release planning is figuring out what to eliminate from consideration – you have to make hard decisions – that is what you are paid to do.

Please note that my background is working on products that have mass market appeal and did not have to deal with things like customer funded development – where a customer throws money at you to get a feature that only they will use.

Here are the five guidelines I have used effectively ….

1) How MANY customers will ever USE it?

We held a strong line on this – if the feature was meant just for the selected few (no matter how much money these customers had), we said No to the customer. You may say – no way, it will not work in my case. My reply – have you tried – Have you told your customer No and told him why? – if not try it.

I will give you an example – we had a very well known consumer company in Japan as a customer – they had bought a few licenses but had the promise of buying a whole lot more licenses – they had a lot of money. We visited them in Japan, they visited us here, met with our executives etc. – they tried to push their agenda hard on us and they had all sort of ideas as to how the software needs to work. We questioned them hard to get to the bottom of their underlying problems – why, why, why do you need to do something. They had some great ideas and some that applied only to them – we readily agreed to do the former and rejected the latter with solid business reasons why we won’t do it – not enough customers have the need.

They respected us at the end – their feedback was that we were the first vendor to have grilled them on their requests and were bold enough to turn them down, as opposed to other vendors who were ready to do whatever they wanted. They realized that we were a company that knew what we were doing and our willingness to grill them, told them that we wanted to make sure we were solving their problems the right way.

2) How OFTEN will customers USE it?

Is this something a customer will use once a year, once a month or something they would use everyday. Why does this matter? Remember the phrase “death by thousand cuts” – if something that needs to be used everyday is not supported or is very inefficient to do, it kills user productivity. This may not be something that will make a press release when you launch a new release or in your product demo, but this is something that will get you a standing ovation from your existing customers. Believe me, I have experienced this multiple times where the smallest change scored the highest in customer satisfaction. Stuff such as choosing the right default values, remembering the last used options fall into this category.

Taking how MANY customers would use it and multiplying it by how OFTEN they will use it, you get what I define as Velocity of a new feature.

VELOCITY = How MANY customers will use X How OFTEN they will use

Features with highest velocity should be serious contenders to make into your new release.

3) Will this open up new markets?

It could be something that could be asked by your smallest customer – but it could be this brilliant idea that could change the rules of the game and open up a completely new market for you. You as a product manager need to make this call.

I have been asked in the past if we implemented feature requests only from large customers with lots of licenses – my response always has been – size does not matter, quality of the idea does. This is what product managers get paid to do – take such ideas and make a business out of it.

4) Is this considered table stakes by the market?

There could be features you would need to compete in the market – if you don’t have these basic things, you are not even considered a player. These ones should be obvious if you know your market. For example, pivot tables or charting are considered table stakes for a serious spreadsheet application.

But tread this one with caution – this is where sales can take you for a ride. They will say “we cannot compete because we don’t have this X, Y and Z” and the list could be endless. For those being raised by sales, ask them to put you in touch with customers who would not buy without this feature – then from the customers get to the real problem that is solved by the feature – for all you know, you may have an innovative way to do it, or can come up with one that might change the rules of the game.

5) Is the feature a building block to the real thing?

This could be something determined by R&D (architectural changes) or some other user facing feature that is needed to support the final feature.

If you consistently use these guidelines, you end up making a business case why you want to turn down a feature request – this even works with executives because it is now based on facts and not opinions. After all this, if some higher up overrides your decision, it is not in your hands, but you know you did your analysis.

You want to talk to customers – ask me, I was a customer once …

Have you heard this one before – I have – internal pundits claiming they know what the market wants because at one point in time (read “eons” ago, before your market segment even existed), they used to be in the customer’s shoes.

“Hey, I used to do product design”

or

“I used to be a salesman”

or

“When I used to run YYYY department”

they say ….

I have found a quick counterattack for this –

“Great, when did you do that?”

“In 1997, I used to work at XYZ Co.”

“Hummm, 11 years ago – so you mean to tell me that the world has remained stagnant and nothing has changed in those 11 years – did I hear that right? (OK, not exactly in the words above, but you get the point).

That usually stops this “we have answers here in the building” or “the way I did is how the world works”.

Yes, there are certain product decisions that you have to make drawing on your past experience, but saying that we know what to build because I was a customer once, is nothing but a recipe for failure – especially in the high tech arena, where the way you did it last month is probably not valid anymore.

It amazes me how many companies claim to be customer driven, but then they limit their product managers from traveling because the travel budget is tight, but on the other side the product development budget is a big leaky bucket funding products no one will ever want to buy.

Where do your customers get information?

When interviewing customers to determine their needs, take the time to also ask them where they get information that keep them up-to-date in their profession.

1) Are there organizations that they regard in high regard that a recommendation from such organizations is considered valued?
2) What magazines do they read frequently?
3) Do they have a blog?
4) Do they read blogs? Which ones?
5) Do they read or contribute online discussion forums?
6) Are there places which your customer absolutely disrespects or would not want to have any association with?
7) Do they read analyst reports – like Gartner, Yankee Group, IDC etc.

    You want to find out where they hang out professionally online and offline. This is because if and when you build a product/service that solves their needs, you want to make sure that the new product/service is promoted well where your potential customers hang out. So, there is more to learn in customer interviews than just the unmet needs – take it as an opportunity to profile your customer very well.

    %d bloggers like this: