Sunday, December 15, 2013

Product Marketing to Product Management

Recently I had a conversation with a student graduating from Kellogg. The tale was pretty familiar - ex-consultant with engineering degree and MBA wants to transition to a Product Management role. Larger companies like Google, Amazon, Microsoft might give him/her opportunities, but smaller companies are very wary. How does one make the transition then?

Why are smaller companies wary?
Very simply put, they need someone to be productive as soon as possible, and be proficient in many aspects to be effective as a Product Manager (design, engineering etc.). And no experience prepares you for Product Management as does Product Management itself. So anyone with even some Product Management experience has a huge advantage. Experiences that help are - Engineering, Design, Marketing, Strategy. You will likely get just a subset of this in Consulting and through an MBA.

So what can one do?

Two routes come to mind
1. If possible, leverage your domain expertise along with other experiences. When I was recruiting for Lattice, I lucked out that I had taken a class in Predictive Modeling in Marketing, and done an independent study on applying the techniques I had learned to solve a similar problem to what Lattice does. I did this out of pure interest - helping @ Lattice was a lucky co-incidence.
2. Move into in adjacent role in the company in which you would like to become a Product Manager. Professional Services, Pre-Sales and Product Marketing are good roles. I especially recommend Product Marketing as you get to know the product, the customers and the market pretty well - if you are doing your job well, that is. You also build political capital and a good reputation through this route, which should help you make the transition.

So what route worked for you? Comment and let me know

Saturday, November 23, 2013

Are you giving your customers Cookies or Yoghurt?

The other day I was hanging out with my daughter Simran. She comes up to me and says - 'Cookie?' 

I said 'No Simran, you had a cookie in the morning.'

Then she comes back and says - 'Cupcake?' 

And I said no. 

And so on - till I asked her 'Are you Hungry?' and she said 'Yes!' 

I asked if she would like to have Yoghurt and Grapes - to which she readily agreed.

Which made me think of how much this interaction was like my life as a Product Manager. Customers - and customer support/account management teams - hardly ever come to me with a problem. It's always a feature request - I need this shiny new widget, and I need it now. It is my job to understand the problem they are trying to solve, and then determine what is the best solution for this. And the best solution depends on a lot more factors than what the customer wants - what takes the minimum effort, is consistent with the overall product, solves problems for the market generally.

So next time your customers ask you for a cookie - don't just give in. They might be happy with Yoghurt - or even broccoli!

Saturday, October 26, 2013

What I have been building at Lattice Engines

Some lessons on Networking

A few months ago, I had written a post on Recruiting for a Startup role. Which involved a lot of Networking. Ever since, I have a few more reflections to add on the topic.

  1. Recruiting network lasts - I had been networking for a while before searching for a job. But even the connections I had reached out to explicitly seeking a job have been great in staying in touch. So don't approach networking during a job search as a transaction affair. There are several roles that I recruited for, where I was not the right fit. But those people have offered me help, advice, guidance on my current role at Lattice
  2. Introductions - this is more expressing a pet peeve than anything else. If you reach out to a friend  or acquaintance (lets say its Mr. F) to make an introduction to someone (lets say Mr. VIP), and your friend sends an email introducing you to Mr. VIP, make sure you reply to email expressing enthusiasm for being introduced to Mr. VIP Right away. Definitely within 24 hours, and ideally before Mr. VIP responds. There have been cases where I have introduced someone to Mr. VIP, and said 'I will let you two connect' - but NO ONE followed up.
  3. Same way, if you are reaching out to someone for help, you have to make time for them. Canceling on someone repeatedly, or requesting several time changes makes is clear what your priorities are.

Saturday, October 19, 2013

Product Manager - a Vague Job

Look here for a Sample Job Description of a Product Manager (from

As Product Manager, you will guide a team that is charged with a product line contribution as a business unit. This extends from increasing the profitability of existing products to developing new products for the company. You will build products from existing ideas, and help to develop new ideas based on your industry experience and your contact with customers and prospects. You must possess a unique blend of business and technical savvy; a big-picture vision, and the drive to make that vision a reality. You must enjoy spending time in the market to understand their problems, and find innovative solutions for the broader market.
You must be able to communicate with all areas of the company. You will work with an engineering counterpart to define product release requirements. You will work with marketing communications to define the go-to-market strategy, helping them understand the product positioning, key benefits, and target customer. You will also serve as the internal and external evangelist for your product offering, occasionally working with the sales channel and key customers.
A product manager's key role is strategic, not tactical. The other organizations will support your strategic efforts; you won't be supporting their tactical tasks.


  • Managing the entire product line life cycle from strategic planning to tactical activities
  • Specifying market requirements for current and future products by conducting market research supported by on-going visits to customers and non-customers.
  • Driving a solution set across development teams (primarily Development/Engineering, and Marketing Communications) through market requirements, product contract, and positioning.
  • Developing and implementing a company-wide go-to-market plan, working with all departments to execute.
  • Analyzing potential partner relationships for the product.


  • 3+ years of software marketing/product management experience.
  • Knowledgeable in technology.
  • Computer Science or Engineering degree or work experience a strong plus.
  • This position requires travel to customer and non-customer sites in North America and Europe (25%).

What this job description - and indeed any PM job description - does not answer is: what are the activities you will do on a day to day basis? Would you run usability tests? Attend sales calls as the product expert? Run the Product Steering Committee meeting? Help shape the company's strategy? Help select the shade of blue of the Reports button?

Product Managers are both very detailed and very strategic, and so need to be strategic about how much time they would spend on each activity. Here is a framework that I use to determine how much I need to engage.

On X and Y axis, I plot my initiative and expertise in the topic, and initiative and expertise of other people in the company (THESE ARE JUST SAMPLE ACTIVITIES/VALUES). This does assume all activities are equally important, but let's use a simplifying assumption for that, for now.

The orange circle indicates activities I can trust other people with, and contribute, when asked for my input. I might contribute on occasion, or engage when I think that some product needs/objectives might not be met, but I largely stay away.

The green circle is my core areas of focus.

The red circle is the danger zone - the areas where no one has good enough expertise. Either I need to develop my skills here, or make sure we get someone who has this expertise.

I don't formally track activities on such a graph, but is it on a subconscious level on day to day basis.

What decision framework do you use when you determine where to spend your time?

Tuesday, October 8, 2013

Dear JIRA: Your product's usability sucks

Who asks for dates in this format? Where were you when the rest of the world was asking for dates? You are never going to get a good date and will die alone (pun intended - my master sense of humor at work :)).

Saturday, September 28, 2013

What I learned at McKinsey

After nearly 2 years of total time at McKinsey, I joined Lattice Engines as a senior product manager. And I love my new job! But in the midst of this new job, I have often reflected on what I learned from my time at McKinsey. Was working there after business school really valuable?
Not even counting the network and brand, and the friendships I developed while at McKinsey, I completely believe it was. Just like Business School, I answer this question by the following statement - if the experience significantly changes (and improves) the way I think and act, I believe it is valuable. In particular, there are some elements of the McKinsey culture that have become part of the way I work. I will classify them under two categories: Work style and Communication and Interpersonal skills
Work Style
  1. Efficiency and Urgency: I have a sense of urgency to do things faster, more efficiently, that I did not before. At McKinsey, there was a constant emphasis on using the 80-20 rule to have maximum impact with less effort; this was the only way you could actually complete the work assigned to you. That has completely rubbed off on me, though I do sometimes push for getting things done in an unrealistic timeframe.
  2. Scheduled PS sessions: We had 2 problem solving sessions scheduled weekly, to proactively think through problems we might face. Having these on the calendar forced us to come up with answers with artifical deadlines, and kep the project moving forward. Also, these sessions gave us a way of stepping back and reviewing the progress as a group, look at the big picture, get input from multiple stakeholders and make better decisions about the future of the project
  3. First day answer: There was always a urgency of getting to an early answer. On a first day, it was just a hypothesis; you will spend several weeks proving or disproving the answer. But having to come up with an  early answer makes you focus on what are the things you need to do to come up with a refined answer, and use facts to back it up. In addition, this helps bring around a focus on Iterative problem solving and end-product focus: We began every study with a storyboard; an outline of what the final product (i.e., the final presentation) will look like. This helped us understand and prioritize our analysis, and also help drive prioritization of work
  4. Put something on paper: There was also an emphasis on coming in with a perspective, and in particular putting something down on paper which forces people to react. This is a powerful technique because most people are overwhelmed with too many things to handle, and if you ask them something, they might not put too much thought into their answers. Putting an opinion in front of them forces them to react, and either agree or disagree, and produces better results
Communication and Interpersonal skills
  1. Bucketing or 'chunking': Give someone a set of six points, and they will not likely remember anything. Give them three points, with two sub-points each, and they will likely remember what you said. This is probably the most useful habits I developed; rolling up points into themes, and communicating in sets of 2-4 themes at a time. This has made my presentations and communications so much more effective, that this alone is worth the time spent at McKinsey.
  2. Respect for different personality types: McKinsey lives on MBTI types; people use MBTI as a way of communicating how they work, and to understand how they can work better with others. For me, it helped in two major ways. First, even though I don't use MBTI types anymore, when I start working with someone, I try to get a sense of how they like to work. I also respect people's preferences more, and try to understand what they say based on their personality. Second, MBTI has helped me understand myself better. I know that since I am INTJ, I need time on my own to think through things before meetings, I love to organize things and build plan before I proceed, and that I love to think big picture, but need to watch out for the details when I work. 
  3. Team Learning: A unique thing we did close to the beginning of each project was to hold a team learning session, where everyone mentioned their MBTI type, their learning goals, and how they like to work. This session was very valuable, both as a team-building exercise, but as a way to surface information that can help the team tremendously in the future, to avoid misunderstandings, and to support each other in achieveing individual goals
  4. Dialogues and handling different points of opinion - At the end of my one year learning workshop, I learned two very valuable frameworks for conversations. One was treating dialogues as a balance between listening and asserting, and techniques to make sure that you do each of these more effectively. Second, I learned a way of handling different points of opinion by getting to an understanding of the facts and assumptions behind each persons arguments, and understanding what assumptions you need to test for everyone to get on the same page

The 'Easy to Use' myth

One of the most important requirements for any new product is that it should be 'Usable' or 'Easy to Use.' But in my role as Product Manager at Lattice Engines, I have always been puzzled about what this means to the product. There are really three different flavors for a product being easy to use; in this blog post, I discuss each of them.

Easy to get started

The most common meaning of easy to use, is easy to get started with. The most important criterion are:
1. The various controls you want to user to use more frequently, are easily available
2. The feature works as the user expects

For example, if you are creating a new feature that enables a user to search a e-commerce website. The expectations for this feature would be:

1. The search box is in the normal place - top and center, or top and right
2. The user can enter a text and just click enter, and expect the search to give you results
3. There is potential auto-fill and/or auto-correct functionality available
4. This feature works in a similar manner across all platforms and devices used to access your site.

In other words, the control and behavior mirror the mental model of how users expect your feature to behave.

Easy to learn/master

Let's say you are designing a product with lots of advanced features. Your users need to often achieve a certain level of mastery to start using those features. These require a different set of consideration; you need to provide everything to the user to learn and master these features. This includes

1. Training/tutorials to walk through the advanced features
2. Clear separation of advanced features from the most common features
3. A non-threatening learning environment; by this, I mean that the consequences of using the features should be clearly visible to the user, and he/she must have enough information to decide whether to take an unfamiliar action, and ideally know that they can always reverse any change they make

High productivity after Mastery

A last important aspect of ease of use is what sort of productivity can the user achieve after he/she has learned the advanced features. A prime example is excel; there are tons of shortcuts which require lot of effort on part of the user to learn. But for the advanced users of excel (e.g., consultants, investment bankers) the shortcuts increase their productivity tremendously.

There is a trade-off

These three objectives are not mutually exclusive; given limited resources, and design considerations, you have to decide which is most important, and design for that case. For example, I was recently designing an advanced module at Lattice. My initial instinct was to design a very simple, intuitive interface, and I got pretty good feedback from most potential users. What I did not realize that a very small percentage of our users would use this module; those that would, use excel for such tasks. Designing an excel-like interface increases the effort required to learn the interface upfront, but helps them be much more productive when they have gained mastery.

Thursday, April 18, 2013

Why I don't normally listen to the news - but am thankful for journalism

I don't listen to the news. I don't watch CNN, Fox, or any news channel. Occasionally I will glance at the NY times or CNN. Why do you ask? In one word - negativity.

The news media excels in making us aware of all the negative things going in the world. From terrorism, to the obesity epidemic, to the attention deficit order, to floods etc. Hardly ever does one see a positive piece of news. And why so? Negative news sells. Negative news makes people angry, and turn back into the channel. Negative news can be sensationalized.

Now I don't want to pretend that  burying my head in the sand is the answer. But I do think that most people pay too much attention to the news. I find a balance by occasionally glancing at the news, and knowing enough to make important decisions e.g., who to vote for. But that is what I want to limit it to. I would rather spend time with family, read tech blogs, work hard at my job, and generally remain happy, than remain 'informed.'

One exception - the recent Boston acts of terrorism. That is the one time I was thankful for journalists, and news sources such as NPR. Not Twitter, NPR. Why? NPR, and other news outlets check their sources. Twitter was already abuzz with rumours 30 minutes after the incident  12 dead, while only 2 people were confirmed dead. And so on and so forth.

So thanks for journalism and the news media for keeping us informed when it counts. In most other days though, I shall continue to ignore 90% of what you say.