how to receive feedback like a product manager

Many of us try our best to give good, timely feedback, and in turn we try to receive feedback graciously and patiently—after all, feedback should be a gift. But, let’s be real, it can be really really hard sometimes. If you’re anything like me, I’m sorry. Kidding! If you’re anything like me, you probably have a hard time separating your emotions from the the feedback that you’re either trying to give, or trying to receive well.

I think we could all improve our feedback giving/receiving skills by approaching feedback a bit more like a product manager. Not to say you should form your feedback in the way that a product manager might, but rather you can approach feedback in a similar way that a product manager approaches a customer problem. There have been a billion things written on how to give feedback well, so for now I’d like to start with how to receive feedback… even if it’s bad.

Let’s get into it!

• Bad feedback

• It’s ok to feel things

• Prepare yourself

• What’s your problem, anyway?

• Solutions are better together

• tl;dr

---

Bad feedback

I don’t mean receiving negative feedback. I don’t mean getting dope-ass feedback, either. I mean getting feedback that is not well-thought-out, not timely, not specific, and—horrors of all horrors—is phrased as YOUR personal failing as a human, rather than a skill or behavior that can be corrected. It’s well enough that you’re trying to give constructive feedback, but we can’t expect that everyone who has feedback for us is quite as, well, thoughtful.

We’ve all been told feedback isn’t supposed to be personal, and even givers of bad feedback will try to make you believe this. Allow me to quote Meg Ryan’s character, Kathleen Kelly, in the Nora Ephron rom-com of my childhood (nay, life), “You’ve Got Mail.”

What is that supposed to mean? I'm so sick of that! All that means is that it wasn't personal to you. But it was personal to me.

It’s ok to feel things

Receiving bad feedback can feel like a punch to the gut. You will feel it physically. Your fight or flight response will kick into high gear. If you’re like me, you might cry. If you’re more of a fighter, you may lash out. Allow yourself to feel those feelings and observe them.

If you need some time to calm down, let your feedback-giver know that you’d like some time to think about this, and schedule a meeting for the next day. There is nothing wrong with letting things sit so that you can calm down, and more importantly so you can get to the bottom of the actual feedback that’s buried deep within poorly executed words.

Prepare yourself

To get to the bottom of the feedback, you may have to throw out a lot of the initial round. The giver of feedback can be awfully similar to a customer. They feel a certain way about something, they believe they’ve diagnosed the “problem,” and they’ve told you how they want you to fix it. Customers are highly unreliable So are inexperienced feedback-givers.

---

DO

take seriously that there is some piece of actionable insight beneath their words

DON’T

believe the feedback at face value

---

The good news is, you no longer need to focus on the claim about yourself. Instead, you’ve got a mystery to solve. And who doesn’t love a good mystery? Your mission, should you choose to accept it, is to discover what your feedback-giver’s ultimate concern / problem is. And it’s going to be tricky!

You may have a story in your head about where this feedback is coming from, or the motivations of the person giving you the feedback. The reality is your story about this person may be completely false. Think about Elizabeth Bennet’s low opinion of Mr. Darcy for the first half of “Pride and Prejudice.” She had a very clear story in her head about not just his behaviors, but what his behaviors meant about his inner character. Of course (spoiler alert!) she eventually finds out she was sorely mistaken, yadda yadda yadda. The point is, don’t assume your story is correct.

Your feedback-giver may not be aware of what is actually bothering them. They may say it’s x, when really it’s y. For example, they might cite your lack of willingness to provide weekly updates as evidence of your laziness, wherein the actual problem might be that there’s a lack of trust in your work. A weekly update will never fix the trust between you, but together you might be able to develop a plan that would.

What’s your problem, anyway?

My favorite question—the real MVP within a product manager’s toolset—is, “What problem are you trying to solve?”

(Yeah, that’s right. I MADE AN MVP JOKE! I’m proud of myself. And like any good joke I will now explain it. I meant Most Valuable Player, whereas in most product contexts one would assume I meant Minimum Viable Product. See what I mean about assumptions?)

Sometimes you can come straight out and ask, “What problem are you/we trying to solve?” Sometimes that’s a bit more awkward, though, especially if your feedback-giver doesn’t realize they haven’t really pinpointed the root problem yet.

If you feel like they’re getting micro-manage-y, try these questions:

• What concerns do you have about [x]?

• How are you planning to use [this data/this information]?

• Is there something in particular you’re worried about?

If you feel like they want you to do things their way:

• Do you have an example of what you’d like to see? Let’s walk through it together. Tell me what you like about it, and why.

• What are the outcomes you’d like to see with this?

• Let’s look at [document x]. What things didn’t work? The structure? Content? Tone? What things did work?

If you feel like you got an answer wrong:

• Can we walk through our different approaches to calculating this? I’d like to better understand how to do this going forward.

• Is there any context I was missing?

• Did I miss a key piece of information?

Don’t feel like you have to stop after one question. In the product manager world, there’s a concept of the Five Whys. The idea is that you take the initial problem and drill down until you get to a root problem. Do you always need exactly 5? No. You might only need 2 or 3.

Example: problem extraction

“I want you to send me a weekly email on the progress of [project a].”

→ “I am worried this project will go over schedule.”

→ → “I don’t trust you to keep the team on track.”

→ → → “The last project you delivered was a quarter late.”

→ → → → “I delivered [project b] late because I was pulled into [project c] and was told to prioritize that.”

Remember, something that “sounds” like an answer to the problem might not be the real problem. You might be given an answer that sure seem like a reason for the behavior, but are more likely red herring phrases that require further digging.

Examples: Dig more

• I just want to know what you’re working on (why? how will you use this information?)

• I want to be able to unblock you (are you worried that I won’t reach out when I need help?)

• I want to make sure I give you context (what prevents you from proactively providing me context?)

Solutions are better together

In product management, we believe that to find the best solution to any problem, it’s wise to have multiple people brainstorming multiple solutions to that problem. We then keep the best solution, no matter where it came from. If a solution was provided as a part of the “feedback,” make sure you evaluate that solution against the root problem. It’s much easier to have your feedback-giver come to the conclusion that it doesn’t solve the problem than it is for you to explicitly try to convince them.

Example: solution ideation

• Will a weekly email help you learn ways of keeping things on schedule? e.g. does what they’re asking for solve the root problem

• What options are there to help you accomplish the goal of keeping things on schedule? (sheer force of will is not an option)

• Is there additional training or coaching that could help prevent this in the future?

• Do you need more tools for prioritizing pieces of the project?

• Do you need your manager to shelter you from external factors that might lead to things slipping? (e.g. other teams eating up your time, conflicting priorities, or scope creep)

tl;dr

• Getting poorly constructed / worded / thought-out / plain old bad feedback is hard

• It’s ok to give yourself time to work through emotions

• Acknowledge that you may have a story in your head about the feedback-giver which may not be correct

• Go through the feedback and extract the problem(s) like a damned scientist

• Ask 5 why’s and other probing questions to get to the heart of the problem

• Brainstorm solutions with the feedback-giver

quick update

Hey folks! Wanted to send out a brief updated on what to expect from me in the coming months.

Cool stuff

• I’m working on translating my recent webinar for ProdPad into a blog post—coming soon!

• I’m going to start offering a few facilitated group discussions—if you’re interested, please fill out the form!

• I’d love to offer a more regular ask eboyle post—please submit questions for that! (small narrowly scoped questions preferred, but ask big ones if you have them)

Shameless plug

As a reminder, I do offer individual one on one coaching. While the majority of my clients tend to be product managers, I also work with program managers, and even a few folks in HR roles. Whether you just need to get a sanity check on how you’re approaching something at work, need an honest take on a situation, or want to work on a soft-skill, I’m here for you.

Reach out to get the full range of options (and pricing) available to you. Happy to discuss a sliding scale if needed—just let me know.

What else?

What else would you like to see from me, given that the world turned upside down? I’m open to ideas of how I can support you all!

I’m out… (metaphorically. literally still in the same 450 sq ft I’ve been in for 3.5 weeks everything is totally fine)
Erin

simple changes to help move to working remote

Look, the world is both scary and weird right now. Folks who usually work in offices—especially open-plan offices—may be struggling to focus, be productive, or even stay sane. It’s important to realize that your employees and team members are humans and likely have a lot on their mind right now, and you are just not going to be quite as productive as business as usual.

Here are some really simple tips to try and keep you and your people in good shape for more long-term remote work.

Make sure bio breaks are built in.

It’s really, really easy to join video conference after video conference and forget that people need time to take a breather and use the restroom. Most people will just take the break and be late to their next meeting, or just hold it. Neither of these are ideal outcomes.

Use speedy meetings

(end half hour meetings 5 minutes early, and hour meetings at least 10 minutes early) and stick to it to ensure people have a chance to do whatever they need to do as humans.

Build physical movement into your meetings.

Look, we have all forgotten to stand up once in awhile when we’re in an office setting. With people working from home, it’s even more likely they’ll sit for hours on end, forgetting to move around a bit. Besides, we’re all going to get more and more stir crazy as this goes on.

Use physical ice breakers

at the starts of recurring meetings. Maybe it’s 5 minutes of easy stretching, doing 20 jumping jacks, having a dance party for one song… whatever you can think of to build movement into your meetings will help everyone. It’ll make you feel better, and remove some of the cobwebs from the brain. Do make sure you keep this inclusive—consider having optional variations for folks who might not be able to do a full-on jumping jack.

Limit context switching as much as possible.

When we’re distracted by external events and worried about the world, it’s hard to find ways of concentrating on work that—let’s be honest—is not always the most important or interesting thing on your mind. One way to make it easier to get into a flow state is to construct your time in a way that limits context-switching and groups like-work together.

If your job requires a lot of 1 on 1 meetings (people managers, product managers, and program managers), considering rearranging your calendar do those all during the same block of time.

If you work on multiple projects, consider assigning different projects to different days of the week.

Now is a really great time to Marie Kondo your meetings.

I’m not saying you should get rid of any meeting that doesn’t spark joy—that would uhh, really limit the productivity of your organization. But you absolutely should look at some elements of your meetings and Goldilocks them a bit.

Evaluate and modify your meetings

• Function - what is the goal of this meeting, and is it fulfilling its purpose?

• Form - what about this meeting is working or not working well remotely?

• Frequency - is this meeting happening too often, not often enough, or just right?

Based on your answers to these elements, you may want to brainstorm some ways to switch things up. Maybe some meetings turn into a quick Slack chat, and maybe some move to a less-frequent basis for now. Some meetings may need to occur for a shorter time but more regularly.

Create space for unscheduled discussions.

Let’s be honest—we kind of hate drive-by conversations when we’re working in an office. They distract us, get us out of our flow state, and can’t be prioritized. However, there is very often a need to chat in an unscheduled way, despite our desire to structure the heck out of our calendars.

Create virtual office hours

and encourage people to literally drop in on you. Hold it the same time each week, with the same meeting link if you can, and plan to share your video even when no one has joined. When someone does stop in, you’ll be ready for it. You might find that this reduces the need for some ad-hoc meetings as well.

This can also help teammates who may be feeling especially isolated and just need to see a friendly face.

Pretend you’re a real YouTuber.

I’m joking! Mostly. Sort of. You’re having a lot more video calls, right? Why not curate something interesting to look at behind you? I am not encouraging anyone to buy anything new—first of all, that’s going to be difficult right now, but more importantly this is a fantastic time to really implement the reduce and reuse portion of reduce, reuse, recycle.

Have a colorful sheet or towel? Hang it up. Have some house plants? Relocate them to be in the frame. Glass jar that once contained pasta sauce that you’ve now consumed? Slap some acrylic paint on it or fill it with knickknacks for some instant pizazz. Finally, play around with your lighting to make sure you’re not creeping people out.

Do this for you, but also do it for the people who now have to stare at your plain white wall for hours each week. Heck, maybe change it up a little bit every week! Fighting monotony in our lives will also fight monotony at work.

benjamin button, doctor who, and seurat walk into a bar

I recently sat down with a former coworker of mine to catch up and talk shop. He’s an engineering leader with a keen interest in product, and we were discussing how to create a product vision that communicates direction yet doesn’t prescribe exactly what to build.

This is a topic I know in my bones, but have historically had trouble finding the words to articulate how to achieve this. Sometimes you learn things that, after awhile, seem obvious… and yet aren’t even remotely obvious to someone who hasn’t done it before.

This is the long way of telling you I had a breakthrough in that moment, sipping coffee together in the window. Product vision is the Benjamin Button of the business world.

Go ahead, laugh. But… it’s just so crazy it might work.

time and detail are inversely correlated

View fullsize

I don’t even want to admit to you how long it took me to figure out how I wanted to draw this. But hey—we got there!

The further in the future your vision depicts, the more detailed, specific, and high quality it can be. As you move closer to that time horizon, the vision becomes fuzzier, less clear, and depicts more of the problems to be solved. At the shortest distance, it may become words instead of images.

Long-term vision

In order to effectively communicate your 5 or even 10-year vision for the product, you’re going to need something a little bit more inspiring than words. You need to literally create images so that your people can see where you’re heading. The beauty of the time horizon being so far out, is that this vision should not impact the product by the time we reach that horizon. You’re not prescribing anything, because no one on your team is staffed to work on this area yet anyway. All you’re doing is demonstrating what could be.

Mid-term vision

You still need some visuals to help communicate a vision that’s 1 or 2 years out, but you’ll want to lower the “quality” of those visuals. In other words, the images will spend more real estate depicting the problems to be solved, and less to what specifically will be implemented. This is where I find it very useful to say “NONE OF WHAT I’M SHOWING YOU WILL BE BUILT! But it’s representative of the types of things we might build to solve these issues.” Also maybe never show this to a sales person…

Short-term vision

You’re a couple months out from starting work on an area, which means your visuals should be of such low quality that they’re actually just... words. At this point you’re not sharing any nods to solutions or interfaces—you’re simply articulating the problems and areas to be prioritized in the coming months.

a vision is never done

The fun thing about product is that it’s a living, evolving, changing thing. What you think it will be in 5-10 years is almost certainly not what it’s going to be, whereas what think it will be in 2 months is going to be a lot closer to the truth. And, as we move forward through time, our 5 year vision becomes our 3 year vision becomes our 1 year vision becomes our next project.

This means your vision is never done.

Think about that for a moment. Your product is constantly changing (hopefully…), your knowledge of your customers and market indicators is constantly changing. That means to some extent your vision is also constantly changing in subtle ways. You may find yourself re-making your long-term product vision every few years, but the mid-term vision is likely shifting once a year. It’s removing things that have already happened, it’s adding things previously nodded to in the long-term vision, and it’s removing specificity.

you are in both the present and the future

And it’s not because you’re either Doctors Strange or Who. As a product manager you will have to learn to flex through time. One minute you may be writing minute stories for a feature you’re implementing in a week, and the next you’ll be mocking up visions for 2 years from now. While to the untrained eye they might seem like completely opposite activities, you should see the trails and traces of threads that connect the two.

You are implementing this feature, because it was a solution to a problem that was presented in the short-term vision. Solving that problem moves the product closer to the “what if” that was painted for the mid-term, which in turn leads to the “someday utopia” presented for the long-term.

case seurat: let’s van gogh with another metaphor

Still not making sense? That’s ok—I’ve got one more metaphor to throw at you. Imagine you’re Cameron Frye, standing in the Art Institute of Chicago, wondering why the worst friend ever, Ferris, is actively destroying your life. You’re staring at a painting. It depicts a scene. Your eyes zoom in. You see a woman’s face. Your eyes keep going. You see nothing but dots.

I’m describing pointillism, an artistic technique in which the artist creates an image from dots of color. It almost certainly describes the saying, “the sum is greater than the whole of its parts.” (Dot matrix printers also come to mind, although that rather dates me.) In addition to all of that, pointillism also the perfectly demonstrates product visions.

View fullsize

At a distance, you can recognize the image. It’s clear, it’s beautiful.

View fullsize

Get a little closer, and you can still make out some detail, but the scope is much smaller.

View fullsize

Even closer? You can’t see the image at all, only the underlying problems.

---

I also cannot believe how hard I just punned

But hopefully it was worth it for you, if not me. Does this track with how you’ve worked on product visions? Are there any other metaphors I should cover in the future? Let me know in the comments!

the holy tripod

tl;dr

1. At a minimum, a Lead PM, a Lead Designer, and a Lead Engineer should form a tripod that leads the product engineering team

2. The tripod should meet to establish agreed-upon responsibilities and communication patterns, starting from the generally accepted roles

3. No member of the tripod has the final say on everything, they’re like 3 co-equal branches of product government

4. Product is a team sport of solving a Rubik’s cube—you can’t change the constraints, so use prioritization and negotiate with one another in a collaborative manner.

---

Holy Tripod, Batman!

I couldn’t resist. But in all seriousness, the product tripod is a staple in my product belief system (PBS). I believe deeply that every product engineering team should have a tripod at its helm. Hopefully, by the end of this blog post, you’ll agree with me. Although why you wouldn’t just blindly follow me I’ll never understand. 🤷🏻‍♀️

Introducing: The Tripod

What are the key roles?

• Product Manager / Lead PM

• Product Designer / Lead Designer

• Engineering Manager / Team Lead

Why is it so important?

Successful products aren’t typically created from a single person’s mind, but rather through the art of collaboration between a diverse group of people. Even if your organization isn’t super, ahem, diverse (we’ll address that in a different post—I have thoughts y’all), you can achieve a degree of diversity of thought simply by ensuring these three roles are collectively leading the team.

Tripod+

Sometimes a product eng team tripod has even more legs than three (I’ve been known to call it a fivepod) if you’re one of the lucky teams to have access to one (or all) of these roles:

• Data Scientist

• User Researcher

• Program Manager

• QA Lead

It’s fairly common for these roles to either be non-existent in smaller companies, or to be shared among several product engineering teams. Depending on the demands on that person, you may find them being just as involved as the core tripod members, or you may need to prioritize the most important meetings and interactions.

The Tripod and Other Metaphors

Why do we call it a tripod?

What happens when you remove one leg of a tripod? Barring some sort of shenanigans, typically a tripod that becomes a bipod is a… laying-on-its-side-pod. A tripod cannot stand if any of its legs are out of commision. Such is the physics of a product engineering team. It requires a complete tripod to stand on its own three feet and perform to its full potential.

Is it a dictatorship, oligarchy, or democracy? (Dictatorship, right? The PM is clearly the dictator, right?)

Nope.

The tripod is both none of these and all of these. It both listens to / represents its people, but it is not a majority rule system.. It is both ruled by a group of people and gives individuals the power to make final decisions.

If you are working with a PM who’s acting like a dictator, they’re doing it wrong. Please refer them to me. If you are a PM and you’re acting like a dictator, please stop. And also come see me.

But I really, really want a political metaphor...

A much better metaphor is the system of checks and balances most Americans will be familiar with as represented by our three co-equal branches of government. A group of three working toward the greater whole, but with specific, individual areas of responsibility.

Roles & Responsibilities

Why are they doing what is clearly MY job?

The responsibilities of the tripod overlap by design. This can often cause some consternation—someone’s always convinced someone else is usurping their job—but it’s important to understand the primary roles of each member of the tripod as well as the overlapping contributions they may make.

Things I’ve thought or said out loud (to people not in my tripod):

“I just feel like he’s trying to do my job.”

“But I’m supposed to run the sketch sessions!”

“I just need us to get this thing done… AGGGHHHHH”

“But I can’t let them design a solution without my participation!”

Yeah... don’t be me.

What are the definitely locked down and set in stone responsibilities?

Not so fast, rule-follower! While I like to believe stubbornly that these roles are super widely defined and acknowledged, the truth is we are all unique humans. (I’m here for the hot takes.) While there is a general guideline for who is responsible for what, each of us brings certain strengths, interests, and areas of expertise to our tripods.

The lines between each role are bendy… flexible, if you will. They can flex to conform to your unique tripod. The only absolute constant is that you must collectively discuss and define your roles when forming a new tripod. Like any relationship, communication is everything.

What are the more-or-less generally accepted hand-wavey responsibilities?

Product Lead

• The expert in target customer needs/problems/opportunities

• The main representative of company goals back into the team

• The main representative of the tripod out to the rest of the company and customers

• The final decision-maker on overall priorities / and or scoping decisions as a result of collaborating with the other leads

Design Lead

• The expert in user experience personas for the customer base

• The owner of the overall user experience and design aesthetic for the product

• The main representative of company design systems back into the team

• The final decision-maker on implemented designs

Engineering Lead

• The expert in the technical lay-of-the-land for the product

• The main representative of technical capabilities, constraints, company maintenance, and technical debt surrounding the product area

• The final decision-maker on resourcing and structuring implementation within the product engineering team

It’s easy to say the designer has the final decision on designs and the engineering lead has the final decision on timeline and implementation and the lead PM has the final decision on scope, but it’s much more complicated to piece this together in practice.

Tripod Decision Making as a Rubiks Cube (because we needed another metaphor)

Look, this stuff isn’t simple, so I’m just putting it all out there. 

Here’s a common situation that comes up time and time again in product:

-------------------------------------

DESIGN LEAD: Here’s the best possible
user experience

ENG LEAD: Cool, that’ll take us about
6 months.

LEAD PM: Nope. Try again.

DESIGN LEAD: Ok fine we could
cut this piece or phase it in later.

ENG LEAD: That doesn’t really help
us much… PM?

LEAD PM: We absolutely have to have this
piece and this piece, but that piece we could
probably punt on. What do you both think?

[debate for awhile, and comes to shared conclusions]

DESIGN LEAD: Cool here’s a new
design.

ENG LEAD: Would you be open to
changing this design element in this
way? It would save us a ton of effort.

DESIGN LEAD: Ahh, yeah here’s a
revised design.

ENG LEAD: Cool.

LEAD PM: Cool.

DESIGN LEAD: Cool.

ENGINEERS: WAAAAAHHHHHH.
(jk jk)

-------------------------------------

The Rubiks cube represents all of the constraints that the team is working with, and you, as the tripod, have to solve the puzzle together, as a team.

Imagine that your cube has these six sides:

1. Problems to be solved

2. Resource constraints

3. User experience standards

4. Technical constraints

5. Time constraints

6. Prioritization

Now, you may have noticed that “prioritization” seems like a bogus side, and you would be correct. It’s actually a placeholder side. Constraints are unchangeable, but using prioritization we can, in fact, move constraints around to find the optimal product.

Doesn’t fit into a totally important (read: arbitrary) timeline your company has? Ok, turn some rows. Now it fits in the timeline but doesn’t have an acceptable user experience? Great, adjust some columns. Keep working that cube as a team until you’ve got it solved!

The responsibilities of The Tripod

Obviously each member has their own responsibilities within the tripod, but the tripod itself has responsibilities as well.

Ok, what do they do?

• Represent a shared front to the engineers on the team

• Discuss and debate team priorities on a regular basis

• Discuss team performance, concerns, and develop plans for how to address any issues

• Cover for one another in case of illness / emergency / babies coming early / whatever

• When in doubt, unblock the engineers

• Collectively take ownership of the goals and results of the team

• Challenge each other in a constructive way

How do we do that?

You may find that you need to meet as a tripod on a structure basis (once a week, once a sprint, whatever) in order to stay aligned with one another. Alternatively, you may find that simply working next to each other and chatting in ad-hoc ways may work for you. Either way, it should be discussed and explicitly chosen.

your PM Interview take-home is measuring all the wrong things

The infamous “Product Manager Take-Home Assignment” has gotten on my last nerve. I’ve been asked to do them in the past, and my clients now are often tasked with them as well. Every time I look at one, I’m appalled at what I see—because what’s being asked is not remotely what it’s like to be a PM in real life.

Why you should ditch your PM take-home assignment

1. It doesn’t even remotely simulate what it’s like to be a product manager

   Sure, the take-home is testing something, but it definitely isn’t testing your day-to-day product management skills.
   

2. You may inadvertently be measuring how much time the candidate has, not how qualified the candidate is.

   Product managers are high in demand, and often are interviewing at more than one place at a time. With these assignments, interviewing itself can be a full-time job.

   You may miss-out on great candidates simply because they don’t have the time to do homework. Maybe because they already have jobs. Maybe because they have families to take care of. No matter how you look at this practice, it is not inclusive. So stop it already.
   

3. The first step of being a great product manager is to know your customer.

   Without that knowledge, no exercise in the world can make use of a PM’s best asset. Instead, you’re testing a PMs ability to make assumptions about things they have little to no context for.
   

4. Your candidates are not unpaid interns.

   Homework assignments that involve “real-world examples” from your company are nothing more than free work. Have some respect.
   

5. A poorly-structured take-home assignment can actually reflect badly on your product organization.

   Why would I want to work at a place that doesn’t fundamentally understand what my role is?

Determined to have a take-home assignment? Here’s how to have a decent one

Do not make your candidates make assumptions about the customers.

• If you’re going to give a take-home, you’d better include a treasure trove of (anonymized) customer quotes.

• Don’t be stingy—to simulate real life for a PM, they must have access to your knowledge about your customer.

• If you can’t share qualitative or quantitative data for some reason, make it up. Make sure every candidate gets the same packet of info.

Do not make your candidates make assumptions about the goals of your company.

• Contrary to (apparent) popular belief, individual contributor (IC) product managers are not responsible for setting high-level company goals

• While PMs may help define company strategy, it’s critical to give them a little top-down guidance to aim them in the right direction

• If you don’t know what the goals of your company are, perhaps you are not ready to hire an IC product manager.

Do not ask a product manager to develop a go to market

• A go to market strategy is not the sole responsibility of a product manager

• A product manager certainly contributes to this strategy, but relies heavily on other roles (like marketing) to do this

• Also… asking anyone to do a go to market in a take home assignment is absolutely inane. Sounds like a great way to have a candidate spin themselves in circles.

Frame the assignment around identifying key customer problems

• If a PM knows some customer information and understands the high-level goals of a company, they should be able to dig through said information and identify the main problems that both address customer needs and work toward company goals

• They should be able to articulate:

  • The top pain-points of the customer base

  • Their recommended prioritization (without any additional inputs)

  • Next steps for prioritization (e.g. how technical limitations, timelines, etc. might alter their recommendations and prioritization)

• Under no circumstances should the assignment be around designing a solution

Wait, let me say that again.

Under no circumstances should the assignment be around designing a solution

“WHY?” you ask. “I WANT TEH WIREFRAMES,” you say. Frankly, my dear, I don’t give a damn. Product managers should not design solutions in isolation. Ever. Ever ever*.

SAY IT WITH ME: Product managers should not design solutions in isolation.

*Exception: You’re a 10-woman startup and everybody’s gotta be scrappy. Ok fine. Move along. This blog in general is not for you.

But back to not assigning a take-home

Behavioral-based interviewing techniques are a gold-standard for a reason. Past performance indicates future behavior. And so goes product. You’ll get a much better sense of how a product manager works  and thinks by having them walk you through a past project or two.

Stop wasting your time and the candidates’ time—and stop assigning take-homes.

---

Are you trying to hire a product manager? Want some help
structuring your interviews? Reach out for some expert assistance.

---

neapolitan sundae: the three archetypes of product management

Have you ever had a conversation with a product manager where you felt like you were just missing each other completely? That you did product one way, and they did product another way? You both cited articles and sources and were confident you were thinking about product The Right Way™️.

The truth is, while our titles may be the same, fundamentally different types of PMs are needed to keep our product-world running. And they all do product, well, a little differently.

The Three Archetypes

View fullsize

I like to divide the world of product managers into these three basic types:

1. customer oriented

2. consumer oriented

3. optimization oriented

---

FOCUSED ON

needs & challenges of existing customers

PRODUCT ORIENTATION

long-term and strategic

DATA PREFERENCES

qualitative feedback from user research over metrics-driven

---

FOCUSED ON

usage at scale, such as daily active users

PRODUCT ORIENTATION

shorter-term, trend-based

DATA PREFERENCES

quantitative data from a mix of metrics and user research

---

FOCUSED ON

growth of platform / usage / conversion

PRODUCT ORIENTATION

optimizing existing flows & funnels

DATA PREFERENCES

quantitative, metrics-based data over research or qualitative data

---

B2who?

There’s yet another lens to add into the mix: your company’s audience. The style of product management at your company or in your organization is directly correlated to the type of audience you serve. Are your customers using your product for fun, or to get their job done? Is the goal of your product to keep your users around longer and more frequently, or to fill a need on a regular basis?

B2C Archetypes

If your audience is mainly people who use your product (or feature area) for fun, for leisure, or to manage something about their personal lives, you’re probably in a B2C (business to consumer) world. PMs who have a consumer oriented mindset are going to be the most successful in this environment, alongside optimization oriented PMs.

B2B Archetypes

If your audience consists of people trying to do their jobs or trying to run their business, you’re probably in a B2B (business to business) world. PMs who work in a customer oriented mindset will thrive in this type of environment. Optimization oriented PMs are also often needed in a B2B context, but to a lesser extent than those in a B2C context.

Double check your work

Note: You don’t have to provide software to corporations or enterprises to fall into a B2B style of product. When I first started working at Patreon, for example, the generally-accepted categorization was that we were a consumer product. However, Patreon is for creators—creators who are trying to run a business, that is. In actuality, my job in particular fit much more into a B2B world.

When assessing whether you are in B2B or B2C context, don’t use how the brand feels as your barometer. It can lead you astray.

kaizen, agile, scrum

I started my career as an IT Project Manager at GE Aviation (called Aircraft Engines at the time) in Cincinnati, Ohio. I was thrilled to land such a great job straight out of college, and started in one of their famous leadership programs. Despite this sounding obvious now, GE did an exceptional job at preparing me for my career ahead in ways I’ve only recently come to really appreciate.

A key part of my job at GE was to be a technology partner to various business organizations in the company. I spent time with Sales & Marketing, Services, Engineering, and the Technology Services Group—what I liked to call IT for IT. Our business partners walked us through their incredibly complicated jobs, and we would work with them to identify and implement improvements to the way they worked. It wasn’t always quite problem-first—I didn’t know!—but it was startlingly similar to product management nonetheless.

Learning from the greats

Kaizen

Over the years, well before I arrived, GE spent a lot of time studying Toyota’s methods of operating. If you’ve never heard about Toyota’s famed Kaizen method, you should really spend some time and read up on it. Literally, just google “Toyota kaizen” and a veritable shit-ton of information will pop up. Kaizen simply means continuous improvement.

GE (and, specifically, one-time CEO Jack Welch) saw the incredible benefits Toyota reaped from Kaizen, and folded its concepts inextricably into GE’s cultural fabric. You cannot work at GE without hearing about Kaizen and Lean, just as you cannot work in tech without hearing about disruption. (Oddly, one concept is much more valuable than the other.)

Seeing is believing

I was lucky enough to have an opportunity to tour a Toyota manufacturing floor in Kentucky not once, but twice with other GE employees. It was absolutely fascinating—I loved being on the floor and seeing both the results of Kaizen, and the actual in-process practice of Kaizen. Factory employees are empowered to identify things that are making their job more difficult and be a part of their solutions. I distinctly remember watching a literal robot that carried tools to workers, using a magnet to follow a metal line etched through the floor. That started with the workers. That was Kaizen.

Lean before digitize

While its applications to a manufacturing floor are fairly obvious, I did not work on the floor next to the enormous jet engines. But GE had figured out how to weave the concept into its technology organizations as well.

Lean before digitize

As technology partners, we were often engaged to take a complicated, manual process and build (or buy) a tool to enforce and track that process. As any IT employee knows, we were often challenged to do more with less every year with every new budget. It was therefore our job to eliminate as much waste as possible from our projects. The number one way to eliminate waste? Remove waste from a manual process before building a digital tool to codify it.

Tame that process

I watched a lot of leaders, Six Sigma Blackbelts, and Master Blackbelts facilitate process mapping sessions. They asked critical questions, like… is this approval step necessary? What’s the goal of step x? If we’re gathering that data, what are we doing with it? And, over time, I got pretty good at doing the same. I’d be met with a process, and I’d tear it apart and rebuild it to be the leanest form of itself that still met the business needs.

Get to the point, Erin

I digress. This is not about my ability to tear apart and rebuild a process anew (although I find that stupidly fun). Rather, it’s about learning from old concepts and integrating them into the way we work in this age of technology.

Agile, Scrum, and Kaizen

We, the people of Tech, are enamored with buzzwords like Agile and Scrum. And yet, we fail to see the direct parallels to industries who have been using Kaizen and Lean for decades. Agile is to continuous delivery what Kaizen is to continuous improvement. And Scrum is the join table that binds them together.

Ehh? ehh? I mean… it made sense to me…

Scrum has been widely adopted in software engineering organizations as the process for building products, though ironically it’s often used alongside waterfall methods of product delivery, rather than Agile. Often, though, I walk into organizations that know little about Scrum beyond stand ups, or are worried about adding “too much” process.

Process is not the enemy

But process itself is not the enemy. Stagnant processes—processes that aren’t continuously improving over time—are. Scrum does not prescribe a specific process, rather it gives you the scaffolding of a starting template and the tools to tailor it to your organization.

Just as Toyota empowers its people to call out inefficiencies and solve them, we should be empowering our product engineering teams to do the exact same thing. Are we having a meeting weekly that adds no value? Speak up! Let’s figure out what the original purpose was, and then determine whether it’s still needed. Scrum is just as much about reducing process as it is about adding it.

Designing a process

Let’s say you get it, and your team is ready to embrace process! Where to begin? Well, luckily, process improvement is remarkably similar to product management. Start with some basic questions:

1. What problem is this process (or step) trying to solve?

2. Who is the audience?

3. What’s the current user experience?

4. What are the unintended consequences of the current process / step?

5. What are our constraints?

6. What are possible solutions to the problem this process / step is trying to solve?

7. Which is the best solution for the problem and user experience?

We’re constantly improving our products, and we should be constantly improving our processes. We have the skills, our people have the drive—they just need the freedom.

Unleash continuous improvement. Embrace Kaizen.

your mission

We tend to think of PMs as jacks of all trades… of great product idea people… of having constant meetings and never-ending to-do lists. And yeah… ok so that’s true… but that’s not the most important part of the job.  Even if you’re starting off as a PM and you know all the things you’re supposed to do, you still might be overwhelmed by the sheer volume. How do you know how to prioritize all of these things that seem equally important? It’s a lot.

But, it’s actually pretty simple if you pare it down to the basic things you, as a PM, should be doing.

1. Know your Customer

2. Motivate & Inspire your Team

3. Empower your Team

4. Remove Obstacles for your Team

5. Know your Customer

Know Your Customer

I’m not going to spend a lot of time here. That doesn’t mean, however, that you shouldn’t spend a lot of time doing this.

You must talk to customers.

When you’re talking about a problem you’re trying to solve to, well, pretty much anyone, you should be able to name the humans you’ve spoken to that have experienced that problem. Without any prep. You should be able to say, “Oh, yeah I was just talking about this exact problem with Hillary from [famous person’s] team!” or, “Wes described his experience with [feature y] last week on the forums.”

Good politicians do this all the time. Candidates are always talking about [insert first name] from [insert city or state] and their challenges. They use these stories to show that they are in touch with real people and real problems. They use these stories to inspire their teams to help them canvas. These constituent stories are nothing more that customer stories. You, as a PM, should talk about your customer stories just as effortlessly as a candidate running for office.

Motivate & Inspire Your Team

All good PMs should be systematically trying to work themselves out of a job.

Seriously. Great PMs should use every moment as an opportunity to inspire their team. They should be so passionate about the problem their team needs to solve that the team cannot help but care about the problem. The motivation should spread like a god-damned virus. You should hear engineers talking to each other in the hallways about the problems your users are facing.

What do you think the productivity differential is between an engineer who cares about the problem they’re solving and an engineer that is simply writing code to a spec?

I don’t know and, to be honest, I don’t particularly care, because it’s enough for me that humans are enjoying their jobs. Then again we’re PMs, and no matter how human-focused we want to be, at the end of the day there is a company who needs us to get shit done. It’s a rhetorical question. Obviously motivated engineers are way better for a company, as long as you do not exploit that motivation*.

*An aside about Caring and Exploitation

That last bit is important. You want your engineers to be productive while they’re coding… you don’t necessarily want them coding more or for longer hours. And if you find that that’s happening, go stop it. In general, your engineers are probably only coding for maybe 3 hours a day (depending on the day). You should NOT see engineers coding all day every day, because they should also be doing all of this:

• Thinking deeply about the problem they’ve solving

• Thinking deeply about technical design

• Doing code reviews

• Interviewing to help your company grow

• Cross-pollinating with other engineering teams

• Pairing with other engineers

• Taking a walk or grabbing a coffee to let their brains marinate

• Prioritizing technical debt

• Testing the stuff they build

• Shit I don’t know… I’m not an engineer. But like… they’ve got stuff to do. Respect it and Get out of their way.

Anyway. Thou shalt not exploit caring.

Empower Your Team

Over time, your product-engineering team will develop its own ability to practically PM itself. A team that works together consistently over time on particular problem spaces builds up domain knowledge in those areas.

• Teams become more familiar with the code base for the product areas they work on

• Teams begin to see and understand trends in the problems they solve for their users

• Teams experience user feedback to the products they ship

A team like this has hit their stride, and all of that “slowing down” from being a part of the solution process is paying off. A PM for an empowered team will still prioritize problems and present those problems. But when it comes to defining a solution, they will simply become a resource.

An empowered team doesn’t even need a PM in the room to work on a solution.

The engineers and designers know enough and have enough experience in the domain to make a kickass product.

Remove Obstacles for Your Team

So you’ve lead a team and they’re empowered and cranking out wonderful products. Don’t get too complacent, because your job has now shifted. Your primary responsibilities are:

1. Unblock your team

2. Continue talking to customers

3. Continue iterating on the long-term vision

4. Unblock your damned team

Occasionally you may onboard a new face to your team, and during some dark times you may still need to inspire or give a pep talk or two. Your main, day-to-day responsibilities, however, will mostly be making sure the train stays on the rails.

Often PMs are inundated with emails or Slack notifications or whatever the current hotness in productivity is. No matter the tool, prioritize your inbox/notifications/whatever to focus on unblocking your teams first. Is there a comment or question on a JIRA story or github PR? First order of business. Do all the support tickets assigned to your team have appropriate replication steps? Is there a backlog of at least two weeks’ worth of stories written and prepped?

Unblock your team first thing in the morning before you do anything else.

That’s your mission. Choose to accept it.

That’s it. That’s the job. Know your customer, inspire your team, empower your team, then get (everything) out of their way.

Glamorous? Nah. Satisfying to sit back and watch the team do its thing? You’re god-damned right.