The only “framework” you need for PM interview questions

When I’m coaching product managers on their interview skills, the question I get asked most often is, “what framework should I use for this question?”

My answer is, “how would you do it if this was really your job? That’s your framework.”

There are a lot of fallacies about product management interviews. The worst one, by far, is that you should memorize and use frameworks when answering a question — that frameworks will lead you to the “right” answer so you can pass this part of the interview.

Let me show you why this is wrong. Imagine you were asked this interview question: “How would you increase the number of active Gmail users by 25%?”

Here’s the beginning of a typical “framework” answer:

First, let me brainstorm some user groups and their problems, then I’ll pick one, dive into their problems, and brainstorm solutions based on those problems. Then I’ll evaluate tradeoffs, pick some key metrics, and make some wireframes.

If increasing Gmail active users by 25% was actually your job, do you think those steps will solve the problem? Are those the steps you’d really follow? Do you think that’s how Google improves Gmail? No, no, and no.

To put it another way — imagine the interviewer is making a decision on your interview. Based on your answer, what kind of coworker would you be? How would you work with other people in the company? Could you be trusted to make the next, great Google product? There’s no way to tell, so you’re not gonna pass this interview.

If you want to get that job offer, you have to be the best candidate they interview. You’re up against dozens or hundreds of other people. You have to be better than all of them — the best at creativity, user-centeredness, analyzing, strategy, and communicating. No framework will help you be the best candidate.

Your job as an interviewee is to show that you can do the job better than anyone. Frameworks show how you can get an answer, but they don’t give any indication about how you’d do the work — and the whole point of an interview is to demonstrate that you can do the work.

So get off the “framework” train and try this instead. The person across the table from you isn’t looking for your framework. They’re trying to understand if you can do the job.

That’s why you should answer this question instead:

What would I do if this was my job?

And when you answer, make sure you answer questions questions like:

  • What steps would you take? Why would you do those things?
  • Who would do those steps? What resources would you need for each?
  • How would you know when to move from one step to another?
  • How would you know when you’re done?

For example, here’s how I’d start my answer to the Gmail question:

First, I’d get aligned with my team goals — what metrics, objectives, or user groups are we targeting? I’d research that goal with users — usability tests, surveys, and interviews — to learn more about the problem and develop hypotheses. Then I’d work with my team to brainstorm, prototype, and test potential visions for the product. I’d build out an MVP, confirm my hypotheses, then work towards shipping the final version of the product.

That was my off-the-cuff answer for how I’d do the work. No framework. No memorizing. I barely even thought about it.

If you’re thinking, “wow that’s a great framework,” then you’re on the wrong track. The point is — this isn’t a framework. These are really the steps I’d take to do this if it was my job.

I can give that answer spontaneously, without a framework, because I fucking know how to be a product manager. It works for every question.

Let’s go a little deeper though. With an answer like this, you’re showing your product management capabilities to the interviewer. As a PM, you’ll be working alone with very little management or peer oversight, so your peers and managers need to know you’re capable of doing the job. You can do that in your answer by telling them that how you’d really the work.

As a bonus, you don’t have to memorize anything. You only have to think about how you’d do the job. This works for any kind of interview question. Extra points if you can drop in a quick story of a time you really did this.

You’re probably wondering how you can cover all those topics — goals, research, design, vision, MVPs, etc — in one interview. Easy — you don’t. Instead, just make reasonable assumptions to help get you from one step to the next.

For example, you can’t do research in the interview, but you could make two or three guesses about what your research would uncover, then pick the most reasonable one. It’s not about being “correct” — there are no right answers. It’s about showing how you’d do the work.

So that’s it. If you want to be the best candidate — if you really want the job — drop the frameworks. Focus on communicating how you’d do the work. That’s the only “framework” you need.

No, because…

It sucks when you don’t get an invite to the big party. It sucks more when you don’t know why.

Tell me if any of these look familiar. These are pieces of actual rejections I received.

  • While your skills and background are impressive, we have unfortunately decided to proceed with other candidates who more closely fit our needs at this time.
  • We regret to inform you that after careful consideration we will not be moving forward with your candidacy for this role.
  • Although your background is impressive, we regret to inform you that we have decided to pursue other candidates at this time.

I’ve been applying to lots of jobs and getting lots of rejections. Which is kinda fun. It’s a game to get as many rejections as possible.

I stole that game from Stephen King who famously stuck all his rejection letters on a nail on the wall. My inbox is filling up with rejections. My method is not as visceral as a nail-on-the-wall, but it’s still fun.

I’m comfortable being rejected. I’m comfortable rejecting others. I know there will be many more rejections until I find the right employer and the right employer finds me.

But when it comes to the actual act of rejection, I have a big complaint — the complete lack of details about why I was rejected. I feel qualified for these roles. That’s why I applied. But the employer did not. Why not?

  • Am I underqualified? Overqualified?
  • Do I lack specific experience or knowledge?
  • Did I make a mistake or typo somewhere?
  • Did I misunderstand the problem that this company is facing?
  • Do they think I’ll be too expensive to hire?
  • Is there something in my background that they didn’t like?
  • Did they do references checks? Who said what about me?

I’m not looking for a second chance or extra consideration. Rejection is a part of life that I’m fine with. It stings, but I get over it quickly.

But I want to grow. Being told “no” gives me no information about how I can improve. What could I have done differently to get this job? What should I do if I want a similar job from another employer?

How can I get a “yes” next time?

Here’s what I want: better rejections. Tell people how they missed and how they can improve. Let them grow. And hopefully that no will become a yes.

What if my rejection said this:

  • While your skills and background are impressive, we have unfortunately decided to proceed with other candidates who have more experience with enterprise email products.

Suddenly I have real feedback that helps me understand what’s happening. The role that I thought was focused on guiding product managers was really focused on guiding email products. If I really want to work for this company, I should level up my skills in enterprise email.

There’s another way to interpret that rejection. Perhaps the employer doesn’t want to invest in me — to close the gap between “where I am” and “the perfect candidate.” In that case, I don’t want to work for that company under any circumstances. That’s better for both of us.

I’ll give an example from my own experience. My engineering team was eager to try a new programming language and wanted to build a new feature with it. It would take a few weeks, but this was a small test that could help show them the way forward with the new technology.

I said no for a variety of reasons — it was a high risk project, it would take weeks longer than doing it the old way, and it was unclear that this was a “step forward” versus “adding skills to your resume.”

And this opens new discussions — what are the projects coming up where it’s appropriate to make this change? How do we minimize the risk and effort to do this? How can we be more certain that this is the right change versus a vanity project?

I know that the rejection hurt. But it was more than just “no” — it was an explanation about why the answer is “no.” And (hopefully) they learned something that will help them make this a “yes” the next time.

One last thing. When you explain why you chose “no,” it’s easy to think that the recipient understands your explanation. But often that’s not true.

The response of “we decided to proceed with other candidates who more closely fit our needs” makes sense to the HR person who rejected you over someone else. It doesn’t mean anything to the person who got rejected.

This is eerily close to my thoughts on “regret.” I’ve sent emails like this –“we regret to inform you that we have decided to pursue other candidates.” I felt no regret rejecting you.

And the person who got rejected — they don’t feel the “regret” and they still don’t understand why they were rejected.

So do more in your rejections. When you say no, explain why. Make it clear how the other person can grow and improve. Help that person understand your considerations that led to “no.”

Help them get to yes.

The metrics will take care of themselves

As product managers, it’s our job to “move the metrics” — increase retention 20%, improve conversion rates 10%, and so on. So we do things to move those numbers.

You added detailed tracking to your apps. Added social features, notifications and rewards to hook people. Launched targeted email and ad campaigns. Fiddled with features in the hopes that one of your changes will hit the jackpot.

You did these things because you thought those would help you hit your goals. Someone higher up said that the goal was growth, so you did what you thought would work. You did what you were told to do.

This is the banality of evil products. We built products that serve metrics because someone told us to. If our goal is to move these numbers, we should do whatever it takes to achieve those goals.

The consequence is that we build boring, artificial products that solve our problems but don’t solve our users’ problems — like viral loops, endless notifications, email spam, rewards, or messages that disappear after 24 hours.

We should stop calling these things “products” and “features.” They’re gimmicks, phishing, scams. They’re not delightful or fun. They’re boring. Deceitful.

Products that solely serve metrics are the true evil products.

It’s easy to convince yourself that you did the right thing building products like these, especially if you hit your numbers. “Check out that growth we got with our new email targeting. We hit our goals!” Sure, it’s growth, but it’s artificial.

I’ve done that. I felt good about it for a bit, but in my heart I knew that it’s not real product management. The goal of product management is not to “hit the numbers.” That’s not the career I signed up for.

The goal of product management is to create amazing products that people love. Products that solve their problems in a delightful way. Products that resound emotionally with the people who use them. That’s the job I love, and that’s why I chose to be a product manager.

When you have a deep understanding of your users’ problems and create a great experience that solves it — that’s product management. If you do that, “hitting the numbers” will be your reward for being a good product manager.

If you do that and you can’t hit the numbers, then you don’t have a product. That’s ok. It’s also good product management to know when to keep trying or when to give up. Not every person and not every problem can be solved successfully with a product.

But if you can’t hit the numbers and try gimmicks like showing an alert when someone tries to close their browser tab, that’s when you’re building evil products.

Don’t give into evil product management. Know your users. Understand their problems. Build solutions they love. Do that, and the metrics will take care of themselves.

On being remote

When tons of companies are doing all their work from home, why do they have offices at all?

I want to commend Twitter for allowing some employees to work from home indefinitely. Why hire locally when your employees won’t be in your offices? But they’re only going part of the way there. Many jobs will still be local only.

Many other companies are doing the same old thing — hiring in places where they have offices. When this virus thing is over, they expect you to go back to that office.

Bullshit.

Every company should be working towards life without offices. If you can hire and work remotely, your company should do that.

Let’s take COVID-19 out of the picture for a moment. Why have an office at all? The usual arguments for offices are:

  • I want our team to have discussions and serendipity by being around each other
  • I like to hear the phones ring/conversations/business happening
  • I want our office to look impressive for prospective customers or employees
  • If I can’t see my employees, how can I keep them accountable? They’re probably slacking

Most of the pro-office arguments are about seeing your business happen. If you can’t see your business happening — if you’re not around each other — then business isn’t happening.

And there are naive arguments against offices:

  • We have the tools to run our business from anywhere there’s a wifi signal
  • Offices, especially open ones, are full of noises and distractions. They decrease productivity and happiness
  • Money spent on rent and mortgages could be used to improve your employees, products, or profits
  • Your employees already spend a lot of time slacking in the office

Most of these arguments are about trusting your employees to get their shit done. Does it matter where work happens if we can work from anywhere?

But none of these feel right to me. You’re not gonna convince the CEO that you should go fully remote just to save on rent.

Let me give you my best, less obvious reasons for having a remote team.

First, talent is distributed globally. You can find capable, skilled individuals in every part of the world. Many speak fluent English, and you can pay them competitive rates for where they live — often far less than hiring local employees. Inexpensive and quality employees? Yes please.

Next, most work is individual, so it doesn’t matter if your employees are in the same time zone. You should create remote-friendly processes that keep employees accountable, can happen asynchronously, and can happen wherever your people are. Why do you care when your employees work?

Also, what are you actively doing to create the discussions and ideas that drive your business? If you’re expecting your company to grow and innovate because they’re physically near each other, you’re doing it wrong. How are you building opportunities for your company to be a better business?

The last and least obvious reason is — a new generation joined the workforce, and they’re totally comfortable communicating digitally. They grew up with text messaging and group chats. FaceTime is a habit. What do we need an office for anyway? You boomers who need an office are behind the times.

For all the companies with listing jobs that say shit like “temporarily remote, but must be local” or “NYC only” can bite me. The nature of work has changed. Great employees are everywhere. And you’re giving the finger to a generation of people who work differently than you.

Yes, I know there are plenty of businesses and services that will always be local. When you lock yourself out of your home, that locksmith can’t fix your problem remotely. (Well — they can’t yet. Give it time.)

However, I see a lack of imagination here. There are plenty of companies that could be run fully remote but are unwilling to risk it. And if there was ever a time to take a risk, this is it.

So take the plunge. Go fully remote. Hire that worker from another country or a different time zone. Create the systems that enable your company to work whenever, wherever. Take all that money you spend on rent and invest in your employees instead.

And then update your damn job listings. Say that you’re hiring remotely so I can find you. I see tons of job listings in “Remote, Oregon” but I don’t see any office buildings there…

The backspace problem

The worst invention in writing and technology history was the backspace key.

Before computers, we wrote using typewriters or on paper. They had a restriction. It was really, really hard to undo what you wrote. On a typewriter, you’d have to white-out your errors. On paper, you’d erase your pencil marks or strike out your pen mistakes.

Then came computers. They had this thing called “backspace” where you could just delete a letter, a word, a sentence, or even entire paragraphs with a few pecks at the keyboard. It was a boon to editors who could finally make all the changes they wanted with little effort.

But it came at a cost. You spent time rewriting that last sentence, editing that paragraph over and over. Refining and refining what you wrote over and over again.

You believed that putting more effort into editing would make your writing better. But the issue was that your text didn’t get better. It just churned. Even worse, you kept making changes, but you never felt “done” or “happy” with it.

For tech products, “backspace” meant that your product could be modified trivially. There was always time to get in that one last change, refine that design, tweak that text. But it has the same penalties — time churning on your designs, and the mental strife of not being done or happy with it.

And somewhere along the way, that goal you started with got lost.

I recall seeing Lynda Barry talk about this. She was struggling to write a book on a computer. “The problem with writing on a computer was that I could delete anything I felt unsure about. This meant that a sentence was gone before I even had a chance to see what it was trying to become.”

She eventually wrote that book with a paintbrush. “I was surprised by the instant change in my experience of writing. Without a delete button, I could allow the unexpected to grow.”

So when I wrote this, I wrote it all the way through to the end with just a couple of tiny edits. Then I went back and did an editing pass to make sure it flowed — that it emphasized the points I wanted to make.

You might think punchcards for code and ink on paper are inferior to digital text and software editors. But those old “technologies” forced you to keep going — move past the doubt and reconsideration. You had to fight to get to the finish line. There was no time for changes.

And you were happier when you were done with your ink writing or punchcards compared to people who constantly re-edited their code or messages with “backspace.”

My challenge to you is this: turn off your constant editing mode. Try not to use that backspace key after every mistake. Don’t re-edit word by word.

Instead, work your way through to the end. Find your message. Then you can refine the details to make sure everything fits together — whether you’re writing that text message, blog post, or new mobile app that’s gonna change the world. Your work will be better for it, and you’ll be happier with what you did.

And now to take more of my advice and get to those 100 or so posts I keep re-editing but never publish…

Work culture and job hunting

The thing about a company’s culture is that you can’t tell what it’s like when you’re interviewing. You’ll have to be more creative if you want to learn what a company’s culture is like before you take the job.

Someone asked me if I’d discuss how to find a company with a great culture — particularly during an interview so you don’t get stuck in a place with a bad culture fit. And since I’m on the job hunt again, it’s a good time for me to reflect on this because I also want to find a company with great culture.

So why did I say it’s not possible to do this during an interview? To explain that, I need to define work culture. Then I’ll discuss ways to find out what kind of culture you’re walking into. I’ll wrap up with some ways that companies can do a better job communicating their culture.

What is good work culture?

I should be clearer about what I mean when I say “good culture.” There are lots of useful definitions of work culture like, “what is and isn’t allowed at a company” or “how decisions are rewarded, penalized, or ignored.”

My definition of “good work culture” is:

A company with a good work culture uses a consistent set of values to make decisions and take actions.

“Values” — what are those? Oh yeah, we’re going down this rabbit hole. Here’s my working definition.

A company’s values are the set of beliefs, principles, and priorities that underlie actions and decisions.

In other words, companies make decisions. Those decisions are based on values. Companies that use consistent and predictable values to make those decisions have good culture. Companies that use inconsistent or unpredictable values have bad culture.

Your job satisfaction depends on this work culture. Do your personal values match your company’s values? Can you predict the way others will make decisions based on the company’s values? Based on your answers, I can tell you how happy you are with your job.

Let’s stitch this together with an example. Say you work for some random company. The break room has a poster that lists Your Company’s Values like:

  1. We let employees make decisions independently
  2. We share information openly
  3. We are honest with each other

Now imagine you’re presenting your product’s roadmap to the CEO. She says, “that’s great, but we need to launch [some feature not on your roadmap] this quarter because the board says so. Find a way to get it done.”

I didn’t see “the CEO gets to override your choices” or “the board’s preferences are more important than independent decision making” on that list. But those are the values which was used to make that decision. It makes you feel like shit when someone can clobber your decisions in a way that’s inconsistent with your company’s values. You’re expecting everyone to follow the company’s values, so why does the CEO get an exception? Shouldn’t the CEO be the model for the company’s values?

Another example — let’s say your company has a list of values that includes “work/life balance” but your manager says you need to put in extra hours this weekend because you’re going to miss your ship date. Your company has a bad culture because the unwritten rule “we hit our commitments” overrides the written rule “work/life balance.”

By contrast, this company could have good culture if your boss told you not to work this weekend because work/life balance is more important than hitting your ship date. And obviously you’ll be happier in that company — the company whose written rules match the way they make decisions.

So a company with a good culture is one that makes decisions based on a consistent set of values on a day-to-day basis. Ideally these values are written down and made public so everyone understands how decisions are made. You’ll be happier working at companies like these.

A company with bad culture is one that uses an unpublished or inconsistent set of rules to make decisions. They’re unpredictable — the next decision may use an entirely different set of criteria. The randomness of decisions and values makes you less happy working there.

And that’s why you can’t tell what this company’s culture is like when you’re interviewing. Culture is the expression of a company’s values through decision making. You will only witness those decisions when you’re working at the company, in that moment. An interview won’t tell you crap about their culture.

But you still can try to find out what a company’s culture is really like — if you’re willing to put in the effort.

Discovering a company’s true culture

So you want to learn more about this company’s culture? You’re gonna have to hustle.

You might have a list of “culture” questions that you ask when you’re interviewing, but these won’t work. Asking what people do for lunch or number of hours worked won’t tell you about the company’s culture because culture is something that happens when decisions are made. Worse, the interviewer could lie. In fact, they probably will lie, especially if they like you and want you to work there.

The best way to learn about a company’s culture is by asking current employees who will be candid with you about it. Do you have a friend who works there? Maybe someone who knows someone else that works there? Someone who’s willing to answer your questions honestly? Invite that person out for coffee. Ask them questions about their values and the way they make decisions. It’s the best way to learn.

Don’t have a contact there? Try cold calling someone. LinkedIn makes it trivial to find people who work at other companies. Send a message to someone who is or was in the role you’re applying to. See if they’ll give you a few minutes of time to chat or reply to a question about the company’s culture — especially the way the company makes decisions.

If all else fails, try reading reviews from employees on sites like Glassdoor. You’ll have to take those comments with a grain of salt, but they’re often indicative of what a culture is really like. For example, if several people mention the exec team is lost or inconsistent, you’ll have a pretty good idea about what you’re walking into.

None of these are fail-safe, but you’re get a better indication about a company’s culture by finding people who are willing to be honest and leveraging your social connections. Give it a try.

A call for honesty in values

I want to propose another solution to this problem — a way that companies can help potential employees make better decisions about company culture.

Companies need to be really, really honest about their values.

Most companies want to seem like they’re cool, progressive places to work. When they publish their values, those values look sexy but don’t match the reality of working there. Values like “we let our employees make independent decisions” sound great but are rare in practice. If companies were really honest about their values, employees could make better decisions about which companies’ cultures are a good or bad fit.

For example, if your company values hitting your ship dates, then your values should say “our employees do everything they can to achieve their goals” and should not say “we value work/life balance.” But if your company really does value your employees’ leisure time over working endless hours, put “work/life balance” on your website.

So if you’re in a position where you can set your company’s values, be honest about them. And if you’re an employee who notices the gap between what your company says they value and what they actually value, speak up. You, your coworkers, and potential employees will be better off for it.

That’s all I have to say about work culture and finding a job. Happy job hunting, and I hope your next employer has better culture than your last one.

Staying sane in product management

Last weekend, I attended Portland ProductCamp and gave a talk called “Staying Sane in Product Management” which I’m summarizing here. It was inspired by my previous post “What product management wants” which I recommend if you haven’t read it.

In short, product management is a stressful job. We rarely think deep about the causes of that stress. It’s not just that other people are assholes or you work too many hours. By identifying the right causes, we can make changes that will help us be better product managers and better people.

We’ve all known someone who struggled with the stress, anxiety, or depression from the daily issues we face in product. Maybe you’ve dealt with those problems yourself. My hope is this helps you pinpoint the issues that cause you stress or anxiety, then you can take concrete steps to improve them.

On a related note, I’m also available to help you with these things. Do you need help making progress your career? Or do you want to give your team a boost of morale and productivity? Talk to me. I can help you with coaching or consulting to make you and your team more resilient to the pressures of product management.

This is yet another really long post, and again I’m not apologizing for it. If you want a shorter version, start at the Truth of product management section below.

For the rest of you, what are the real causes our stress as PMs? It’s a few things.

Other people

It’s both true and naive that other people are the source of most of our mental distress. Some people are hard to work with. But why?

For one thing, we have different goals than they do. In my work, I was often told by a manager or CEO to “go build the product of the future.” However, my other stakeholders wanted me to “go build this feature so we can hit our goals for this quarter.” That puts me under huge stress to deliver everything for everyone. Plus it’s hard to say “no” to incoming requests, especially when I’m the only one who can help.

But it’s more than that. We also have incompatible mental models with our peers. The simplest one is the mental model that others have of software development. “We just need a button here that generates a spreadsheet. That’s easy, right?” Obviously that person’s mental model of software development is wrong.

In a similar way, you also have a different mental model of your users and their problems. For example, you see your users struggling with the overwhelming amount of choices in your e-commerce product. Your sales team thinks you don’t have enough choices because users are asking for options that you don’t have. People build their mental models on their observations of the world, and that can put us in direct conflict with them. Even worse, changing someone’s mental models is really hard — nearly impossible. It’s stressful when we can’t see eye-to-eye with others who have reasonable points of view.

And there’s also the problem of your soft skills. Sometimes the problem is not other people. It’s your communication, negotiation, and leadership skills that are the problem. You pitch your roadmap and get shot down by the sales exec. You think, “that person is an asshole.” But the sales exec thinks, “I have no idea what that PM was talking about.” You suck at communicating, but you place the blame on the other person for not understanding. In other words, the problems that you externalize onto other people are actually your own fault.

Loneliness

Let’s go deeper. Another problem that contribute to our unhappiness in product is loneliness. “Lonely? I work with people all the time.” Exactly. Our job is to be fearless leaders, collaborators, and negotiators. We’re doing our job when we work with others.

However, the people we work with are doing their jobs when they work alone. Your devs code alone. Your designers and sales people might work with users outside your office, but most often they’re working with their computers. And when we ask for their time in meetings or conversations, we’re keeping them from their jobs.

We’re also outnumbered. There are fewer product people than nearly every other role in a company. It can be intimidating just to be a product manager, like being the only product manager in a room full of marketing people who desperately need your help with their new ad campaigns. We’re expected to excel alone. In fact, if your manager has to intervene, it’s a sign that you’re not succeeding in your job.

For people who are expected to be leaders and collaborators, product management is a lonely role. And because of the uniqueness of our jobs, it’s really hard for us to find people who can really relate to your problems. Except for other PMs. Other PMs always understand.

Work/life balance

Product managers work hard. It’s common for us to work over 40 hours a week. We often use “hours worked” as a proxy for company culture and professional happiness. And yeah, it’s true — you’re more stressed and less happy when you work more hours.

But how many times have you left the office and couldn’t stop thinking about the meeting you had earlier today where your new feature designs got rejected by your VP? Or felt anxious about that meeting tomorrow where you have to share the roadmap with the sales team and you know they’ll hate it because it’s missing features they’ve asked for?

The stress of our job carries into our home life even when we’re not working. Instead of thinking of work/life balance in terms of hours worked, why don’t we talk about “hours stressed” instead?

Goals gap

Imagine being an airline pilot. What are your goals? First, it’s passenger safety. Did all the passengers who got on the plane get off the plane? And all in the same health as when they started? Great! You did your job. You could also check your flight time, how close you were on your ETA, or fuel use among other things. And you get that feedback every flight.

What about product? Well, your goals are fixed… for now, but they could always change tomorrow. The feature you launched — you won’t see results for a few weeks. And who knows when that next feature will be done. That gap between “do the work” and “achieve goals” is huge in product. Achieving a goal is great, and it feels great. But product management is full of delayed gratification and shifting objectives which contributes to our stress.

Career gap

How many recruiter emails did you get this week? Each one is a siren calling you to that next job. Maybe that company will have a better culture. Maybe you’ll get to work on a mobile app like you’ve always wanted to. Maybe it’s an opportunity to get that promotion which you never seemed able to achieve in your current job.

But maybe your unhappiness in your current job is simply because of stagnation. You’re not working on new problems, learning new skills, or making progress on your career. You’re bored, and you confuse that with job dissatisfaction or a broken career trajectory.

Similarly, we’re told that we should follow our passion and find jobs that make us happy. “Find a job you love and you’ll never work a day in your life” is garbage. This idealization of careers is detrimental to your happiness. Every product job has bullshit that you don’t want to deal with, so you put every new job opportunity on a pedestal because you imagine it will be better. Most likely, you’ll feel the same but deal with different bullshit.

The grass is always greener on the other side. Simply knowing that you might be happier in another job makes you less happy in your current one.

Skills gap

Go read any job description for product management. It’s gonna mention something about working with developers, experience in specific industries, prioritizing features, or talking with customers. Yeah, those are things product managers do.

But those aren’t the skills you need to succeed. The real job of product, and the parts that fill us with the most anxiety and dread, are communicating, negotiating, and firefighting. We have to deal with failure on a daily basis. We have to tell people uncomfortable truths all the time.

We’re terrible at hiring people who can be successful at product because we ask them about the “job description” skills instead of the “real PM work” skills. Or that person sold themselves as a perfect fit in the interview, but they were the opposite of the type of person who will succeed at your company.

Even worse, we’re terrible at developing those skills in ourselves and other product managers. Soft skills are hard to teach, learn, and master. Weirdly, we expect product managers to have mastered those skills already simply because they’re product managers. And because we can’t identify or develop these skills, product managers are often set up to fail in their jobs.

Confidence gap

Our work is burdened by uncertainty. Which problems should I focus on next? Which features will solve those problems? What if I fail? There’s so many choices, and it can be paralyzing to decide.

And yet we need to be confident so we can convince others that our plan is the right one — even if it’s not one we believe in. It’s not comfortable to lie or mislead our teams, but maybe that’s better than being honest with them? Or if we are honest about our feelings, would that destroy their morale?

Then we’re presented with a new set of problems from another stakeholder. Here’s a new business opportunity that we could attack, but it would mean giving up on our current priorities. How do we know which to choose? And when we choose, what if the other path was the right one?

We’re expected to be these confident, certain leaders who always make the right choice, and yet so often we doubt ourselves. What if we fail? Make the wrong choice? Don’t show confidence? People around us might not follow our lead. Worse, they might turn on us. And then it’s not just our goals at risk — it’s our jobs.

The truth of product management jobs

So let’s add it up. Our feelings of stress, boredom, or worry are the tip of the iceberg. Even though we think other people are the source of our problems, the truth is that we’re responsible for many of the problems, and we project those problems onto other people. If we don’t deal with these problems, our negative feelings can compound into anxiety, burnout, and depression.

I know this because I’ve discussed this with fellow PMs and I’ve dealt with it myself. I burned out on my product career for a while because I didn’t have the knowledge to understand what was happening nor the tools to deal with it.

But that burnout led me to realize some truths about product:

  • We undervalue the true skills of product like soft skills or like managing failure. Those skills are really hard to teach or learn, but they’re essential to our success.
  • We assess problems incorrectly — “externalizing” (blaming others) when we should “internalize” (look inside) to find the true source.
  • We’re envy of our ideal selves. We think we should be “happy” but we miss opportunities to be “happier” if we’d settle for less.
  • We confuse solutions (like finding a new job) with problems (like boredom in our current one), and that keeps us from finding the real problems to solve.

Knowing this, I started to approach my work in a new way.

Being better

So what should we do? We should find ways to make our jobs better. Not great. Not happy. Better. Happier. And that means taking small steps that move us in the right direction.

Here’s some of the tools I use that make me a bit happier. They can work for you too.

Talk to someone. Psychiatrist? Sure, they can help with the most acute issues. But talk to anyone who will listen. Ideally, talk to someone who can relate to your issues and give you concrete advice that will help you grow. Grab another product manager and take them out for coffee or beer.

Externalize your decision making. It can be really stressful to deal with a new feature request or other conflicting priorities. Instead, come up with criteria that you can use to make a decision without injecting personal preferences or politics. For example, if your company uses OKRs, you can use those as a shield against requests that don’t align with them. Or default to “no” on any new requests unless it will generate more than $100,000 in new revenue or will close a key account.

Build a community of support. We know that people who practice religion* are happier because they’re surrounded by a group of people who support them. So join a product meetup in your area, or strengthen ties of friendship with your coworkers. Also, find a mentor — someone in your field outside your company who can give you advice and support when you hit that wall.

Work towards a goal. Another reason practicing religious people are happier is because they’re trying to achieve something bigger than themselves. You can do the same in your life. Develop new skills to accelerate your career like learning SQL or some programming. Find goals outside work like excelling at a hobby. Learn a musical instrument. Try dancing. Plan a big vacation and then go on it!

Create healthy rituals. Meditation, exercise, religion, sleep — yeah, all those are fine habits to build up. Also think about healthy work rituals. Block off 4 hours a week for deep work. Turn off those notifications for a while. And plan your tomorrow — at the end of a day, write down all your todos for tomorrow. Block off time on your calendar so you can complete them. Most important — get them out of your mind so you don’t ruminate on them for the rest of the night.

Try something scary and new. Build confidence and resilience to help you deal with the stressors at work. Afraid of joining your local gym? Just fucking do it. Ask a friend to go with you for support. Try an improv class. It will be really scary and stressful but also safe and exhilarating. Plus your improv skills will carry over to your work.**

Lower your expectations. You’ll probably be happier with less than your ideal outcome. Maybe you have a career goal of being a CPO or just want a promotion. Don’t focus on the goal. Just focus on the next step. What’s one skill you need to improve to get that promotion? Or if you’re selling your roadmap, pick one thing that you really want, then trade the rest of your roadmap for that one thing you want. Find the first step to build momentum, and don’t let the rest weigh you down.

In sum

Product management is hard. Really hard. And it can affect our mental health, especially if we’re unaware of the real problems that impact us.

If you are struggling with anxiety, depression, or similar issues, please seek help. These are serious issues that can affect your entire life, not just your work. If you’re not sure where to start, contact me. I’m happy to point you in the right direction.

We can do better for ourselves and each other. Watch out for the factors that contribute to your distress. Put new practices in place to help you deal with those pressures.

And watch out for other product managers who need help. Like I said, it can be really lonely as a product manager, especially dealing with a sensitive issue like mental health.

If you’re looking for help one-on-one or for your group, contact me. I offer coaching or consulting to help you and your team improve at these skills.

We can succeed together, if we try.

* I say “practice religion” intentionally. Simply believing in your religion and attending Christmas services won’t make you happier than non-religious people. Instead, find a community and regularly attend religious events to be happier person.

** In my presentation, I suggested “be really honest” as a solution here. A member of my audience said that it backfired on her when she tried it. I noted that women are treated differently than men in the workplace, and her story was a great example of it. Past that, I’m completely unqualified to discuss gender issues in product other than noting they’re real and that I’m hopeful they’ll get better as product management and software development become less male.

Why Google didn’t hire you for that product management job

Most PMs I interviewed at Google did not pass the test. You won’t either unless you show that you’re more than just a product manager. You have to prove that you’re a Google product manager.

I remember my own interview at Google pretty well. I knew that most people who interviewed there didn’t get hired, so I focused on my mental game. I went in with an attitude that I’ll just try to have fun with it — show that I’m excited to work there and that I care. Most of all, focus on enjoying the experience and trying to learn more about what it means to be a product manager at a company like Google.

Across a phone screen and two on-site interviews, I was subjected to hours of questions that I had never heard before with lots of hard, ambiguous problems to solve. It was difficult and stressful, and yet I managed to stick to my plan — stay happy, stay excited, show you care. I left thinking that I had a good time. It would be OK if I didn’t get hired. And if I got hired, it would be a pleasant surprise.

To my surprise, I got hired.

And within a few weeks, I was interviewing other product manager candidates.

It was daunting. I barely knew what I was doing at my own job, and they were already trusting me to make decisions about who to hire. I knew I’d have to level up my interviewer game to ensure that the next PM who gets hired was better than me.

By the time I left Google, I had interviewed dozens of product managers. Most of the time I was conducting phone screens. That meant I was the first product manager you’d talk to at Google. It was my sole decision that determined whether or not you moved on to the next round of interviews.

Out of the over 50 product interviews I conducted, I gave top scores to only 3 of them. And even if I signed off on you, you’d still have to get the approval of all your other interviewers, the hiring committee, and company executives. It’s a huge feat to get hired by Google.

Why is it so hard? Mostly because we’re told very clearly that we should only hire people who make Google better. Most PMs I interviewed did not. It’s not that they’re bad PMs; it’s just that they’re not Google material.

Here are some specific reasons why you didn’t come off as Google PM material in your interview.

You’re not user focused

I always enjoy asking open-ended questions like, “if I delegate this problem to you, what would you do?” Many people answer they’d go build some solution or dig into data. Those are the wrong answers.

The best answers are always about understanding people and the underlying problems they have. Tell me you’d go do some interviews, conduct surveys, talk to experts, or somehow get to the heart of the problem. Then you can get to the data analysis and other bits. I was always stunned about how frequently I’d get an answer like, “I’d go build a new app…” without any attempt to dig into a problem first.

Show that you really care for and empathize with people who use your product. Prove you’re willing to go the extra mile to understand their pains and problems. This is the heart of product management at Google and anywhere.

You weren’t excited and confident

Most people who interview at Google are nervous — and that’s totally understandable. You’ve been given this one shot to get a job at one of the best companies in the world. You don’t want to fuck up, and that makes you jittery and anxious.

When nearly everyone is like that, I’m always pleasantly surprised when I get that candidate who’s happy, engaged, and enthusiastic to be there. They usually have a little smile on their face. The tone in their voice shows their happiness. They’re clearly excited to be here, and that makes me excited to be there with them. It shows they’re confident and ready to handle any problems might come their way, even though they might be stressed right under the surface.

So channel that anxiety and nervousness into confidence and joy that shows you came here to get this job. It helps if you go into the interview as if you have nothing to lose — you don’t because you probably won’t get the job anyway. If you embrace this feeling of excitement and happiness, you’ll amaze yourself how different your answers and behavior will be during the interview.

You didn’t communicate clearly

“Product manager” is a fancy term for “communicator” because most of what we do is listen, explain, and negotiate. Because of your nervousness and stress, sometimes it’s hard for you to think clearly. Your brain is firing off all kinds of thoughts, you’re not sure which way to go.

Then you try to speak. What comes out is a lot of words — a stream of consciousness, not an answer. I’m sitting across the table from you struggling to reassemble your words in a way that I can understand. You have a picture in your head that’s not developing in mine because your brain is getting in the way.

The best way to handle this is to take a few seconds before you answer to plan what you want to say. Then focus all your effort on clearly communicating those concepts. Make sure you answer the question I asked, and make sure to explain why you chose that answer. Don’t think of new things to say while you’re talking because that will get in the way of your clear communication.

You weren’t Googley enough

I always asked the same questions in my interviews. It made me more consistent as an interviewer, and it gave me a baseline that I could use to measure you against. Because of this, I could tell in the first few minutes of the interview whether or not you’d pass the test.

Most people’s answer’s were middle of the road. They lacked that creativity that shows they were masters of tech, design, and strategy. The candidates didn’t show their enthusiasm about applications of new technology or the brainpower that’s available to them at Google. Their tone of voice was flat or nervous, and they looked like a deer in headlights. They gave answers I had heard before — nothing novel or interesting. It was boring to be with them. I wanted to get out of the interview as soon as possible and even less to be their coworker.

“Googley” is the term that’s used to describe the intangible factors that separate out the people who are really enthusiastic about their work and working at Google. It’s a combination of being knowledgeable, passionate, humble, and friendly that embodies what an ideal Google employee should be. In short, I should be excited that you’re going to join the company — that you’ll fit in with everyone, that you’ll be fun to get lunch with, and that you’ll do it with zest.

This is really the hardest of all to advice about because it’s so subjective. First, you need to do the things above — prove that you care about people and their problems, show your excitement and engagement being here, and clearly communicate what you’re thinking. Then you have to go the extra step to prove that you really know and love product –that’s the best you can do to show that you’ll fit right in as a Google PM.

Coda

There’s a part of my Google interview history that I neglected above… That was my second time interviewing at Google.

My first interview with Google was three years earlier. I managed to pass the phone screen and get an on-site interview. And then I fucked up. I was nervous. I couldn’t think straight. I gave terrible answers. I walked out knowing that I didn’t make the cut, and I was proven right.

A few years later, a Google recruiter got in touch with me asking to come back and try again. I said yes, and I went in with that attitude I mentioned before. I probably won’t get hired, so I should embrace the experience so I can stick to my core values instead of fighting against my nervousness and anxiety.

To my surprise, I got hired.

I got lunch with my new manager a few days before my start date. He said, “do you remember me?”

I said, “no.”

“I interviewed you when you came on site a few years ago…”

“Oh god.”

“…and when I saw your resume come up as a new hire, I went to the HR team and asked them to put you on my team right away. You’re exactly the kind of PM that I was looking for.”

It was that moment that I realized I had really passed the test.

You can do it too.

Make love, not NPS

Great product teams know why people love or hate their products, not if people would recommend them to friends.

NPS – net promoter score – is a metric that many companies use to assess product satisfaction. I’ll assume you know how it works, but if not, see this footnote for a quick primer.

Give me a few minutes of your time to prove to you why NPS sucks and how you can measure love instead.

Why NPS sucks

It’s trademarked
NPS isn’t some commonly accepted measure like temperature or length. It’s a number invented by an agency and it’s been trademarked. If I was an agency and I was looking to drum up work, I’d invent a loaded metric that always shows your product needs improvement, lock it up with intellectual property laws to prevent others from using it, then I’d sell you a solution that optimizes just that metric. Let’s dig into how loaded it is.

Ignoring 28% of the results
I swiped a ton of NPS data from indexnps.com – a site that has lots of NPS results for a wide swath of brands. Recall that responses of 7 and 8 are ignored in NPS results, yet 28% of NPS responses fall in that range. If I was an agency trying to get a client, throwing out a quarter of positive results without any justification is a great way to stack the deck in my favor that you need my help.

Biased results
People often answer survey questions based on what they think you want to hear rather than give an honest response (“experimenter effect“). In the case of NPS, they’ll answer that your product is great even if it isn’t. A full 67% of the indexnps scores were 9-10. Were those people really excited to recommend those products or were they trying to satisfy the pollster?

What are they recommending?
The people answering your NPS question could be recommending any part of your product. For example, if your website has an engaging user experience and separately a monetary incentive for participation, people could be recommending your monetary incentives (“Hey, get free money here”) over your user experience (“Hey, this site is really engaging”). This is an essential detail that gets paved over with the overly simple NPS question.

Hypothetical vs. concrete
Since NPS is framed hypothetically (“Would you recommend…?”), you’re not learning if people actually recommended it (“Did you recommend…?”), to whom they recommended it, how they recommended it, and whether or not that recommendation actually had an effect. NPS leads to more questions than answers.

It’s not an outcome
Companies treat NPS as a key outcome — ex. “Our goal this quarter is to increase NPS 20%” — without understanding how or if that translates to other business results. NPS isn’t an outcome, high scores doesn’t ensure more business, and it doesn’t tell you if customers will stay loyal to your product.

Measuring Love

My hypothesis is that love and hate are the best indicators of your products’ future success, so you need to measure them.

Humans make decisions based on emotions (then justify their emotional decisions with reason). Your goal is to make a product that triggers positive emotional outcomes so that people become loyal to your product without realizing it. Negative emotional responses and decreasing positive emotional outcomes are signs that you’re going to lose customers.

Ask these questions instead to learn whether or not people love your product.

“How do you feel about the product?”
Have the person choose from a series of smileys with a range of emotions – elated, happy, neutral, angry, crying, sick, love, etc. Keep track of the positive versus negative emotions and how they change over time.

“What do you love most about the product?”
Sure, it’s a naive question, but it bluntly gets at the issue. These are the items you should feature in your marketing materials and sales pitches to get future customers’ attention. Ask it open-ended (vs. multiple choice) for best results.

“What do you hate the most?”
These are the problems that you need to fix or you’ll lose customers. Note that different types of users will have different problems, so you need to ask a wide swath of users. For example, if you’re making a business app, the everyday user will hate some parts (ex. “this page sucks”) versus the ones that the buyer hates (ex. “this costs too much”).

“Have you recommended…”
Ask this yes/no question – “Have you recommended [my product] to a [friend/colleague/etc] in [the last month/year/ever]?” Try to learn about the context of the recommendation and why that person recommended it. Concrete questions are way better than hypothetical ones (“Would you recommend…”).

“How did you recommend…”
Ask how someone explained your product to another potential user of your product. Your everyday users can explain your product to other potential users better than you can. You need to understand the language of your users, then use those words when talking to other prospective customers.

Measuring love is hard and necessary

The promise of NPS is that it’s a quick way to assess how well your product is doing — that recommendations are a proxy for product success. Taking shortcuts with something as complex as social interactions or emotional reactions can lead to worse results than doing nothing at all.

This gets to the core of the matter — a great product team should always seek to understand why people love and hate their products, and they should be be able to tell you why without hesitation. “Hey PM, what do people love the most about the product?” If your product team can’t answer that question immediately with concrete examples, they’re not doing their job.

So do the right thing with your NPS scores — get rid of them — and instead learn how people feel about your product. I’d take one person who loves my product over a hundred who’d recommend it to a friend.

tl;dr on NPS: NPS is usually asked as a question in a survey like: “From 0 (not at all) to 10 (definitely), how likely are you to recommend [my product] to a [friend/colleague/etc]?” The NPS score itself is (% of people who answered 9 and 10 – % of people who answered 0 to 6).

So if your nps is 70% (that is, there’s a 70% difference between people who answered 9-10 versus 0-6), the general interpretation is that people like your product. A score of -20% (that is, the percent of people who answered 0-6 was 20% more than people who answered 9-10) probably means that people don’t like your product.

What product management wants

“Is it just me or does every product manager feel like this?”

My former, product manager coworker asked me this while walking the streets of Manhattan. He had recently gone through some work shit and was struggling with it — experiencing the doubt that strikes at the heart of anyone in a tough work situation. He asked that question rhetorically, as if he expected the universe to give him an answer so he could resolve his doubts and move on.

I stepped in for the universe. “It’s not just you. We all feel that way.”

Product management is a difficult, burnout-inducing profession. We do it because we love the idea of it more than actually doing it. I’ve hit the point in every product job I’ve ever had where I tell myself, “this is the last product job I’ll ever have.” Still, I keep doing product work, hoping that the next job I have will be the one that fulfills my expectations.

What will it take to close the gap between our expectations and reality in the product management profession?

Let’s unpack the job of a PM. We take an ill defined idea and turn it into something that people will love.

That means we need to understand what people need, lead a team to create an amazing solution, ship it into the world, see what happens, and then start the whole process over again. If all goes well, the people who use the product pay us (ideally with money) in return for how much they love the product. The job sounds pretty great.

It sounds pretty great, in theory.

In practice, a product manager struggles to balance the needs of:

  • the company who depends on the product’s success
  • the customers who pay the bills
  • the users (who may or may not be the people who pay)
  • executives and others who impose their demands
  • new problems which have to be dealt with ASAP
  • themselves and their happiness

That last one is the hardest by far. We product people are unhappy. That’s more than just my opinion.

“Product manager” was named one of the unhappiest jobs for two years straight, 2011-2012. Don’t believe it? Ask a PM about his/her job and you’ll see the sadness in their eyes. I can’t remember the last time I met a PM who was truly happy with his or her job.

Why are we product people so unhappy? The explanation is deceptively simple. There’s an enormous gap between the expectations of what we want in a product job and the reality of doing the job.

Let me describe the gap in more detail.

You expect: ownership of the decisions and direction for a chunk of the product
In reality: you’re expected to adopt the same decisions and opinions as your boss & managers
You expect: authority to make decisions based on hard data, user needs, and other evidence
In reality: HiPPOs (Highest Paid Person’s Opinion) make decisions despite or withholding evidence
You expect: to work with a close knit team to focus on delivering that product
In reality: you can’t deliver because the team and priorities change too often
You expect: enough support to make the product as successful as it can be
In reality: you capitulate because you don’t have the resources to make it successful
You expect: responsibility to make the decisions that make the product successful
In reality: you have to get layers of approval, and your decision can be overturned by anyone above you
You expect: recognition if things go well, or blame if they don’t
In reality: no recognition when things go well, and all the blame if they don’t
You expect: bottom-up management — you tell the execs what they should be paying attention to
In reality: top-down management — someone else tells you what you’re going to do next
You expect: a job where you’re the fearless leader of a team who fights to achieve awesomeness
In reality: you’re a middleman who takes the specs from the customers or managers to the engineers

That gap between reality and expectations is called burnout. The larger the gap, the faster you and your team will descend into underperformance and depression. And that, in a nutshell, why PMs are so unhappy.

Despite all that, we still do the work — hoping that the next job will be the right one where we can do product management “the right way,” where our reality will match our expectations. And if there is a gap, hopefully we’re paid well enough to ignore that gap.

But that’s a horrible capitulation. There’s got to be a better way to do this.

What does product want?

We want to…

  • make something that people love
  • own our customers’ and users’ goals and problems
  • make decisions based on data and evidence, not opinion
  • have the authority to define our own success
  • have the responsibility to achieve our success
  • get the resources we need to reach that goal
  • have the trust of our stakeholders and managers

That last one — trust — is the hardest one. “Why should anyone trust the product team?” I’ve heard that said too many times and too many ways in my product management career. “First, product has to earn the trust of the organization. Then they can take ownership.”

Therein lies the problem. A healthy team is built on trust — trust that the product team knows how to do their job, how to understand users, how to work with stakeholders, and how to make the right decisions that will make the company and product and users successful.

A healthy team trusts by default.

When trust is lacking, you’ll get the “in reality” situations I described. HiPPOs tell the product team what to do because they don’t trust the product team to make decisions themselves. The company’s course changes constantly because nobody trusts in the product team’s direction. The product manager is blamed for failure even though the product manager never even made a decision by his/herself.

Fixing the problem begins with trust.

To all you executives, product management leaders, or anyone who interacts with your product teams — if you want a healthy product team, you have to trust them with the authority and responsibility to do their jobs. And you should be uncomfortable to cede that much power to them.

It’s a difficult request. Product management is a critical role in a company, and everybody has an opinion on what’s the next most important thing to produce. Giving that power away is a difficult decision, but it’s one that’s essential if you want to see a product team thrive.

The best product team I ever worked on was built on trust. Each PM had a well defined role and knew how their product area laddered up to the company objectives. We were held to goals that we defined for ourselves, and we were given the authority to achieve those goals as we saw fit.

The worst teams I’ve been on, on the other hand, were built on all the opposite. The management questioned and trumped the teams’ decisions regularly. There was no clear ownership and no authority given to the product teams. The team was told what their goals were. There was no trust, and no path to achieve that trust.

If you don’t trust a team or are so uncomfortable that you won’t cede that power to them, fire those people and replace them with people who you do trust, with people who you would empower with real ownership.

Because if you’re not willing to trust them, you don’t have a product team. You have a bunch of overly-paid people who pass specs from the managers to the engineers.

So make the decision to trust your product team. Work with them to understand the problems facing your organization. Help them come up with amazing solutions to those problems. Believe in them when they ship their solutions. And celebrate their wins to show your thanks.

That’s what product really wants — trust. And that will make your product managers happy.