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.