No Batteries Included - Shreyas Doshi's blog

Slides from my talk at SVPMA: How to get that next PM job

Heres a presentation from a talk I gave at Silicon Valley Product Management Association's monthly event in March 2010. Hope you find it useful.

If you liked this preso and 139 slides are just not enough for you, check out an extended version of the preso on SVPMA's website (pdf). This includes 50+ additional slides that didn't make it to the main preso.

We are also hiring product managers at all levels at Google. Email me if you're interested in applying for some of the best product positions in the world.

 

Why you should always work on things that actually have engineers

 

 -Shreyas

Why Product Management shouldn't report into Marketing

-Shreyas 

 

Make Opposition Matter

Conflict magnifies and illuminates who you are. It seizes and startles you into seeing what makes you uncomfortable. It pushes your boundaries -- intellectual, emotional, and physical. Conflict, if treated properly, offers the chance to change your mind altogether.

When faced with conflict, explore the possibility that opposing forces can both be true simultaneously. Taking this perspective immediately dissolves animosity and piques curiosity. You find yourself wondering, "Whats their truth? Where is the value on their side?" When you finally give up the belief that yours is the only truth, it changes the game forever. Now you're in a position to see what new truth you can create together.

I recently came across these lines in the book Change the Way You See Everything through Asset-based Thinking (page 73 - Make Opposition Matter). These lines strongly resonated with me because they describe the attitude that I have consistently seen in the most effective product managers. When faced with conflict, these product managers:

• don't squelch their curiosity. they do try their best to understand what the other person is saying and why
• don't feel the compulsion to be right. they do feel the compulsion to do whats right, based on their new insights
• don't view the process as adversarial. they do view it as an opportunity to make their product better than they had imagined by themselves

Managing conflict is an integral part of a product manager's job description. So the next time you are facing conflict, do what effective product managers do - your users will thank you for it.

Recent experience at the Nike store

I recently walked into the Nike store at the Great Mall in Milpitas to return a pair of shoes. What I saw next was brilliant because it was so simple and obvious once I saw it. Along with my return receipt, I was handed a coupon for 20% off one item - valid for 2 hours only. And since I was at the Nike factory outlet store (theoretically with already lower prices on many items), I felt a compelling urge to browse through the store to use this coupon. Not only that, I felt "special" because this coupon was just for me - the other shoppers walking in through the doors (without a return item) could not avail this generous discount.

The brilliant thing about this is that the folks at Nike used a simple incentive to convert me - someone who only wanted to return an item that day - to an actual buyer. This is the first time I have seen such an incentive, though I wouldn't be surprised if it has been tried elsewhere. Anyway, the point is that most people would probably end up at least browsing the store to find something worthwhile to buy with the coupon. And many of those would probably end up buying something (I bought 3 items - the discount was for one item only). Regardless of whether Nike ends up overall net positive with this incentive, and whether they continue running it or not, this is a great example of doing something different with an annoying experience (i.e. returning goods), which is pretty much the same EVERYWHERE.

There is some inspiration in here for product managers - especially those working on web products - after all, can you think of experiences that are pretty much the same (i.e. universally bad) everywhere on the web? How about account creation or SMS code verification as examples? But there is hope. Tatango provides something different and better to the tired experience of creating an account. Twitter generates a code that employs only the first letters of each triple-tap key on a normal mobile phone (i.e. 'a' from 'abc', 'd' from 'def', etc.) - so that, wait for this... you only have to tap once for each letter in the verification code!

What are you doing with your product thats equally brilliant?

Product Marketing Manager != Product Manager

A cursory glance through "Responsibilities" section of the job postings for "Product Manager" and "Product Marketing Manager" reveals that there is a great deal of confusion between these titles. Many postings that advertise a product marketing manager position are really looking for a product manager, and vice versa.

The role of a product manager, as I have recently described here, is fundamentally different from that of a product marketing manager. There is always some overlap, but, in general, they demand a different set of skills for success.

I can best describe my view of the difference in the responsibilities of a product manager and those of a product marketing manager by using the well-known 4 P's model of marketing activities. In the scope of activities defined by the 4 P's, the product manager is responsible for "Product" and the product marketing manager is responsible for "Price", "Place", and "Promotion". Its a simple distinction and it almost always works.

What does a product manager do?

As a Product Manager, I regularly meet people who find it hard to understand and/or describe what a (software) product manager does. I don't blame them. Very early in my own career as a product manager, I would embark on a monologue for 2 minutes when asked what a product manager did, probably leaving the listener more confused at the end than when I started off.

With experience, I am now able to describe the essence of what a product manager does in one line.

Statement 1: The product manager defines what product the engineering organization should build

"what" is the operative word here. The engineering lead/architect defines the "how", the project manager defines the "when", the product manager defines the "what".

Product managers seem to do a lot of other things, so am I oversimplifying or even inaccurately depicting the role of a product manager? The answer to that is that it depends and I will explain it in two parts.

I. A *lot* of what a product manager does really just supports the essence that I have described above. Activities such as:

a. competitive analysis
b. creating the business case (the "why" of the product)
c. talking to customers, users, executive management, other functional groups within the company (legal, marketing, biz dev, PR, ...)
d. writing PRDs
e. prototyping
f. working with user experience design

Each of these activities helps the product manager understand what product needs to be built and then describe it in a way that engineering can build it. Hence, these activities all support the essence I have stated above.

II. Some other activities of a product manager don't fall so cleanly into the essence. Examples include:

a. Supporting the sales team in deal pursuit
b. Clearing obstacles in product development (funding, resources, ...)
c. Educating people about the product (data sheets, presentations, ...)
d. Working on partnerships

These and other such activities may be a necessary part of a product manager's job, but they are not sufficient without the essence. These activities can be bundled under the following description

Statement 2: A product manager also supports other parts of the organization in order to ensure product success

The role of a product manager is probably one of the most misunderstood roles in the industry today. I have seen people with a product manager title performing the role of a marketing manager, project manager, business analyst, solutions engineer, account manager, business development professional. Conversely, I have seen people in the role of a tech lead, business analyst, marketing manager, program manager, engineering manager perform the role of a product manager. Whether or not your title says it, and whether or not you know it, if you are doing what I have described in statements 1 and 2, you are a product manager.

On anecdotal evidence and product input: how not to build crappy products

Every once in a while, one finds oneself in a discussion over an important topic, having an opposite view as that of a colleague, friend, or family member. This is almost never a bad thing in my view. In the business world, for instance, I would not enjoy being in an organization where no one challenges my views or where I cannot challenge others'. Theres one aspect of such discussions, however, that I try to avoid as much as possible. It is best illustrated with an example.

Lets say I am having a discussion with Joe (a colleague) about the features of our new consumer electronics device. Now, lets say that I maintain that including a certain feature is not justified as it is an advanced feature that we've found is unlikely to be used by most of our users. Joe retorts with "Thats not true! My mother-in-law, who is not at all tech-savvy, regularly uses (and loves) this exact feature in our competitor's product". Hence, I must be wrong and Joe must be right.

While the flaw in the above reasoning should be obvious, its astounding how many times, as a product manager, you will find yourself in a discussion like this. Furthermore, this problem is often exacerbated by the HiPPO (Highest Paid Person's Opinion) effect during product reviews.

Its critical for you to identify whenever you are in a discussion of this nature and take steps towards ensuring that it doesn't lead you to the creation of a crappy product. To counter the threat of anecdotal evidence, follow this recipe of questions:

Does this increase product appeal and/or value?

If yes, does this increase the complexity of the product?

If yes, do the current metrics (quantitative, qualitative, or both) justify this complexity?

If yes, can this be built such that it doesn't adversely affect other, more critical metrics?

If yes, build it. If not, wait until the next version of the product and ask these questions all over again.

Note that I am not suggesting that you ignore input or anecdotal evidence. However, I find far too often that product managers (especially those new to the field) don't say No at the right time. By following a consistent evaluation process - with the underlying strategy of keeping things simple - you can avoid building a crappy product.

On being right and on Product Sense

You don't have to be completely right about every aspect of your product the first time around. Your chances of being wrong are in direct proportion to the novelty of the product you're building. An obsession with always being right usually leads to inaction. Especially for web products, the gains from always being right are almost always eclipsed by the losses resulting from your sluggishness. You can be wrong sometimes and still build consistently successful products (and companies) - as long as you improvise and shed the "ship and forget" attitude. If, however, you have a knack for being wrong most of the times, you are probably lacking a quality called good Product Sense.

Product Sense is not always an "either you have it or you don't" thing. You may demonstrate great Product Sense on consumer web products and completely suck at building ergonomic chairs. Its a function of your experience, proclivities, and intelligence. I believe that the first two of these factors are contextual, so if your current context doesn't allow you to demonstrate the full potential of your Product Sense, I would suggest changing your context so that its better aligned with these factors. Once you have found a job that better matches your experience and proclivities, do the following:

1. Strive to understand your field better than anyone else
   
2. Strive to understand your competition better than anyone else
   
3. Be completely honest to yourself
4. Be empathetic of the entire cross-section of your users or customers
   
5. Be obsessive about product metrics
6. Avoid the temptation of drawing the conclusions that support your feelings and views. Be objective
7. Be curious 
8. This one is worth repeating - Be curious
9. Learn, really learn, from your product experiences

Of exceptions to patterns

TO WHOMSOEVER IT MAY CONCERN. I humbly propose this law so that we can have more productive conversations.

An exception to a general pattern doesn't suggest that there isn't a pattern

Corollary

An exception to a general pattern doesn't suggest that the exception is the pattern