Good Product Manager vs Great Product Manager

If you have not yet read “Good Product Manager / Bad Product Manager” by Ben Horowitz, please read that first – this post is inspired by that post. And by observing some of the great product managers in last many years. Just to be clear, product managers need not mean only professionals carrying “product manager” titles – some CEOs are great product managers and so are some engineers, business guys and investors.

 

Good product managers solve big problems. Great product managers identify big problems.

 

Good product managers always beat their target metrics. Great product managers redefine the metrics.

 

Good product managers get insights from data. Great product manager develop intuitions and revalidate with data.

 

Good product managers empathize with customers. Great product managers change customers behavior.

 

Good product managers think end to end customer experience. Great product managers define the entire ecosystem.

 

Good product managers write detailed product requirement docs. Great product managers embed the product details in engineers brains.

 

Good product managers continuously refine the product. Great product managers disrupt their own products.

 

Good product managers follow process. Great product managers break process.

 

Good product managers win many times. Great product managers fail many time to win BIG.

 

Good product managers create roadmaps aligned with org priorities. Great product managers influence in defining org priorities.

 

Good product managers say NO to 9 things out of 10. Great product managers say NO to 99 things out of 100.

 

Good product managers manage products. Great product managers build great products.

 

Good product managers listen to customers. Great product managers create customers.

Everybody I Know Needs The Product I Am Selling

When it comes to product design, there are people like Steve Jobs and then there are rest of us. Product design is mix of art and science. For lessor mortals (like me), science plays a bigger role in providing the framework for product design. There are many existing frameworks that have helped me immensely. Here I am putting down my thoughts based on my experiences and ideas from other sources.

Going back to first principles, a product is a product only if there is a user. So product design has to start with a user. Two fundamental questions to ask

1. Who is the user? What is the need or want of the user?

Everybody I know needs what I am selling
Everybody I know needs what I am selling

The first questions is the most fundamental question and analogous to what Peter Drucker said about the definition of the business – ‘The purpose of the business is to create a customer’. Well, the purpose of the product is to create a user. Given that we know so little about human beings, answering these two questions is not so simple. The most common mistake, we do here is that we assume something and fool ourselves that we know the answer to these two questions. And since we are rationalizing species, we figure out many justifications to rationalize our assumptions. The better, and less risky, way is to create a hypothesis – with a promise of testing it before moving on next steps.

[This is the most frustrating part I have experienced in the product design cycle. Some call it idea-searching phase. Most of the user needs or problems cannot be just thought of. And I have seen many people, including myself, spending many hours brainstorming about that right idea. One of the suggestions from Paul Graham (How to get startup ideas) is to think about problems faced by oneself. Or  problems you have seen firsthand. Another problem is that at times you have to imagine the future, say 5 years from now, and imagine the problems faced by your user in that world. In hindsight – how would you have come up with the idea of iPad 10 years back?]

2. Hypothesis: My solution “A” meets the need of the user

How do we test the hypothesis? The most logical way is to ask the users. But unfortunately, it does not always work (it took me a venture to realize that, fortunately I did not invest much time and effort to it). Users are human beings and they are complicated. So if you ask them “Would you like know crop prices on SMS”, they would say “Yes”. “Will you pay for this service”, “Yes”. And then you create an awesome(?) product that nobody uses or pays for. Thats when people say, you should listen to your customers and listening is not about just hearing what they are saying. It is an art to figure out what customers are saying and this might be mastered with practice. But here we are trying to simplify this process using scientific methods. This course on Human-Computer Interaction on Coursera has a lot of tricks on customer needfinding.

One of the non-so-smart-ways to test it out is to actually developing the product and try it out with the real users. And that how we are going to do it. But intelligently. How? We will create a minimum viable product that users can try and pay for. Payment need not be in terms of direct money transaction. If a user spends invests time in using the product, keeps using it and tells about it to friends, that is a kind of payment. It is up to you how you define the payment (see point 6 – Product metrics). So we move to the next question to ask.

3. What is my Minimum Viable Product (to test my hypothesis)?

MVP is easier said than done. Once thing I need to remind myself is MVP has the word “minimum”. In some cases even a landing page with right messaging or product screen shots should be enough. In others, we might need a decent prototype to show it to users and test the user experience. Or going further, our hypothesis might also test whether user pays for the product and hence MVP might also mean collecting cheque from the user.

However, in all the cases, one thing is common. We need to come with “minimum” set of functionality the product can do so that we can test our hypothesis. Sometimes there are multiple hypotheses to test and MVP also means to cut down these and test only the most important and risky ones. For instance, if the core value of a test preparation company is adaptive learning, the set of important hypotheses can be –

1. adaptive learning is effective

2. users will understand this and  pay for it

And hence these will be the first ones to test. Next step is coming out with minimum set of features to test these. Some hypotheses can be extremely difficult to test [like the example we have picked] and designing the feature set and user experience can be a daunting task.

4. How to design the product?

Even when you are convinced that the product needs the real needs of the user, it is always very easy to make a scrappy product that the user will not use. In fact, it is extremely hard to create something that user would use – and continue using it.

If it is improvement over existing product, your product needs to be 10x better than the existing one. Because there are two things always against you. a) Users resist discarding the products they are using and 2) Users resist to try new product.

On the other hand, if your product is fundamentally first one, the onus lies on you to convince your user about the need for such a product.

In both the cases, a behavior change or habit change is required. And designing new behavior is not really easy . But again, for non-Steve Jobs kind of people, there are frameworks to study and apply selectively (Notes on Behaviour Design).

Going into further details, I would go through the following checklist

Is the product value clearly visible to the user? How is it going to help the user? To what extent?

How does user start using the product? Is there a onboarding process or a starting plan? How easy it is for user to try the product?

What are the behavior changes required? How is the product tackling those changes?

How easy is it to use the product? Is it giving enough liberty to make mistakes? How much does user have to think before using the product or while using the product?

Does it give continuous feedback to the user? Is there social proof about using the product?

Had penned down some of these sometime back (7 Questions To Ask While Designing New Consumer Products)

5. Measuring the right metrics

There are two reasons to measure the metrics – to test out the hypothesis and to improvise.

Metrics give well-defined qualitative and quantitative facts to answer the following two questions

1. Is the hypothesis correct?

2. How to correct / improve the hypothesis?

If you are designing product without leveraging the data, either you are shooting in the dark or are just too good in understanding the consumer behavior and designing for them.

As Eric Ries writes in his book The Lean Startup, it’s very easy to fall prey to vanity metrics. Mixpanel and Andreessen have been very upfront in calling these Bullshit Metrics.

Again, defining the right metrics is very dependent on the type of product it is. In any case, one need to define set of numbers that can measure these metrics. Some usual metrics for software products

1. effectiveness

2. user activity

3. revenue

4. retention

5. referral

There are many others. Here is a great presentation from Dave McClure (Startup Metrics for Pirates)

One can leverage effective tools like A/B testing or multivariate testing to get more meaningful data.

6. Modifying the hypothesis and testing again

It is highly unlikely that we will get the right product the first time. And this is where the science takes over from the art. The lessons learnt till now can be ploughed back to generate better ideas. This neat figure from the book The Lean Startup explains everything.

Lean Startup Cycle
Lean Startup Cycle

Good products never get completed. They keep improving – by providing more value or better user experience.

7. Productizing

I think all the sexy work in product design end in the first two points. But the most dirty work starts when we start productizing. Productizing needs testing your product for all the corner cases, managing the product workflows, creating ancillary stuff around the product, packaging, versioning, support and many other non-cool things. Heres what I wrote while having such an experience – Lessons From Productization

A product is just a project before it is productized. It’s that last 20% of the work that consumes 80% of the time in product development.

iPhone - Productization example
iPhone – Productization example

8. Reaching out to early adopters

One of the best ways to find the early adopters is to simplify the problem so that the target market becomes very small. Analogous to MVP, we should hunt for MVM – that is Minimum Viable Market.

The ideal cycle would be as follows:

1. Discover the MVM

2. Crack it with MVP

3. Increase the scope of MVM

4. Crack it with new MVP

5. Go back to point 3

Again it is easier said than done [and I have not succeeded in doing this yet]. Be it LinkedIn, Quora, Facebook or AirBnB, this is how they have done it. LinkedIn & Quora hacked the inspiration value in the product by first going to successful and renowned people (friends). Facebook started with a single college network. AirBnB started with letting out their own apartment.

Check out this topic on quora to read about more companies and their inital traction – How Did X Get Traction? Questions about how companies got success early in their history.

Summary

To write the story in short, all the above points answer these 3 questions

1. Why? Point 1

2. What? Point 2,3

3. How? Point 4, 5,6,7,8

I think it is very important to start from “Why”. It sets the vision of the product. I also think there is no unique process to design good products. On the other hand it is still possible to design suck-y product even after using hundreds of frameworks or checklists.   It is important to be ready to fail.

To end the long post, check out this video from Simon Sinek: How great leaders inspire action

[thanks to Ashok I for reading through the draft and proving the feedback]

A Case For Ugly Applications

Reddit Sticker
Reddit Sticker (Photo credit: cambodia4kidsorg)

Ugliness level is definitely a subjective criteria. But I can take liberty in generalizing it in the similar way we generalize beauty. Website of Apple is beautiful, Reddit is ugly. If you agree, we are on the same page. Till few months back, design aesthetics was one of the primary consideration I had before working on any application. But then things changed with a simple understanding – the beauty of a website or an application is not always relevant to its functionality. And then there are live examples – Amazon.com, Reddit.com, Coolmath.com, Craiglist.com, berkshirehathaway.com, HackerNews and to some extend Facebook. Also Tally (accounting software), Google docs and Wikipedia.

Unless, the purpose of an application itself is to look good, which can be a good purpose for selling say lifestyle products, it need not be aligned with a good-looking website. If the purpose is to increase sales, the primary design decisions should be derived from the sales metrics. Amazon would have come with their design after millions of split testings and optimizations. If the purpose is engagement, that should be the primary purpose and Facebook is a good example. Coolmath website conveys that they are not marketing their products and probably their target customer is more comfortable with using such website. Similarly Reddit and HackerNews meet all the test in usability and functionality for their target audience, the look and feel does not matter.

A nice look and feel of your application or website is neither a necessary condition nor a sufficient condition. Aligning it with the purpose is more important. And the only way to do it is using real metrics based on user testing. What looks cool or beautiful can serve no purpose and your target audience might not care about it.

Lessons From Productization..

Productization
Productization - An Inspiration

Working on a million-or-billion-dollar idea is cool. Working with the latest technologies is also cool. Getting things working for yourself is also cool. Unfortunately all these things mean nothing to the users of our products. What matters to them is whether the product (or service) is actually usable. To promote to that level, our cool projects need to be productized. And this part is very boring, nevertheless very important. Here are some key steps I jotted down while productizing in last few months…

 Managing workflows – This involves thinking about all the possible scenarios that can happen while using the product. Even very simple products can have very complicated workflows. Scenarios and the use cases for these can vary depending on the kind of product, but these are typical workflows –

1. How do users reach you to buy the product?
2. How do they buy your product or subscribe to your services?
3. How do they start using it and go about using various features?
4. How do they unsubscribe?

Testing – Product can have tens of cool features and hundreds of workflows to manage these cool features. But all these need to be thoroughly validated before the product can be made usable. Testing can be the most frustrating and time-consuming part in the product design process. Catch all the bugs / gaps in your product or else your customers will (and that wont do good to your business).

User Interface / User Guide – Although user interface deserves a whole book, and there are a lot of good ones available (my fav one – The Design of Everyday Things), the simple point here is to make sure that the product is self-explanatory. Of course, we can provide a 50 page user guide on how to use the product but take that risk only if you are doing a big favor to users for using the product. When was the last time you read a product user guide?

Packaging – The whole productizing process can be called packaging, however here what I mean by packaging is the way product is presented to the customers. Does it have consistent brand identity? Does it look and feel good to gain enough credibility before user actually try out your products. Packaging becomes all the more important if you don’t have too many reference customers to talk about your product.

Pricing / Versioning – Lets say you want to buy an iPhone. Here you go – http://store.apple.com/us/browse/home/shop_iphone/family/iphone

16GB is $199, 32GB is $299 (as of today)

Thats it. There are also older versions and unlocked versions but the pricing is very well laid out.

Support – No matter how you streamline your workflows. Or no matter how much robust your products are. Problems are bound to occur. There would always be cases where users find it difficult to use your products. So the last thing, but very important thing is to put a support system before launching the product or service.

Related post – 7 Questions To Ask While Designing New Consumer Products (or Services)

7 Questions To Ask While Designing New Consumer Products (or Services)

product design
Mosquito-killer racquet kills mosquitoes using electric charge

We put a lot of effort in designing products and services for consumers. However, with our busy schedules in defining and completing the product features, we forget about some basic things we should take care while designing our products. Based on my learnings, here are few questions, I think we should ask before shipping out any product.

1. Are you trying to change consumer habits? –  Human beings are resistant to change. With so many years of life behind us, we get trained to spend our lives in a particular way. Therefore, it is very risky to ask a consumer to change the behavior just for using your product. For instance, would you risk putting a search bar on left side of your PC screen? Or say switching positions of leg-breaks and gears on your bike? These are the easy ones. But what if you are introducing a product that requires change of consumer habit? If you are selling financial planning product to a consumer who has never used one, how would you make sure he or she gets used to it? And actually starts using it on a daily basis, i.e., create a new habit? Or for instance, say you want to introduce a new pedagogy without classrooms and without books, how do you go about it? I don’t know a sure answer. Perhaps, you would want to design such that your new product works in the similar way consumers are used to work without it. How do people plan expenses when they have no financial planner? How do students learn without the new pedagogy? I guess that’s what ebook reader designer might have thought while designing the UI. How would a user turn his page with a physical book? Or why does our Smartphone camera make a noise while clicking – to mimic the real camera?

2. What are your defaults settings? – Human beings are overwhelmed with the amount of information they process everyday. Everyone wants to minimize this data processing. While signing up for a new web service, most of us don’t put a checkmark asking us to subscribe for the newsletters. That is probably we really don’t want newsletters spamming our inboxes. But now, these guys have found a solution. Now the checkmark is for NOT subscribing for the newsletters. Result: most of us still don’t click it and get the newsletter. Not that we are being hoodwinked. We are just fine with the defaults. The same trick can be applied for better purposes like designing controls of your products, designing wizards or forms etc. As the name default suggests, default settings should work for most of the users.

3. Does your product forgive users’ mistakes? – Is your product intelligent enough to interpret users’ mistakes and accommodate them? Customers use our products to get things done, not to get bothered by minor mistakes they make. Apart from forgiving users’ mistakes, products should also prevent user mistakes by using easy user interfaces. Product User Interface should provide the most hassle free experience to the user. In the world of SaaS, a painful and non-forgiving user experience would be like asking the user to stand in a long queue for something which is easily available elsewhere. Would you stand in such a queue?

4. Does your product provide continuous feedback? – When we prepare for an exam or a test, it is our natural tendency to keep testing ourselves regularly to get a feel of where we stand. Similarly, when we are driving, we keep looking at milestones to get a feel of how much we have covered and how much distance still needs to be covered. Basically, in any experience we go through, continuous feedback provides us good sense of our progress and keep us hooked on. Continuous feedback can keep user’s interest alive while using the product.

5. How many choices do you offer? – Have you ever invested in a mutual fund? How did you choose the one to invest in? There are so many options available today that an average person with limited time will go insane deciding where to invest. Same thing applies when we go buying mobiles or laptops. Being human beings, it is very difficult for us to choose when the number of options are many. On the other hand it would be unfair if we had no options at all. Imagine being offered just one class of tickets in Indian trains. So what is the right number of options one should design? Again, the mother of all answers – it depends. Not too many to boggle the mind of a user, not too few to make her feel not targeted. We should be careful in designing the pricing plans or number of configurations for your products and services.

6. What are the incentives in using the product? –  “Never, ever, think about something else when you should be thinking about the power of incentives” says Charlie Munger. If while trying the product, user forgets the reason why he is using it – we should seriously consider re-designing it. Users are literally scratching your back when they are using your product, and your product needs to do the same for them (You scratch my back, I will scratch yours). Of course, you would have build your product to change the world or with some value proposition in mind. That is the big picture. But here what we are talking about is whether the user understands that value proposition while using this product (smaller picture).

7. Are you making the user feel social? – Why is Facebook Like button so powerful? Social Proof is a well known psychological phenomenon. When we see a restaurant with a long queue, we assume that it would be a good restaurant. Some restaurants even manipulate the queues artificially by using many tricks. Similarly, if 10 of our friends like a video shared on the Facebook, there is higher probability that we are going to watch it and like it. Social media integration into your products can enable users to identify with other users. However, this also comes with disadvantages of its own.

There are many more things to take care while designing awesome products. This is not a comprehensive list. To get further insights, I would strongly recommend two amazing books:  Nudge: Improving Decisions about Health, Wealth, and Happiness by Richard Thaler and Influence: The Psychology of Persuasion by Robert Cialdini. Some of ideas I discuss here have been picked from these books. Comments are always welcome.

The Closure

Don was helpless. The high command wanted results. He had been successful in buying time till now but not anymore. Every single day without an order was becoming difficult. He had a terrible evening the day before in the company’s annual meet. Robert, the charismatic CEO of S.H.I.S. Inc had given an encouraging speech on the future prospects on the company. “We are ranked Number One in safety records. We are ranked Number One for being always on time. Number One in comfort and amenities. And this is all because of you wonderful people.” thundered Robert. Then he went into the philosophy on which the organization Second Home In Skies (S.H.I.S.) Inc  was started twenty years ago. He always liked repeating it and people always loved to listen to him. He discuss on every important project being undertaken by the company. There was no mention of DragonSpeed in the long 45 minutes speech he delivered.

DrangonSpeed was conceived five years ago – the most ambitious project the company had ever undertaken. DragonSpeed was set to beat all the records – 2x the speed of existing aircrafts, 3x the existing passenger capacity, manifold fuel efficiency and many more features while raising the safety standards of already high standards set by S.H.I.S itself. Don was brought in from academia to accomplish this. He was a superstar in his previous world with groundbreaking research and multiple papers and publications. He was offered the highest pay package, becoming the only one to draw more than even Robert, the CEO. He was given the best twenty engineers available in the organization. The board was gung-ho about the project. The revenue forecast for other aircrafts were dwarfed by the DragonSpeed’s numbers. The company was betting on it to get into the billion dollar valuation club with an IPO. The shine of IPO money was already visible in the eyes of board members.

Don team constituted brightest engineers graduated from leading educational institutes with excellent academic and professional records. They were all hungry for success and considered themselves lucky to be part of such a huge project. For most of them, it was the first job after graduation. They were all ready to take off for high-flying careers.

Fast forward five years. The DragonSpeed was ready to fly. The team delivered the DragonSpeed as was required. The simulator tests confirmed that it met all the specifications set. It had however slipped the schedule. By whopping two years. This was just one of the problems. There was nobody to buy or rather sell the Jumbo. The sales team of S.H.I.S had never sold anything like DragonSpeed and none of the customers they worked with wanted such an Aircraft. The company hired other marketing agencies to sell the plane. “My customer does not need such high-speed but need higher fuel efficiency than what is provided by DragonSpeed”, expressed one of the Marketing Associates located in Far East. Another associate suggested some more customizations. Don’s team worked hard to meed these requirements, but unfortunately the list of such requests was growing faster than they could work on.  In addition, Don was having hard time in managing the expectations of the team members. The DragonSpeed was as ready it could be, but had still not touched the skies. The high command needed a customer to fund the final flight testing of the DragonSpeed. It was a painful experience for engineers to watch their dream machine lying idle.

One early morning, Don found a note in his mailbox to meet Robert. “Don, we have really tried very hard, but nothing seems to work out. The board of directors have decided to end this project. We would not be able to invest in it any further. I am sorry, you will have to leave the organization.”  Don was given a day to clear up his personal belongings. The remaining twenty engineers were allocated to other revenue-generating projects.

This was the closure of DragonSpeed.