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.