Cracking the PM Interview: How to Land a Product Manager Job in Technology (Cracking the Interview & Career)

by Gayle Laakmann McDowell

Since even small changes will be seen by many millions of users, it’s important to get all of the pieces right, including the UI and algorithms.

To encourage innovation, Google has a program called “20% time.” This is a policy where engineers and PMs can spend 20% of their time on a company-related side project. To start a 20% project, you don’t need any approval; you just start working on it.

internal sites where you can post your project and try to recruit other people to join you. Many big products at Google such as Gmail, Google News, and Orkut started in someone’s 20% time.

For example, whenever possible, see your projects through to the end. Focus on understanding the things you did and the outcomes of your actions. Understand not only if your outcome was successful, but by what metrics it was successful—or not. Consider what it is that drove the success or lack of success. It’s okay to fail sometimes, but you need to know why you failed.

If you want to stand out from the crowd, you will need to show strong technical skills combined with excellent customer focus and product design skills.

One of the best ways to rise above the crowd is to have a side project like a mobile app. This gives you a chance to show your customer focus and product design skills.

Able to form a relationship of mutual respect with engineers. Companies almost always hire a product manager to join a team of engineers who already work for the company.

With all of this emphasis on technical experience, engineers are in a great place to break into product management.

Customer Focus is the most important thing to develop when moving from engineering to product management.

This means not just thinking of cool ideas, but relentlessly thinking about the target audience, their hopes and dreams, their needs, and how they’re different from you and the other people at your company.

Ask the PM or Sales team if they will bring you along on their next customer visit; they usually love to bring an engineer along.

When they ask for features or tell you what they need, see if you can dig a few levels deeper to get at the underlying motivation.

Writing story-like user scenarios for the features you’re building is another way to develop customer focus.

For these scenarios, put yourself in the customer’s shoes and imagine how the feature fits into the rest of their life. It might seem silly, but when you include details about the customer’s mindset, you can build products that fit into their lives better. For example, did Sally really turn on her computer today hoping to update her Flash player? Probably not, so maybe the update should happen quietly in the background.

As you’re preparing for the product manager role, practice describing features from the customer’s point of view by calling out the user-facing benefits.

It’s important to talk more like a PM than an engineer if you want to be considered seriously for the role.

For most of your career, you’ve needed to lower other people’s unrealistic expectations.

As a product manager, you need to let go of that instinct and allow yourself to envision a world where you’ve made the impossible happen.

Teams need product managers who can lead them into the future, building things that hav...

It might sound crazy, but for any product or feature you’re working on, think about how it could change the world. If this is hard for you, here are some tips: See if you can tie the benefits to fundamental human needs like safety, friendship, or self-esteem.

As an engineer, it’s better to prove things through data than charisma. As a product manager, you need to master both.

We’d love to think that all of our coworkers are perfectly logical creatures, but to accomplish things in the real world,

A spreadsheet with compelling metrics may not open as many doors as a statement like “I’ve looked at all of the numbers and I really bel...

When you think about becoming a product manager, there are some changes that you’re expecting: you won’t be be coding anymore, you’ll be responsible for a lot of decisions, you’ll spend more time in meetings.

As a PM, most of your work doesn’t have such concrete output.

Stephen, who switched from a developer to PM, shared that “when you’re a dev you have all these daily successes: my code works, my build passed. As a PM, you have to remember to look for it: I convinced this person, I got the team onboard, and so on.”

About the team never seeming to know what you’re working on until it’s complete (which could signal communication problems)?

you get to a tipping point, after which making decisions and working with a team become a lot easier.

Things flow more naturally. You get less cynicism and skepticism from engineers, and it enables a friendlier environment. Reaching that tipping point should be a big thought when you start a new role. Circumstances can make it easier or harder. Currently, I’m leading mobile development for the Yahoo mobile app for iPhone and Android. The team started as a designer and myself and has grown significantly.

Larry, the CEO, tried to get teams to have a single decision maker at the top, but on my team that figure wasn’t well identified. A lot of the engineering leadership had strong product opinions, which can be fine, but I’m also strongly opinionated. Working on the team involved clashes that were hard to resolve without conflict.

As an early tip, be as much of an observer as you can. Don’t try to disrupt or change things too much early on.

You’ll come to a product and have your conceptions of what needs to change, but most times there’s a culture of making decisions and reasons for

why things haven’t been high priority in the past. You don’t want to pull t...

Understand the context of things. Be more inquisitive. Instead of telling people what to do or trying to make ...

Make it so the fact that you’re there is driving something that wouldn’t happen if you weren’t there. There’s often administrative or boring work that isn’t getting done.

People agree that it should get done and has value; it just isn’t at the top of anyone’s list.

If you pick transitions where you get a sense of depth and go deeper and deeper, that’s fine, but then never violate that principle when you open a settings pane. Take the metaphor for your app and use it across the board.

Another example is that I try to make sure that, as much as possible, when you open the mobile app, you get straight to the value with as few bumps as possible. So if we’re adding a feature that won’t be used by everyone, we avoid welcome screens and tutorials.

My position is always: don’t show it up front. You can educate people, but don’t put the bump up front.

Make who you work with your top priority. They’re your best resource for learning. And since things in tech can get stressful, it’s important to make sure they’re genuinely good people. The

The thing I tell everyone is that a PM is an expert in their customer.

That’s what sets them apart from the developers and testers.

Developers on Excel don’t need to understand quants, but the PM does.

In my space, those customers are developers. And that brings me to another point: you have to really like your customers.

When I’m interviewing, the thing I check for, no matter what, is passion.

As another interviewing tip, when I’m interviewing and I want to tell if the person should be a dev or a PM, I’ll usually ask questions that can go in two different directions. You can either start designing the solution and building algorithms, or you can step back and talk about who the customers are, what the goals are, and start defining success.

If you’re interviewing to be a PM, it’s good to look at every problem starting with “Who is the customer?” and “What is success?” I do that all the time. I’ll be at a stoplight in a traffic intersection and will think “How can I make this better? Who am I making this better for?” These problems show up all the time, so you can train yourself to think this way.

I found that what I liked most in my job was to go out and explain the product in non-technical terms to our customers, and then come back and explain who our customers are to the rest of the team. I’d talk to users and potential users and try to find out what they wanted. Usually the first stage was just listening to them complain.

One of the big things was talking to a lot of awesome role model product managers. When I joined Google, I talked to Sundar Pichai and a lot of people who had been there for a while and whom I really respected for being awesome product managers.

Look at good products, see how they build products users love, then contact the people who work there and ask them how they did it.