Category: Content

This article was originally posted on Mind the Product on September 6, 2022.

---

A great product culture attracts great product managers. But when it comes to how you, as a product leader, should shape product culture, there’s a lot of advice out there like “empower teams” that feels so big in its scope that it’s hard to take action. It’s very easy for managers to say “yes, let’s build a great product culture” but much more challenging to make the change.

Teams practice great product management by having the product operations at the company set up for them to thrive. It then naturally follows that a company’s product culture is shaped by its product operations (product ops). Neglecting product ops creates an inconsistent, stressful, and less effective product culture. When leadership pays attention to product ops, it makes it easier for every team to function and pays dividends as a result. Below, I’ll dive into the connections between product ops and product culture, why product ops is an effective lever to pull to shift product culture, and how to begin shaping your own product culture through product operations.

Explaining product culture

Product culture is a subset of company culture – as VP Product explains: “[Product culture] also defines how an organization works, what values it holds etc. In short, it defines how the staff at an organization behaves toward each other and the outside world.” A healthy product culture will be more likely to ship successful products and create more business value. An unhealthy product culture will struggle to ship software that consistently has a positive impact on company goals.

Make it easy for teams to practice great product management in order to craft an excellent product culture. Find ways to make it easier for product managers on your team to use all the data at their disposal for better decision-making. This ultimately means delivering more value to customers, faster.

Unrealistic expectations

Product leaders ask for a lot from product managers, but then put the onus on the PM to accomplish everything within those expectations. PMs are expected to be strategic thinkers, project managers, tech interpreters, customer evangelists, user researchers, go-to-market experts, copywriters, marketers, data analysts, entrepreneurs and then some. They are constantly being told that if they “work smarter, not harder”, then they will succeed. I’ve seen a lot of product leaders then coach them on prioritization of time, how to “hack” their schedules, and coming up with other suggestions on how to improve efficiency. But focusing exclusively on time management is treating the symptoms, not the underlying issue.

Even though those leaders are trying to support their reports through the role, expecting the PMs to find time to work on creating more time in the day makes the entire situation worse. And most product leaders I know are extremely busy themselves, so they are limited in their capacity to help.

When PMs are asked to figure it out on their own, a common pattern emerges: every product manager on the team tries to hack their way to productivity in a way that works for them. Sometimes it works great, sometimes it doesn’t. The organization has a different way of working depending on which team you’re on, forcing partners to adjust their mental mod as they work with one product manager and then another. Engineers feel like they need to navigate new ceremonies, agile practices, and development habits every time they switch to a new team, and executives start to complain that they don’t know which product manager to go to for what questions. This lack of unity taxes the entire organization and creates a sense that “there is no product culture”. Performance across individuals is inconsistent and people talk about the “good PMs” and the “bad product managers”.

Companies place massive expectations on product managers and then struggle to support them to meet those expectations. As managers, it’s our job to look at the environment they’re in to help them thrive.

The path of least resistance

If it is harder to follow product management best practices, it is less likely the product manager will excel and more likely that they will describe the product culture as “weak”. It isn’t a lack of desire or knowledge about what great product management looks like – it’s just that there is too much friction in the role to be a great product manager all the time.

So as a product leader, our job is to make sure that it’s as easy as possible for them to do the things that are most important. Want them to do more user research? Make it automatic to schedule calls with customers. Believe that great roadmaps improve cross-team collaboration? Create templates and playbooks on how to communicate the most information in the least time-consuming way possible. And most critically – give the team permission to not do certain things so that their time can be freed up.

All of this work falls under the category of product ops. Creating systems, patterns, and paths of least resistance to doing great product work. And it’s worth your time because these things can start to amplify each other. Better user research means that it can be easier to develop with engineers, leading to less time slogging away on user stories, freeing up more time for other things. Strong roadmaps mean less time where cross-departmental partners in marketing, sales, and customer support are asking the PM for status updates on what is coming down the pipeline. Product ops is the epitome of “work smarter, not harder.”

The first step in product ops: the assessment

Just as with all of product management, the first step towards coming up with a solution is understanding the problem. Run a product ops assessment. Determine what goals you should be focusing on. Figure out where there are structures, tools, and processes in place to enable the team to succeed, and identify where better support systems would lead to better outcomes.

Talk to your team. Figure out where they’re struggling and how they want to be helped. Craft a plan to actually put together the support system to make them thrive. And then get feedback on it and iterate. And if you don’t have the time to do this yourself, bring someone in for a few months who can move it forward.

The short version? Good product ops treats your product organization like a product. Identify unmet needs, build solutions, measure, and iterate. The investment in the people doing the work is well worth it. Whether you have anyone explicitly working on product ops or not, it exists anyway. Best put some effort into shaping it, lest it get out of control.

Public Health Reports, Special Edition on COVID-19
Henry Bair, BS; Jenny D. Wanger, MBA; Nirav R. Shah, MD, MPH
Published: June 8, 2022

Abstract

The swift global spread of COVID-19 prompted public health authorities to explore digital technologies to aid in contact tracing for infection control. Exposure notification, a mobile device–based technology that notifies individuals of potential exposure to COVID-19 without requiring personally identifiable information, has been broadly favored because of its relative ease of use, scalability, and protection of personal privacy. Although several exposure notification protocols were developed, a partnership between Google and Apple led to the development of the most widely implemented exposure notification protocol in the world, including in the United States. In this article, we first describe the development of the Google Apple Exposure Notification (GAEN) protocol, noting the value of the discourse among software developers and public health authorities concerning the protocol’s design and features. We track states’ deployment of GAEN mobile applications (apps) and population-level adoption rates, finding the nationwide rollout of GAEN apps to be more fragmented than anticipated. We then discuss how the limited data collected from these apps make assessments of their effectiveness challenging. Finally, we consider the importance of the federal government playing a greater role in GAEN’s early development, emphasize the power of public–private partnerships, and highlight the overriding importance of public messaging over technological details.

This article was originally posted on Mind the Product on February 20, 2020.

---

To help hiring managers and recruiters, like myself, decide whether or not to interview you, it can be a great exercise to treat your resume like a professional product. Here I’ll share some useful pointers on how to do just that.

Having reviewed hundreds of product managers’ resumes in the last year I’m sure I’ll have overlooked some fantastic candidates, simply because their CVs didn’t shine. Building on some of the other excellent career-as-a-product posts and talks out there, let’s do a deep-dive into your resume.

Consider this article a requirements document: it’s structured into several user stories from the perspective of a hiring manager, for a product manager role. I’ve pulled in examples from real product managers’ resumes to help you think about how you might improve your own.

Use this article as a guide to polish your resume and improve your job-hunting prospects. Ultimately, your resume should itself signal that you have the skills required to be a successful product manager on any team.

This advice is designed to apply equally well to those looking to break into product management as well as those who are already experienced in it. If you’re

• an experienced product manager, I’d expect to see strong examples of your work in your resume
• looking to break into product, I’d expect to see your non-product management work explained in product-driven language

And in both cases, no matter what, keep in mind that your resume is just one part of your job application. You will, of course, often need to take multiple steps to land that interview.

Storytelling

As a hiring manager, I want to hire great storytellers, so the team can work towards a unified vision.  

Product managers need to be expert storytellers, and a resume is simply your story in bullet-point format. It needs to explain your journey into and through product management, as well as the evolution of your products.

If you’re looking to move into product, your resume needs to explain how your past experience is relevant for work as a product manager. Think of your previous roles as prototypes for a product management role – you might not have had all the features of a full product management role, but you had some of them. Highlight the relevant features of your previous roles.

The following is how one product manager describes their current role on their resume:

Leading a team of 20 people (analysts, developers, QA) developing one internal tool and integrating another external tool used by 800 agents on a daily basis.

Note for this example that the applicant just tells us what they did in a very literal sense. I could use this same sentence for a product, scrum master, or engineering manager role. In addition, “leading” in product management can be very vague. They could improve their resume quite a bit by being more specific:

Running ceremonies, identifying feature gaps, and defining requirements for a 20-person cross-functional scrum team building an internal tool to improve call center operations.

I can now understand a lot more about the product and role, without taking up more space on the page. Take a minute to look at each position on your resume and check that there is one bullet point that describes the role you had and the product you were working on.

Data-Driven

As a hiring manager, I want to hire people focused on gathering good data, so we can craft good hypotheses about what to build next.

Every product manager needs to be data-driven. This includes qualitative and quantitative data. Use your resume to show how you’ve made decisions using data. This could include different tests you’ve run, quantitative analyses that have helped you make a better choice, or user research that has changed the course of your roadmap.

One product manager described their decision-making as follows:

Engaged client executives to assess strategic business needs and challenges, and translate business strategy into human capital opportunities with business impact.

This excerpt tells us at a basic level what the story was, but it could also use a dose of specificity. And any time you talk about strategy or roadmaps is a great chance to highlight your data skills:

Ran an ROI analysis and presented results to client executives, leading to a redefined strategy for our employee hiring and training programs.

See how adding a layer of data (and detail) enhances the story? If every bullet on your resume looks like this, it can highlight a wide range of relevant experiences, frameworks you’ve used, and the tools you’ve encountered. With this I can find reasons to interview you because I have more confidence that you have the right experience for what’s next.

Impact-Oriented

As a hiring manager, I want to hire people who measure their impact, so we can make sure we’re building the right things for our customers. 

Great product managers never stop measuring and communicating the impact of their decisions. Use your resume to highlight your successes and failures (aka learnings) through the performance of your product.

One thing to note: it’s far more useful here to talk in relative rather than absolute terms. Without context, increasing revenue by $1 million per year can either be revolutionary or quotidian. On the other hand, increasing revenue by 10% clearly shows the scale of your contributions.

Use detail and clear KPIs like this product manager to demonstrate these skills:

Introduced KPIs and evaluated success; depreciated underperforming features which improved engagement by 34%.

Note how good use of metrics reinforces the other two user stories – this bullet point is a mini-story where data led to a decision. The one thing that could improve this even further would be to add why removing the features led to increased engagement.

If you’re at a company that doesn’t measure the impact of your products or if you can’t share your KPIs for some other reason, talk about what you did to push your org’s culture in a data-driven direction. Did you install analytics or build dashboards? Tell us about it.

Iterate and Refine

Combine these three pieces together to make your whole resume shine. In combination, you have data-led stories which demonstrate the impact you’ve had on the teams you work with. This provides the hiring manager with a strong understanding of what they might be able to expect from you if they were to bring you on board.

Like any product, your resume should be a living document. Seek lots of feedback from as many sources as possible to make it better and better. While these concepts sound straightforward and simple, you’d be amazed at how many applicants have generic resumes which don’t tell me enough about them to move forward.

Thank you so much to the product managers and aspiring product managers who gave me permission to use their content for this article. Best of luck on your next job hunt, wherever it may take you!

UPDATE: I revisited this topic in 2025 and have done a 180. Read all about it: Stop scoring everything: how to prioritize with strategy

This article was originally posted on Mind the Product on February 7, 2019. It is based on a talk I gave at INDUSTRY in 2018.

---

Prioritization is challenging and stressful. Sometimes it’s because of micro-prioritization such as bug triage and moving one small fix in front of another. Other times it comes from the macro level: deciding to target new user growth versus lifetime value; spending time on user research or analytics; handling your manager’s feature request versus the tech debt the engineers beg for.

And then there’s the squeaky wheel. This can be a person or a topic, but it’s always something where I feel like an all-caps message came through: “THIS IS A BIG DEAL!! FIX IT!” Given that I want to be good at my job, please stakeholders, and solve problems, I’m always tempted to rush to make things right. I tell myself that if I just knock this one out they’ll go away and I can return to my regularly scheduled programming.

This happened to me recently. We’ve been reworking our home page and in the process found the search bar had a bug – a strange loading effect where it flashes gray for a millisecond. The product team decided to ship with this bug and we put it in our backlog to be fixed once we took care of a few other stories. An engineer on another team saw the bug and was concerned about it, starting a conversation on Slack that escalated to the point where I had multiple people messaging me about when we were going to get this fixed.

Nobody likes shipping imperfect products, but at the same time we all know that we can’t hold off to wait for perfection. I had a prioritization challenge in front of me – do I change our backlog and move this story up or stick with the original plan?

Squeaky wheels get more complicated with status. I have been in situations where a C-level executive said, “we need to build something like THIS!” and laid out feature requirements. However we had a list of features that had already been validated by user research. Do we move this idea up and begin to research it, or go with what we know?

The best way to solve for squeaky wheel syndrome is to have a prioritization process in place ahead of time. A system removes the personal from these conversations and turns it into a conversation about the values you’ve established as a team. Because it’s systematized, there are more consistent inputs and outputs which mean that the emotions anyone is feeling that day are removed from the equation.

So that bug on our home screen? I was able to lay out that our system defines issues in terms of severity. This bug has a certain severity score and should get pulled in next sprint, but we don’t interrupt work in progress for that level. Given that we already had those standards established, I was able to quiet everyone down and get back to work. They were able to trust the system and were glad that I had heard them and had a plan in place.

What about the CEO, however? Can a prioritization process help you through larger feature development and tactics? Yes, if you have a system in place. But the only way your system will work is if your leadership believes in it as much as you do.

Pick a Method, any Method

When it comes to building out a prioritization system, it doesn’t matter which you choose. RICE, Kano, MoSCoW (who came up with that capitalization?), or any of the other ones out there – pick one you like and run with it.

The only thing that really matters is gaining support for your prioritization system. If everyone has agreed on what prioritization model your team is using, they became part of the decision to de-prioritize their idea. And if they still don’t like the outcome and want to be a squeaky wheel?  It shifts the conversation from “Product refuses build my thing” to “The system says that my idea isn’t the most important thing to work on right now”. Any debates become about whether the process is working or not instead of a personal conflict between product and the requestor.

Step 1: Define Prioritization Goals

We began by talking at a high level about our goals as an organization. All product teams did this at the same time, and we all made sure our executive stakeholders and leadership were in the room. Once we felt like everyone had the same sense of our guiding principles, I asked our stakeholders to list out all the goals for my product team. I said yes to every goal they mentioned. The list was a little long.

So I asked: “What do we do if we have an idea that we think might improve customer satisfaction and retention, but will decrease our margins? Should that win out over an idea that might increase total revenue but could cause more calls to customer support?” Our extended leadership team hadn’t gone into deep discussions about our product KPIs before, so this was a good opportunity to help them learn more about the product process. Once we had a short list of goals in hand, we wrapped up for the day.

Step 2: Customize a Framework

When the team reconvened, it was time to talk about frameworks. We chose a RICE model because it leads to numeric scores for each item on the list and matched well with the objectives we had chosen for the product. We didn’t spend too much time choosing the framework.

We spent a tremendous amount of time customizing the framework. If you use something off the shelf, it’s too easy to say “well, that worked for so-and-so, but it isn’t going to work for us”. You create room for excuses. When you customize the framework to fit your needs, everyone has shared ownership.

We thought about customization in several ways – the first was categories. Instead of Reach, we talked about the number of customers who would see this per month. Impact became two things – reduction in customer support calls and increase in average order value. Our definitions allowed the model to use the language we use when talking about our business.

The second way we customized was with the definitions. Within our framework we defined that a big impact might be so many thousand extra customers taking an action, while a small impact might be defined in a different way. Each category had clearly outlined definitions of small, medium, and large to make sure we were having an objective conversation.

Our final customizations were in how we weighted each category. Instead of everything being equal, we decided to weight growth more heavily than cost savings. This allowed us to make sure we were doing more of the things that would help us succeed long term as a company, without completely ignoring the reality that we can’t just be a company that spends forever.

Step 3: Prioritize Ideas

Only now, once we had talked about goals, chosen a framework, and customized it, did we begin to put ideas into the model. I got to say yes to every idea that came my way, whether I thought it was good for our business or not. We placed them in the model, filled out the framework, and got our scores. A little final tweaking allowed us to make sure everyone felt comfortable with the results.

The prioritization system switched our conversation. No longer was product responsible for prioritizing in a vacuum. The entire company had a voice in prioritization, and the model helped us understand whether we were making good choices or not. Now when someone comes to me with an idea I always get to say “Yes, let’s add it to our model!” and the data helps us say yes or no as a team.

What if someone disagrees anyway? They’re upset because their item is still at the bottom of the list, and that’s understandable. At that point your response can be: “Okay, what do you think needs to be adjusted in the model? Do we need to weight things differently, do we need new categorizations?” It gives us an opportunity to talk about the goals for the product and company overall, and we decide as a team what the best next steps are.