Hiring in product is broken, and those hypothetical product questions you get asked in interviews are just the tip of the iceberg.
“Describe a coffee cup.”
No, you’re not in the middle of a therapy session, you’re in a product manager interview, and a bad one at that.
If you can, you should get up and walk out, because your interviewer’s bias is about to count against you.
Yes, bias.
These types of questions are great if you look, sound, and have “the resume” the interviewer dreams about when they put up the job posting (none of these things are explicit. It would get them sued).
But because they can’t be explicit about what they want (anti-discrimination legislation and all that) here you are, describing a coffee cup, and unintentionally running directly into a process that is full of bias.
Sorry to break it to you, but if you don’t look like you fit on the company’s “about us” page, you’re in a world of trouble.
How did we get here?
Enter the product hypothetical – for a long time, companies have been using interview questions like “how many matches could you fit inside of an airplane” or “how many gas stations are in the country” as a way to understand how someone thinks.
But do these questions really help you to understand how product people think? I posit that they don’t. Instead, they land us in a world where bias wins and rational thinking loses.
What do I mean by that? Let’s ask the world of behavioral science.
Behavioral Science isn’t new
Behavioral science teaches us about our mind’s proclivity to lean towards bias, specifically cognitive bias.
In fact, we’re cognitive bias machines. I learned this while reading about behavioral science from two of its foremost experts, Daniel Kahneman and Amos Tversky. The pair spent their lives trying to understand the WHY behind our behavior, and for their efforts, they became two of the world’s most cited academics.
Kahneman’s seminal work, Thinking Fast and Slow, talks about our system 1 – intuition, and system 2 – rational thought. Most importantly the book shows us that our intuition is a hotbed of cognitive bias, one that can be controlled by almost anything – from how much we’ve eaten in the morning to the last argument we had with our spouse. Do you want your choice of breakfast to determine the next person on your team? Relying on intuition means it could play an important role.
Back to bias
The Kahneman and Tversky research points to system 1 as being susceptible to bias.
Most product hypotheticals have no guideline, no rubric, and rely on the “intuition” of the person giving the hypothetical to determine what happens next.
Ask yourself, when you’ve seen a product hypothetical with clear criteria? And by this, I mean a situation in which the criteria have been clear for both the interviewer and the person being interviewed.
While the person on the other side might be trying their hardest to work out a complex system, the interviewer is just listening, usually passively. With no rubric, no grading structure – they end up at the whim of their system 1 thinking.
What happens as a result?
Unfortunately, in this situation, the interviewer is more likely to play heuristic bingo (a term I’ve created that describes when we let our bias control our decisions).
Heuristic bingo is a good thing when deciding where you want to eat for lunch, but when it comes to hiring, it leads to disastrous consequences. The interview process becomes less about skills, experience and know-how and more about what we expect people to look and sound like.
For folks like me, who aren’t white from privilege, it means you end up a casualty of the process, no matter what your skills are. This plays itself out during the hypothetical section of interviews where the interviewer relies more on whether things ‘feel’ correct rather than if they are interesting or match criteria.
If that person says something novel, it is discounted. This is particularly insidious in product management because most of the work is contextual, and a best practice at Facebook may (actually, probably) mean absolutely nothing at your company.
How do we avoid bias?
Let’s shift to system 2, our rational thought, which is less susceptible to cognitive bias.
One of the easy ways to get into system 2 thinking is to have a long conversation about someone’s life. The good news is that interviews already have a vehicle for such things – it’s our experience.
People have no problem telling stories about how they did something. The important thing to remember is that you’ll need to really dig in, as an interviewer, to know what “something” you are looking for. Your questions are important.
This is no different from trying to solve a problem for a product you own. This is the time to ask questions and get context around how this person’s experience helps your company to solve that problem.
It’s time to talk to people more
Our brains are built for stories, and in hiring, we need to take full advantage of that. So instead of asking people to create, just ask them to recall.
Talking to people and asking them to recall will help you to uncover their stories, through which you can learn about what they’ve done.
Their stories will be filled with details and these details are enough to see if someone is being honest. They also give you room to ask follow-up questions to get to the bottom of what you need. Write them down so you can check them against your criteria and understand what you’re looking for.
For extra points, recording and rewatching the conversation (especially if someone is further along in the hiring process) can give you, the interviewer, more insight into this person’s experiences. It also gives your ‘system 2’ enough time to think about the conversation.
Let’s be clear — hiring in product is broken. In fact, many tech companies are failing outright when it comes to hiring equitably, despite the statements many have made in response to recent police brutality. These statements have been highlighted in a database published by The Plug, in response to which, The Plug founder, Sherrell Dorsey, has reported that at the majority of companies in the database so far, less than 4% of employees are black.
Talking about product hypotheticals is, therefore, only the tip of the iceberg, as there are systemic injustices that lead to inequality everywhere, as recent events clearly illustrate. If we’re to make a better world, we need to work for it.
With that said, getting rid of hypotheticals now can give you the space to focus on a more equitable hiring system by listening more to candidates and asking them about the problems that they are dealing with.
What kind of relationship do you have with your company’s customer success team? I often ask product teams this question, and the answer is usually that there isn’t a relationship at all. And if there is, it’s hanging on by a thread. The product team never connects with the customer success team except when it’s time for an “enablement” session. The session is designed to allow other teams to understand a product. This meeting, though, is likely to just be a quiet presentation and Q&A.
Meanwhile, the customer success team tends to see the product team as the product feature repository. They just drop off feature requests and then go back to their own work.
Both forms of communication are reactive. Customer success hands off customer problems with solutions and dates to the product team. The product team uses customer success as a shield against the customers themselves. Neither team leverages what the other knows to maximize their ability to collaborate on solving big customer problems and innovating in the marketplace.
But that dysfunction isn’t the most significant issue. The organization is building a culture of resentment. The teams will continue to resent one another until something changes. So, they’re losing in two ways. They lose the opportunity to leverage the intelligence of both teams, and, because of the resentment, the business misses out on some moonshots that could change its overall trajectory.
Before we talk about the tactics we can use to make things better, we first need to address that resentment. Remember, it’s the product manager’s (PdM) job to increase the overall decision fitness of the organization. By decision fitness, I simply mean how well the team makes decisions. Good product management leads teams to consistently make better decisions. You won’t be able to level up in this area if there are no clear lines of communication between customer support and product.
So, let’s talk about how you can identify some of the issues both teams have with each other, create more precise lines of communication, and tie it all to your culture so that it stands the test of time.
Identifying Issues
Your customer success team is likely the lowest paid and the least listened to team in the building. Their job is often a taxing one. It’s a matter of when and not if customers are going to yell at them. The customer success agent is on the front lines of frustration, listening to customers vent during their lowest moments of using the product.
Your job as a product leader is to take the opportunity to sit down with them and listen to what they have to say. If the poor relationship between teams that I described before sounds familiar, they will likely have a lot of valuable information to tell you.
Let’s set the stage with BobCo, where two leaders, Jill, the new director of product management, and Bob, the new director of customer success, are connecting for the first time. They plan to get the company on a better path and leverage each other’s team for better product outcomes.
Bob and Jill both took the time to listen to their teams for the first 90 days of their tenure. They also talked to other disciplines, like engineering and sales, to get a solid overview of the organization.
Both connected with a random distribution of people, taking advantage of their newness to the organization, and led one-on-one conversations with everyone on each team around three subjects.
3 GOALS FOR ONE-ON-ONES
Establishing competence — “Here is who I am and what I’ve done.”
Laying out their vision of the future — “This is what I want to do.”
Building a bridge between the other team — “How can my team help yours?”
Replacing Resentment With Trust
Bob and Jill both know that the secret to identifying issues is to build trust. That trust must first start with themselves, so Bob and Jill spend time listening to each other and developing a shared vision of their futures.
They spend their first few conversations feeling each other out. Once they get to know each other a bit, they agree that a team conversation will give them a jump-start on understanding how product and customer success can work together.
How should they frame this conversation between the two teams? I’m a big fan of the team retro process laid out by NOBL.
A team retro gives the facilitator and the relevant team at least 60 minutes to get everything out on the table. Remember, the retro process isn’t about blame; it’s about level-setting and improving, so make sure you use your time together to get a clear lay of the land. In our example, both teams more than likely have some misconceptions about the work the other does. It’s finally time to clear them all up.
Both Bob and Jill are coming into teams that already exist. Like most of us, they have to deal with the culture that’s already there. In this case, it’s one that is marked by the resentment that I mentioned earlier.
Without presenting a solid foundation to both teams, one that establishes competence and tells a story that people can trust, and showing that they trust one another, they know this process can fall apart.
A team retrospective can raise issues that plague teams and businesses. Both leaders are committed to handling the pressing problems upfront, by writing them down and following up. They present regular status updates to ensure that no one had to work to find out what was happening. They also keep each other accountable by holding routine check-ins. All of these steps can go a long way to establishing trust.
Building Bridges
So, you’ve done the first team retrospective. Put the next one on the calendar in about a month. Keep this meeting a consistent part of both teams’ workflow. Every time each team talks, you’ll build more trust. But you’re not done there.
After the retro, Bob and Jill realize that just talking about the issues won’t be enough. Instead, they need to change how the teams communicate. This change means moving from a reactive approach (enablement and feature requests) to a more proactive one. Making this shift requires bringing both teams into regular contact during product development.
So, they pick one point during a sprint for the customer success team to meet with the entire product team to talk about development and see how customers may engage with the product as it’s being constructed.
This connection point helps the customer success team understand how to talk about the product with customers and get their insights. Because they now know how to frame these insights, the product team is more likely to receive this feedback instead of brushing it aside.
And this new structure leads to an important point. Customer success teams have a good understanding of the emotional state of reactive customers but aren’t always clear about the problem set of proactive customers.
Bringing the customer success team inside the process allows them to guide the product team in addressing the customers’ emotional needs as it’s building the product. For example, say you have a section of customers that are angry about your latest widget. The customer success team can take a look at the next iteration of the widget and tell you exactly what they are hearing, which will help the product development team avoid potential landmines.
Jill knows by bringing Bob and his team around in the middle of the process, the team can make sure they solve more pain points and build a better story to present to the customer. Bob knows by bringing Jill around, his team can frame customer requests more effectively.
Keep in mind that the PdM should under no circumstances consider this feedback qualitative research, however. The customer success team’s involvement isn’t a replacement for talking to customers. But it is a great way to make sure each team is making the most of one another’s expertise.
Be Transparent
Bob and Jill know that working together will lead to stronger teams, but they need to make sure they can keep it that way. After all, these are two teams that have had some contention before. Bob and Jill need to keep the newfound trust going.
The continuing retrospectives will help to identify any trouble between the teams as it happens. This relationship isn’t going to work like before, though, and change is fragile. So, leaders will have to talk often about both successes and failures. Transparency is the bedrock upon which you build trust.
You’ve already made some serious inroads if you’ve adopted the retros and invited customer success into the development process. The next step is to instill a culture of transparency.
Bob and Jill set up a report designed for the business; they call it the BobCo Product to Customer Report. Inside, they highlight anecdotes from customers and how the different product development teams are each building products that meet the needs of the customer. Those anecdotes fit the story the product team is trying to tell, and speak to how those customers will be affected by the change. They also include data about research, renewals, churn and team changes.
Are new hires coming in to shake things up? Is the team doing some tech debt initiatives that mean new features can’t happen right now? Are you holding office hours? All that information should go into the report. This report then goes to the rest of the business to build trust and allow them to keep an eye on the product strategy.
Customer success and product can work well together. What does it look like when it works?
Important customer information gets back to the product team and influences strategy. Remember, product management’s job is to improve decision fitness. By taking in the emotional energy of the customer, we can better understand their points of view, leading to better decisions. Customers aren’t acting out. Their feelings come from somewhere. Customer success holds the key to understanding where.
A strong relationship with your colleagues in CS will give you a much higher success rate when launching products.
How do you build such an alliance? I put the onus on the product team to manage the relationship and bring out the best in the teams around us. Product isn’t just a translation service — it also is a diplomatic one. We’re here to build bridges to help us level up the decision fitness of the company as a whole.
Our customer success teams are on the front lines keeping things running every day. We have an opportunity to use that expertise to make better decisions about the products we bring to market and how our product development serves customers. We get there by making sure that we stay open, bringing them along, and continuing to build trust through transparency.
Building the right products is a team effort, and when we all work together, great things happen.
Because the world moves so fast, product management is seldom a linear process. We can’t afford to let our thought processes be linear, either. Welcome to product calculus.
Think back to your school days, and specifically math class. As you moved past arithmetic, you probably started your journey into advanced mathematics with algebra. As you built up your mathematical skills, you may have taken any of several different classes: geometry, advanced algebra, trigonometry, probability and statistics, and so on.
Often, a high school course of study in math culminates in calculus. That’s because, to master calculus, you need to have a solid foundation in all the other forms of advanced math. Calculus encompasses and builds on aspects of each of the other branches of math you’ve learned to that point. It challenges you to synthesize all your skills and take a step forward in your intellectual journey.
So, why am I talking about high school math? Well, it turns out that this provides a pretty good analogy for product management. When it comes to product management, some people are doing product algebra and others are doing product calculus. I’ve found that a lot of people in product think algebraically long after they should have progressed to calculus. So, let’s talk about how to avoid that and how to deepen your product thinking just like you did with your mathematical thinking.
WHAT IS PRODUCT CALCULUS?
Product calculus is a philosophy that embraces the fact that, as product managers, the ground is constantly shifting under our feet. Rather than settling for the easy answers and false certainty of a linear process, product calculus uses a mental model based on its namesake branch of mathematics to account for constant change.
Product Algebra
When I talk about algebra, I am focused on equations. Think about the equation 2x + 2 = 8. You can easily solve for x here because you’re looking for exactly one answer that fulfills the problem.
You can show the answer, and you can easily tell people how you got it. This entire process is a straight line. So, when I talk about product algebra, what I’m talking about is that straight line.
Product algebra boils down to how we, as product managers, can get straight answers to people. Now, if you’ve done product management, you automatically know that idea sounds weird because most of our work has nothing to do with straight answers.
How often do you get a chance to give someone a straight answer in your role as a product manager? Product management is contextual, which is why straight answers are hard to give with regard to how to do product, or even how to operate as a product manager. The ground is always moving underneath the PdM.
If you say you give straight answers all the time, then I’m going to guess that you aren’t actually doing product management. More likely, you’re doing product development delivery, helping things go from ideas to market. This is a serious role, but it’s more suited to project managers who have tools and processes that are designed to get teams aligned and ship products.
Product management isn’t here to help a team just ship software. In fact, sometimes, when a product manager is doing their job, no software gets shipped at all. Why? Product management’s main job is to heighten the decision fitness of an organization.
That doesn’t always mean shipping software. Your success shouldn’t be tied to how many lines of code flew out the door. Your job performance should be tied to how well your work empowers the organization to make smart decisions. This means helping to clarify strategy, which is always contextual.
Contextual factors include everything that can affect the work you’re doing. This might be the product itself, the customers and the marketplace, the internal environment of the company or even the politics of the U.S. as a whole. None of these factors are static. Anyone who has woken up to find alarms ringing thanks to a massive bug or a piece of legislation like General Data Protection Regulation can attest to how quickly things move in the world of product management.
This incredible pace of change means that strategy can’t be linear. You’re trying to synthesize all kinds of complex issues, and you’re trying to determine the probability that the next action is the best action. If all this were as simple as solving for x, then algebraic thinking would be fine. But again, if you can give straight answers, then you’ve probably found yourself doing delivery. I’d argue it’s not a great use of your time or talent as a PdM.
Product Calculus
So, if everything is contextual, how can we think about our work in mathematical terms?
If only there was a branch of math that focused on continuous change. Well, we’re in luck because there happens to be one devoted to just that: calculus.
Why is calculus relevant here? Well, since product management is primarily about improving the decision fitness of the folks involved in a product’s development, and all of those factors are constantly moving, then the job is a lot more like calculus than algebra.
Product managers are in the strategy business. Strategy isn’t about telling you where the puck is right now. It’s about telling you where it’s going.
The biggest mistake that product teams make when it comes to strategy is treating all the information they receive as if it’s static. That outlook leaves the decision fitness of the team dead in the water, and I’ll show you why.
Product Roadmaps and Product Management
When I see a team’s product roadmap, I can instantly tell if they’re stuck in algebra land.
Why talk about roadmaps here? For many folks outside of the discipline, the roadmap is where the rubber meets the road. It’s how people gauge the worth of a PdM since they’re often the most impactful document that they see come from the product manager. Look at any product management job description, and especially one written by a non-PdM, and “Make a roadmap” is often at the top of the list of tasks the PdM will be doing.
Most companies get roadmapping wrong, though, because they’re thinking about things in product algebra terms. Roadmaps are not themselves strategy. They are an output used to get folks aligned around the strategy. When a team isn’t careful, they can mistake the artifact, the roadmap, as the strategy itself.
When a team thinks this way, they can find themselves looking to solve an equation. That equation often looks like feature X + feature Y = market success. This almost never happens, though. More often than not, a company then goes back to the drawing board, just trying in vain to remake whatever the hot new startup is.
So it bears repeating: Roadmaps are not strategy. They are a communication tool designed to prepare a team to execute the strategy.
Let’s talk about two teams. One approaches their strategy with a product algebra lens, and another that practices product calculus.
Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.
The product leader, working with the product algebra lens, immediately thinks about the roadmap. They do a competitive analysis and look at feature requests from their most preferred customers. Soon, they have a roadmap, looking about a year in the future, ready to go.
They feel good about themselves, and leadership feels great about everything as well. After all, knowing where the market is going is a good thing, and they have some features that are ready to take the world by storm.
This is all well and good, except you can expect any and all of the following to happen:
Timelines Slipping: As a product person, you have more than likely seen timelines slip, oftentimes just by pure acts of God. All it takes is one bug, and that perfect map you’ve set up is out the window.
Backchanneling: As the timelines slip, teams often politicize decision making. Things are falling behind, so they need to rely on whoever they know “gets the job done.” As communication happens along multiple axes, more than one version of the truth begins to emerge. There’s the roadmap and the “roadmap.” Different teams make different decisions based on whether they’re in the in-group or whether they’re following the company messaging. When this happens, one thing is for sure: It will end up as a big mess.
Customers Changing: While this is happening in the background, your customers are continuing to ask for things. Sure, the customer had ideas about what they wanted three months ago, but I mean, that was three months ago, right? How long are they going to wait?
As these problems unfold, the team is still diligently working through the roadmap that the leader put together at the beginning of the year. The problem is that the product algebra mindset is linearly focused, looking to solve equations and get a single output. Nobody in this model has the capacity to handle changes to the plan.
Why do teams do things this way? Despite the obvious problems, algebraic thinking has one benefit: It provides false certainty. Making something, anything, fit an equation is so much easier than worrying about the rate of change.
Roadmaps are fragile communication documents that unfortunately often take on the characteristics of doctrine. The mistakes outlined above are only going to compound. Remember, context is always shifting. Some people will cling to the roadmap, given its doctrinal qualities, and others will ignore it altogether. Nobody will be aligned, nobody will have any way to adapt to changes, and things will only get worse as the context continues to evolve.
You can see how these issues really start affecting the long term health of your product team.
Let’s take a look at how the other team deals with the same circumstances.
Calculus Thrives on Change
Leadership gives the product team the following direction: They need to satisfy the market, improve customer relations and make investors happy.
This product leader sees the roadmap as a communication tool for the strategy. It’s a means to an end. Knowing that the ground is constantly shifting, that leader makes a strategy based on bets that are focused on outcomes.
These bets should have a few components. They need a question or a problem we’re trying to solve to give teams a place to start. That leader also makes some decisions that can help guide the team by laying out priorities. For example, the team might prefer quality over speed. There should also be a confidence level of completion to help teams gauge risk.
Following the instructions given by leadership, a product calculus roadmap could look like this:
The market is trending towards AI, and so let’s bet on automation. This bet means that question X (based on the situation) should have our focus due to problem A. We prioritize failure over building product this quarter. Due to our circumstances, we foresee this as an investment and have 35 percent confidence that we’ll end the quarter with a prototype.
Customer relations are disconnected, so let’s increase our investment in them. We’re looking to answer question Y, due to problem B. We prioritize building deep relationships with our current customers over generating new ones. Due to our circumstances, we have a great relationship with our customers and have 95 percent confidence that we’ll end the quarter with a prototype.
Investors are pushing us toward an IPO, and so let’s decrease our offering based on question Z, due to problem C. We will prioritize quality. We have 50 percent confidence that we will stay on track to IPO.
Why are these things important? In each bet, we’ve given those that read our strategy an understanding of our motives. The roadmap that follows can lead directly back to these bets and has the freedom to change when necessary. When teams look at the bets, they can make better decisions and move the product forward through shorter feedback loops that use those bets to get aligned.
For example, instead of just going through a sprint with goal to build a feature, as we would when doing product algebra, you can now check your work and metrics against those bets during your planning meetings instead of just trying to follow a timeline.
What does this approach do over the course of a year?
There is no timeline slippage since you aren’t making promises to the market. You’re only looking to solve problems. From those solutions, you’ve made the promise to look toward outcomes.
Teams are free from a timeline based on a magic feature. They can now decide to take on the problem on their own, eliminating the need to toggle between the roadmap and the “roadmap.” That ends any need for backchanneling since they own the bet. They can look for problems to solve and move forward at their own pace.
What if the customers request changes? Well, which bet do they fit under? If they aren’t critical or tied to the strategy by falling into one of those categories, feel free to ignore them for now. They aren’t important yet.
Since you are operating as if the ground is shifting and living inside of the ambiguity of reality, you can simply consider how fast it’s shifting and act based on that information.
Product calculus deals with that shifting ground by saying: “Hey, we don’t know exactly where we are, but we do know things will keep changing. Let’s adjust accordingly.”
There are plenty of concepts beyond just the roadmap that product owns to which you can apply this framework. If I had to leave you with something, though, it’s that being a product manager isn’t straightforward.
The best thing we can do is improve our decision fitness and use that to communicate clearly. That’s why a calculus mindset is so vital: It primes you to thrive in the real world where context is constantly shifting. When you’re doing product calculus, you’re less likely to be blindsided by anything because you’re always anticipating changes.
There’s a difference between privacy, which is based on trust, and secrecy, which isn’t. To maximize your team’s potential, you need to foster privacy and eschew secrecy.
Our mental spaces are fascinating. Sometimes, we may keep certain information to ourselves because we know that we’re trusted to complete a task. We don’t need to involve anyone else in our work. Other times, we may hold things back because we know that we aren’t trusted at all. Silence is a self-preservation strategy.
In both cases, though we did the exact same thing, the meaning was completely different because of the wider culture we were in.
This schism reflects the difference between privacy, which is based on trust, and secrecy, which isn’t. As a leader in whatever space you’re in, you need to understand whether you have created a privacy- or secrecy-based culture in order to understand the communication patterns inside of your organization.
Your communication culture has a huge impact on the rest of your business. Cultivating an atmosphere of trust is essential for success. The level of trust people in your organization place in leaders and one another affects productivity, the health of teammates and long-term employee retention.
You need to understand the difference between privacy and secrecy so that you’re not letting the latter shape your company’s culture. In fact, you may accidentally be pushing folks toward a secrecy-based communication pattern now. Fortunately, several tools exist for fixing this situation and getting your team feeling comfortable again.
Free Toolkit: Employee Retention Rate Calculator
Use our template to seamlessly calculate your own employee retention rate.
The differences between a privacy-based culture and a secrecy-based culture go deeper than the surface. Company culture affects everything it touches. To get a sense of how this works in practice, let’s look at a hypothetical product development team making a feature and how it might work in each culture to highlight the differences.
PRIVACY-BASED PRODUCT DEVELOPMENT
The cross-functional team confirms the plan for tackling their goals in the next quarter. They then set up a meeting cadence to check in, and they make clear communication rules in a public channel so the rest of the team can keep up with each other when there are questions. Backchanneling is nonexistent, and there aren’t many questions because micromanagement is at a minimum. The group identifies problems as they come up, brings them to the attention of everyone on the team and discusses them publicly.
SECRECY-BASED PRODUCT DEVELOPMENT
The cross-functional team confirms the plan for tackling their goals in the next quarter. The design team doesn’t trust the engineering team, so they don’t mention that they have a secret project to build a design system that will cut into the larger project. Engineering keeps their refactoring secret from product because they are tired of being “bothered.” Meetings are on the calendar to check in, but no one takes them seriously because all real communication goes through backchannels, and anything public, including the meetings, is just theater. Teams may identify problems, but they aren’t dealt with because no one believes they’re actually going to be solved. As a result, work slows down and management starts micromanaging to solve the issues. The micromanagement makes teams retreat more.
Unfortunately, from what I’ve seen, the latter scenario is closer to reality for a lot of teams. Let’s see some things that may lead to this kind of culture.
What Pushes Secrecy Culture?
Although many factors contribute to a secrecy culture, they all boil down to a lack of trust.
If I don’t believe that other members of my culture have my best interests at heart, I may decide to keep as many secrets as possible to prevent information from being leveraged against me. As human beings, our first instinct is to survive. This strategy makes sense as it’s kept our bloodlines around long enough to get to the present day.
Many of the behaviors in the secrecy-based example lead to a lack of trust. Let’s grab the two that I highlighted: backchanneling and micromanagement.
Backchanneling occurs when one person talks to someone else privately about strategy or execution.What makes backchanneling so insidious is that it starts off innocently. I think I’m just open a Slack DM between me and someone else to talk about something small. Unfortunately, it rarely stays that way. Soon that chat goes from a quick question to talking about the project, which then turns into making plans that exclude other people. Small things that you think no one notices can’t be kept under wraps for long though. People sense when they’re being left out, and, soon, folks get territorial.
Micromanagement involves someone in leadership looking to stay on top of everything someone is doing, no matter how minute. Micromanagement starts as a leader trying to help. Suddenly, what was once an attempt to pitch in undermines people and kills their confidence. Their productivity may experience a short boost before bottoming out. Other people close to those being micromanaged will also lose confidence because they worry that the manager is coming for them next.
Both backchanneling and micromanaging are easy to identify. When there are different answers to the same question, that’s the result of backchanneling. When you see clones instead of people, it’s a sign of micromanagement. The good news is that once you see these trends emerging in your team, there are some concrete steps you can take to roll them back.
Moving From Secrecy to Privacy
If you identify some of these behaviors in yourself or your team, don’t fall into the trap of saying, “We’re stopping this today!” If the culture is already damaged, you have a high probability of making things worse. Your decisive action will cause everyone to fall back into the same old habits. People will see the new plan as micromanagement and find their cliques to discuss what they think is really going on. Instead of taking drastic action, then, it’s worth taking time to do an investigation. Here are two tools to do just that.
RETROSPECTIVES
A retrospective is a way for a team to publicly talk about the issues that they’re facing. Teams are probably already aware of project retrospectives, but the useful type here is the variant called team retrospectives. These meetings are designed to give the team’s operational dynamics a postmortem. The first time you run one of these, you’ll notice surface problems, like teams having issues with each other, pop up. If you can, solve the simpler problems by making sure the right people talk to each other. Many issues can be handled with a conversation and a simple output, like “Next time we’ll talk with each other before we start work.” It’s important that once you get these things in motion, you ensure that the stuff you’ve discussed is actually happening. Follow-up is important for building trust. Eventually, you’ll see people bring up the deep-seated things that are making your culture secretive, and you’ll have a path to making it better.
ONE-ON-ONES
One-on-ones are a tool to help managers understand their teams by talking to the individual members privately. Both the manager and team members should use this time to talk about what’s going on in the company at large and how that person can improve in terms of individual contribution. Remember, managers micromanage because they think exercising complete control over everything and everyone works. We know that it doesn’t; good managers trust their teams to get things done and ask questions of team members to understand motivations. Being in a place where you can talk directly and frankly builds trust and helps to make things better.
Neither of these methods works overnight. What they will do, over time, is build stronger connections between management and the teams/team members themselves. As a leader, you’ll be able to see problems and get to the root of them. Remember, if your culture isn’t trustworthy, fixing it will take time.
Give People Privacy
As a manager, you must create an environment where people can feel like they own their privacy.
Tools like retrospectives and one-on-ones will go a long way toward building trust throughout the company. Getting away from backchannels and micromanagement will get you closer to an environment in which people feel confident and will handle any problems as a team.
Feeling better about where we work often leads to productivity gains and a better bottom line. Take advantage of that by starting with these tools today.
What if there were a way to figure out the problems that a project would encounter before you started work on it? With a premortem, you can do just that.
If there is one constant we can count on, it’s that mistakes will happen.
When we start a new project, though, that can be the furthest thing from our minds. We often approach a new challenge with a sense of optimism. Of course, we need to bring enthusiasm to our work. The downside is that we are then opening ourselves to being blindsided by problems we could have foreseen.
Over time, this can become a major problem. In the CI/CD world we live in, it’s never a question ofifwe’ll have new projects, but how many. As product managers, we own the decision fitness of a company, and the organizational debt that comes from those blindsidings adds up, ultimately affecting the company’s ability to reach its vision.
This responsibility becomes clearer when considering the questions that we tend to get and also the ones we ask ourselves. Often, these questions boil down to some version of “How do we know this will work?” We get so many variations of this question that a lot of PdM tooling is just figuring out how we can answer that one query in all its versions. Retrospectives are designed to help answer that question for past projects, but how can we ask it of future endeavors?
This question keeps product coaches and executives up at night, partially because there is no solution. If you knew the future, you wouldn’t need to be a product manager because you ought to just play roulette all day. For those of us without clairvoyance, though, the best we can do is minimize our risks and raise potential problems as soon as possible. After all, we know mistakes are unavoidable.
So, how do you do that?
Let me introduce the concept of the “premortem,” which is a workshop that can help identify problems before they happen. One of the outputs of organizational debt is fear, and this workshop helps shine a light on that fear so that teams can find alignment. I know this sounds a little scary, but as we walk through a premortem definition, how it creates an accurate map of an organization’s incentives, and how you can infuse it into your processes, you’ll see how you can use that fear to find holes in your own team’s alignment.
What Is a Premortem?
A premortem is a workshop that allows participants to give voice to their fears about potential sources of failure on a given project. It differs from its more well-known sibling, the postmortem, in that you do this before the project begins. The facilitator of the project asks the team to work backward from a hypothetical potential failure to understand how it happened and which behaviors you can avoid or adopt to dodge catastrophe.
What does bringing up problems before a project do for your team? It gets to a fundamental truth of organized structures: We often deal with the same issues over and over again. Bringing that fact up and making organizational fears and assumptions transparent to those around us is a great way to start to address the problem and end its grip on a team.
A premortem requires a facilitator, a note taker and representatives of the different teams that have some responsibility for the project’s success. The facilitator should ask and do all the following:
Based on a standard time horizon for a project in your organization, ask the group to brainstorm about some realistic ways this project could fail.
The facilitator should bundle these concepts together based on topic. In facilitator speak, this is called “affinitizing.”
The team can then prioritize the problems, first by talking about the groups, and then by voting on which topics are most important to the business.
Then the facilitator should ask the group to brainstorm again about how to avoid these potholes.
This process, which should take 60 to 90 minutes, will help teams clearly identify fears that they face that may currently be lurking under the surface. The meeting will help the teams to give voice to their anxieties and get everyone on the same page by specifically discussing the issues each group faces.
Why Is a Premortem Important?
So, let’s talk about potential failure, which is the foundation for this exercise. What if I asked you, “How will this imaginary project fail?” You might have trouble coming up with anything. In fact, it may seem very strange that anyone would even ask this question.
In practice, though, you’ll find that coming up with answers isn’t so hard. Let’s shift away from this article and imagine that you, as the product manager, are in a room with your team. You think about the last time a project failed and why. During this session, you recall that two teams didn’t interact well, which hampered the project.
In fact, you aren’t the only one who thinks this. Other people on your team do so as well. The facilitator asks, “What are some realistic ways this project could fail?” You all have plenty of things to say.
Next, you’ll work through why these things happened. As the team expands on the important failures, you’ll gather far more information on what happens when teams interact. The conversation will generate a great deal of insight into possible problems.
Finally, you’ll jump into solution mode and talk about what actions you can take to mitigate the risks you have mapped out. This is process improvement at its best, as you’ll be working with real problems and solutions tied to the fears of the team, based on the themes you’ve seen earlier.
Premortems Map Out an Organization’s Incentives
The process in the middle of the workshop, where we affinitize and come to an understanding of what the problems are, has a few components to it that will help you become a better product manager.
What makes the understanding section so powerful is that the person speaking will often share stories in which perceived slights took place. The stories you hear through the premortem will help you understand what fears folks in the organization are facing, both implicit and explicit. Sometimes, you’ll be lucky enough to hear the team articulate their fears in a fully formed way.
It’s a shortcut to understanding the politics of an organization. Politics aren’t quantifiable, so the information isn’t going to be as straightforward as a hard, quantified number. The qualitative anecdotes you hear, however, will help you identify how your organization works.
If you don’t understand the politics of the organization, you’ll soon wonder why various teams are apprehensive about certain tasks they’re given. This is where having a map, developed through a premortem, helps you to navigate problems.
Dealing With the Responses
You’ll notice two types of responses from the teams you speak with. They may talk about themselves, which we can call an internal assignment (i.e., self-awareness). Other times, they may talk about other teams, which we can call external assignment (i.e., blame). You should gauge the seriousness of each response by comparing them to the values of the company and asking the respondents to rank their importance on a scale of one to 10. Doing so will help you determine a course of action. Both internal and external assignments are worth investigating further.
Let’s look at a hypothetical example. Imagine that you’re talking with your marketing department as part of a premortem. You might get something like: “We got thrashed because our Q3 launch didn’t go well. We were just swamped.” This response would qualify as an internal assignment. It’s also pretty tame since it seems like a one-off issue.
Alternatively, sometimes the responses are very clear external assignments: “Our last release gave us way too many bugs because QA didn’t catch them, and they ruined it.” This is an external assignment and an alarm at that since the blame is absolute, especially if they use dramatic language like “ruined.”
As a product manager, this is where we put our detective hats on and hit the pavement, looking for the reasons why the incident happened. You are looking for sharp critique, blame, or the other failures teams talk about. Sometimes, you can find them in the postmortems of other projects or in written documentation in places like Confluence or notes buried in your company’s Google Drive. Try this with internal assignments.
Other times, the answers will be with the people in the org themselves, and it’s worth scheduling an informal follow-up chat to get more details. Conference rooms can work for something like this, but more often than not, getting some coffee or lunch will work even better. You want this conversation to be as casual as possible so that no one feels as if they’re under attack for placing blame. Remember, this is a fact-finding mission, not a blame game. This approach is particularly useful for external assignments since talking can clear up misunderstandings.
As a product person, it’s important to build relationships across the organization to find out where resources are and also identify hot button issues between teams. Premortems can help you accomplish this.
Making Premortems Real
Not all companies are created equal, and so you need to understand what ties the company together. This is where company culture and values come into play.
These concepts that you often see on the walls and on the website’s “About” page are the key to getting a premortem to happen within teams. Oftentimes, the values you see are at least implicitly agreed on, and since they are, you have the opportunity to use those principles as a shared framework to bridge the gap between groups. They are the lighthouse that can lead your team to safe harbor.
As you put the workshop together, make sure you refer to these values in the description. Do so both in writing as you send out communications and also when you get the team in the room. Since everyone agrees with these principles, at least in theory, people will be far more comfortable with the meeting. They should begin to see it less as a sniping session to get their political enemies and more as a way to get everyone on the same page.
Having a clear code of conduct helps to let people know that there are rules in place to maintain respect between people and teams. Everyone is looking to improve, so it matters how we talk to each other. Snark, sniping and backbiting are all counterproductive. Make sure that whoever facilitates lays out the ground rules and enforces tact in the conversation. Finally, this type of workshop requires clear communication and context. If you can’t get in a room together, video actually matters here.
Face Your Fears With a Premortem
Our first calls are almost never right. Same with our perspectives on the teams we are working with. The more alignment we have in the organization, and the higher our trust is inside of our teams, the better we are. We’ll need to have a map of where we are to be effective.
Premortems are a great tool to make that happen. By exploring the past before we engage with the present, we give ourselves a chance at a better future.
I’m going to share a harsh truth here. No, you don’t.
You need an architect, a project manager, or any number of jobs that directly speak to the problem you are facing. Your issue is that you haven’t defined that problem, and are more than likely listening to outside voices that “think” they know what product management is.
In my 13 years in tech, which I’ve spent building startups, consulting, and growing product teams, I’ve never, ever seen the use of a technical PM. My hope after you read this is that you’ll understand why, and as you build your product teams, avoid the trap this represents.
So, let’s start there — what does a technical PM represent?
“You know what we need? A technical PM.”
This is a prime example of what I like to call “conference babble:” listening to talks and workshops at a conference and mixing them all together with prior experience to create the world you want. “Technical PM” as a job description is conference babble of the highest order.
As product has taken another leap forward in consciousness as a discipline, plenty of folks have taken the stage and talked about their trials and tribulations. It’s part of the process. As product people, we are working out the nuances of what we do.
Experienced folks understand the nuance, while non-experienced folks may end up in conference babble land. And that is where the rise of “technical PMs” comes from. Why not take advantage of this increased nuance with “technical” skills, and we’ll have some kind of super engineer. Right?
Who doesn’t need that? With that thought in tow, folks come back and start typing job descriptions. “We’ll have a little bit of this, and a little bit of that, and they will be able to fill all these gaps. We’re unsure what we are asking for here, so let’s ask for everything.”
Another unfortunate second-order effect of product talking about what they have been able to accomplish is people getting the wrong idea of what product managers do.
In the eyes of some, they’ve become magic wands. If I wave a PM in that direction, then everything is fixed. They can “CEO” that function. So, why not throw “CTOing” that function in there as well?
That reminds me of what famed business author Seth Godin often speaks about, and what I’m calling the Cheesecake Factory dilemma.
Cheesecake Factory has a menu as thick as your doorknob. The food is mediocre because they cook everything — there is no focus or specialty.
There are no two ways about it; engineering and product are different disciplines. Both take years of experience to do well. By asking for someone to do both, it starts them down the path to mediocrity.
“Alright, we’ve found our technical PM. Now they can go solve the problem.”
Another tough truth: no, they can’t.
Let me hit the fast forward button on this since I’ve seen it a lot while consulting. Your engineering and product teams will have a cold war over this person. As a result, one of two things will probably happen.
They will turn into a project manager/architect by proxy with nagging commitments
They end up doing “PM” work anyway, title be damned.
No one hires senior technical PMs. There are no directors of technical product. This battle will play itself out, and that third-order culture effect could be devastating. If you are a person with hiring authority, part of your job is to minimize any cold war that can happen in an organization. Internal stressors are a company’s silent killer.
So let’s hit the rewind button.
“What is our problem?”
Hiring is a puzzle, no different from finding product-market fit, alpha, a bug, or whatever paradigm you subscribe to.
Eating at the Cheesecake Factory may mean you leave full, but the culinary experience won’t blow you away. Ask yourself: what are you really looking for?
If it’s someone to get projects running on time, go get a project manager. If it’s someone who understands the innards of a technical system, an architect will do well (plus, they are super technical).
Ask yourself what this person is for. Remember that being sincere about what you need can help your business grow.
“Wait, how will I know this what I need?”
Talk. Ask more questions.
Bring in outside counsel if you have to. There are plenty of product coaches that will help you settle what problem you are trying to solve and how doing so will improve your business.
The wrong hire won’t solve your problems — they will just exacerbate them. Worst-case scenario, you are starting a cold war between your product development teams that will slow down rather than speed up progress.
As product management becomes more popular as a discipline, the more trends — hiring and otherwise — will come and go. Remember that you don’t have to follow every one of them. Stay true to your organization’s needs and your product’s differentiators and you’ll avoid the “shiny new object” pitfall.
Too many times I’ve heard this: “I know what the customer wants.”
Immediately, my brow furrows a bit, as I press for more answers. Usually, at this point, I ask, “How do you know?”
What happens next tells you a good deal about the maturity of the product development practice you’re dealing with. Unfortunately, for most folks, the answer here is the wrong one.
In my 13 years in technology, I’ve heard the wrong answer over and over again. It’s usually some form of “We just know.” You can translate that answer into the truth, which is that the team has an ego problem.
When teams tell me this, I often imagine a tape playing in their heads that sounds something like this: “That’s why I was hired/founded the company. I’m here because I know what the customer wants. Why else would I be here as a [insert role here]? I’m here because I have a good feel for what the customer wants.”
Sorry to break it to you — whatever you do, that isn’t what you’re here for. You’re not an intuition machine with infallible judgment. The goal of any company is to use the tools and people it has to make great products that drive profits. That’s how you win customers, and it’s how you’ll keep them.
Unfortunately, plenty of teams don’t take this tack. They believe everyone is there because of what they, and they alone, innately know. This attitude is extremely limiting to the work we need to do as product managers.
I firmly believe that one cannot think and know at the same time. Once you’ve decided you know something, you’re shutting yourself off to engaging with the topic further. When it comes to product development, though, there is no way to truly know things. Not even a team doing all the research it could possibly do knows the right answer. It doesn’t exist. When you say “I know,” you’re just closing the door on a whole host of possibilities.
There are just too many options and complexities for a right answer to exist. Think of product management like calculus: There are many possible answers, not just one. If you’re focused on knowing a so-called right answer, you aren’t doing any type of user-centered development.
Instead, you’re engaging in ego-driven development. This leads teams to waste a lot of time building things the customer doesn’t need, leaving the customer unsatisfied and the company with a bunch of undue overhead from products they don’t need to carry. Worse, you’re hampering your team’s ability to do great work. The best product development teams focus on learning. If you aren’t thinking about the customer, then you’re robbing your team from doing just that.
Well, like all things, the road to hell is paved with good intentions. Here, the problem begins with taste. Taste is your innate sense about whether or not something works. The one thing about product management that you can’t teach is taste.
Before we go any further, I think it’s worth taking a moment to say that taste is what got you into whatever you’re doing. It’s an important piece of the puzzle. As a beginner, it’s all you have. As you gather more experience, you begin to close the gap between your taste and your ability to create new things. Ira Glass makes a good point on this subject.
Your current job, your next job and your ultimate legacy in this business are all built on that taste. It’s the thing that makes things happen. And that’s good. You need to have taste!
So, clearly, taste is important. When it goes too far, though, you start to enter ego territory. We can’t afford to have our taste become a dictator. That’s when bias takes over and blinds us to better outcomes. When we do that, we’re not thinking about the user, but ourselves. That’s when we’re practicing ego-driven development.
Identifying Ego-Driven Development
So, now that we have a definition, how do you know when your team is operating from an ego-driven place?
In the introduction to this piece, I highlighted the difference between thinking and knowing. That’s where teams go wrong. They move their discussions from “thinking about the customer” to “knowing the customer.”
This can manifest itself in different ways:
A lack of customer connection.
Building fast and learning slow.
Missing opportunities to reflect.
Let’s examine each of these issues and some ways to solve them.
A LACK OF CUSTOMER CONNECTION
When was the last time you talked to a customer?
I don’t mean talked at them to sell something, either; I mean to them. What are their hopes, dreams and the problems they’re facing? How does your customer intend to get closer to the hopes and dreams and away from the problems? Are they willing to invest? Are they ready to leave?
All of these questions are important to ask and give you guidance on how to think about the customer. When you talk to the customer regularly, you begin to mix your taste with an overall sense of their problems. That is where product development becomes powerful.
BUILDING FAST AND LEARNING SLOW
Is your team’s mindset always focused on pushing ahead to the next sprint?
Whoa, there! What was the last thing we learned about the customer who’s using this product of ours? In fact, did it solve their problem? Is this worth continuing? Are we missing something in the market? What about our competitors?
If you are just building, and not investigating, not only are you missing out on getting to know the space your product holds, but you’re also underinformed about the marketplace as a whole.
The marketplace is constantly changing. So, if you aren’t building on your knowledge every time, your team begins to rely on luck. This means you can’t consistently ship good projects. You might get lucky once or twice, but you’ll eventually strike out.
MISSING OPPORTUNITIES TO REFLECT
How are we working right now?
It’s vital that we look at what we are making, but it’s just as important to understand how we’re working together as a team. How is our team morale? Are we overworked? Are we bored? Are we stuck in a rut?
If you aren’t investigating yourself, how can you get better as a unit?
Your taste needs to get better too. If you can’t find alignment with the other people on your team, the distance between you, them, and the project grows, ultimately hampering your ability to ship good products.
Avoid Ego and Improve Your Products
Business is constantly evolving. Our customers are changing, and the problems around us are growing more complex. This requires getting out of our heads and paying attention. Ego-driven development isn’t going to help us keep up with the pace of change. Although an ego-driven process may make us feel better in the short term, it has disastrous long-term implications, up to and including kicking us out of the marketplace altogether.
That’s why it’s so important to check in on all of these factors. Doing so allows us to take our ego out of the equation and make good decisions.
Make things that matter. I can’t think of better work than that.
So, you’ve made the hire. Congratulations — finding the right product manager who can help your team succeed is a huge burden off your shoulders. As a member of the welcoming committee, you well know that onboarding is extremely important to the success of your new colleague.
A bad onboarding process is essentially running that brand-new hire you just made out the door — and a sizable number will leave before they can do anything they promised during the interview process. Onboarding new employees isn’t something that should be taken lightly.
Except that it is.
In fact, Gallup puts the percentage of companies doing poor onboarding at a whopping 88%. That means that you aren’t seeing things — yes, people are leaving jobs rapidly. And while much of that can be blamed on bad management, the specter of bad onboarding can be just as impactful.
Onboarding in product management
Those are generalizations about the overall workforce, and while I don’t have a ton of peer backed numbers, I can be fairly confident that the trends follow in the discipline of product management. My conversations with product leaders and founders tend to support that notion, as one of their struggles continues to be keeping great talent. They find that new hires don’t quite find their footing and seem to never reach full productivity. Those folks tend to start looking elsewhere.
All of that work to bring in someone for them to leave in a few quarters is devastating.
This article is going to address the difficulties that product managers face during the onboarding process. These challenges are based on the understanding that product managers are there to help facilitate product decision-making within an organization. This means that the first few months of a product manager’s tenure is more akin to being a “detective” than anything else.
How a company prepares a PM during the onboarding process can be the difference between a long-lasting team member and a flash-in-the-pan who sends you right back to the hiring boards.
The challenges are that product managers have to:
Figure out the company’s place in the market from scratch
Understand past decisions
Know what their areas of responsibilities are and what power they wield
Let’s go through each of these in turn. I’ll share a few things you can do to move your new hire along so they can be effective, plus some things to throw into the welcome pack to help them on their way.
Figure out the company’s place in the market from scratch
Your company doesn’t exist in a vacuum. Even if you are creating something on the edges, there is often an alternative that your customer base is currently using to solve their problem(s).
When a new product manager comes on board, it’s critical that they get this information as early as possible. This allows them to ask questions that can improve the current “map” of the company. After all, you hired them for a reason! When armed with accurate knowledge of the market, a product manager is more confident in the bets they make and less likely to run afoul of silent rules that exist in the marketplace.
Put these in the welcome pack: A list of current competitors, the rules of the market from leadership’s point of view, and your business strategy, along with all the artifacts that accompany it.
Understand past decisions
The company doesn’t exist in a vacuum, either externally or internally. The team or organization made a number of critical decisions in the past, and the company learned from them.
When your new product manager comes on board, they need to know what those decisions were, who made them, and what the company discovered. As they learn this, they get a picture of where they can add value based on their experience and what they don’t need to re-learn. This means they can use their energy effectively going forward. This also applies to the things people in leadership positions won’t do. There’s no need for the new hire to waste their efforts.
Put these in the welcome pack: The last six months of major decisions, an org chart, product mission/vision/strategy, and a list of anything that the company won’t do.
Know what their areas of responsibilities are and what power they wield
Building on the idea of “wasting energy,” it’s very easy to do so in a new organization, especially as a product manager. When you don’t know what you can do without getting the “ok,” it can be frustrating. It hints at dysfunction within leadership because when these things aren’t clear, people don’t act.
When your new product manager comes on board, they need to know what they can do. Can they just run a research study without an “OK?” Is it company policy for them to be able to hop on a plane to see customers without your sign-off? How about changing the roadmap? What about bringing in new software? If you are thrown off by these questions, I’ve got more, and they easily compound. Don’t waste your new hire’s time — let them know what they can do without asking permission.
Put these in the welcome pack: Rules on company spending/training spending/research spending, old research wins and losses, and anecdotes on when the company changed course.
Time is of the essence
You’ve made the hire. The person is coming in the door. They are smart and accomplished and are ready to help make the business better.
You trusted them enough with the offer, so help them out, and get them onboarded so they can get right to work, the right way.
Well, I think we should start by breaking down both terms. Full-stack, in the tech sense, describes someone who is a jack-of-all-trades, but (generally) a master of none. You usually see this term on engineering teams, where job descriptions ask for “full-stack” candidates by requiring skills that are critical for both front-end and back-end work. The expectation is that this individual can fit into any project and drive results.
Companies generally hire product managers (PMs) to foster and strength alignment between teams, and also to mitigate risk. When the product team is effective, they end up being a force multiplier for all of your resources. When they’re struggling, they become roadblocks to those teams that are creating value for the company. There are several types of PMs, and in this article, we’ll focus on the main three: the product-delivery-focused PM, the growth PM, and the strategist PM.
A full-stack PM would combine all three of these types to make the ultimate “full-stack” product manager. Let’s explore these three types and the skills that are most important to each.
The product-delivery-focused PM
This type of PM is responsible for delivery. They often work with engineers often and are judged by the value of the features they ship. When product delivery is going well, it helps teams move forward. But when it isn’t, the team gets stuck in red tape and loses focus on the value of the products the team is putting into market.
The product-delivery-focused PM needs to have solid project management skills to keep everything moving on schedule. They also need to be fairly comfortable with the internals of a product, since they are going to be partnered with the engineering team to understand technical debt and feature value. In most places, the “typical” PM is this type.
The growth PM
This type of PM is focused on the business. They work frequently with sales and business analysts and are evaluated by metrics like virality and nominal pricing. When a company is growing, the business is moving toward its goals and increasing its market share. When growth is stagnant or even decreasing, the team ends up trying to balance disparate objectives and KPIs lose their meaning.
The growth PM needs to be comfortable in sales, marketing, and pricing to keep growth moving up and to the right. In addition, they need to be comfortable with the sales process (whether it is B2B or B2C) because they will be making changes often. Andrew Chen is known as the originator of this position and has written a ton about it here.
The strategist PM
This type of PM is focused on the market. They work with designers and marketing teams and are judged by the alignment of the portfolio. Often, they are also trusted to handle new ideas. When this PM is doing his or her job well, the business is aware/protected from new players entering the market and has some idea of some adjacent markets to explore. When it isn’t, the team is caught off-guard.
The strategist PM needs to be a mix of marketer and UX’er and be ready and willing to spend a lot of time with customers and other stakeholders. In general, they end up being the connective tissue of your strategy, tying together intuition and metrics like retention to tell a story. Plenty of companies utilize them when they feel comfortable in a specific market.
So, how do you merge all three?
Alright, let’s be truthful. All of that sounds impossible because it is. The term full-stack is a symptom of teams trying to maximize “efficiency” when it comes to labor costs, without fixing the core issues of the company. If you find the term “full-stack product manager” on a company’s careers page, you should run away, far and fast.
If your team puts a job description up, it’s worth asking a few questions, such as:
What problem does this hire solve for us?
How will they integrate with the company?
How will this hire position us for the future? What bet(s) are we making by bringing this person in?
If they cannot answer those questions, then your leadership team is fulfilling headcount just to do so. It might be time for you to save yourself and find a team that is clearer about what they’re looking for in a new PM hire.
If I asked you about your relationship with your customer success team, what would you say?
Whenever I ask product teams this question, I’m generally surprised by the answer: that there isn’t one. And if there is, it’s barely hanging on. Often, the relationship is very back and forth, with CS handing off customer problems — or even worse, solutions — to the product team. Then the product team places them either very high (bug or critical error) or low (enhancement) in the queue because they originated outside of the typical product development process.
This breeds resentment and the two teams rarely address it. The status quo remains unchanged and the opportunity for better alignment and communication is lost.
Does this sound familiar?
As a product executive and consultant with over ten years of experience, the customer success team is often the first team I talk to when trying to understand a business and its customer base. When the relationship between CS and product works well, important customer information, including qualitative feedback, feature requests, and emotional reactions to the roadmap, makes its way to the product team to inform their strategy.
Ultimately, a strong relationship with your colleagues in CS will give you a much higher success rate when launching products. And all of this for free.
How do you build such an alliance? Well, I put the onus on us, the product team, to manage the relationship and bring out the best in the teams around us. Product isn’t just a translation service — it also is a diplomatic one.
Here are three ways you can repair and improve that relationship with your customer success team:
Hear them out
Bring them into the research process
Be transparent
Hear them out
Typically, your customer success team is going to be the lowest paid and the least listened-to team in the building. Their job is often a taxing one — customers frequently yell at them, and they work on the front lines of frustration, listening to customers vent at their lowest moments of using the product.
Your job as a product leader is to take the opportunity to sit down with them and listen to what they have to say. If the relationship I described before sounds familiar, they will likely have a lot to say.
How should you frame this conversation? I’m a big fan of the team retro process laid out by NOBL here. A team retro gives you and that team at least 60 minutes to get things completely on the table. Remember, the retro process isn’t about blame; it’s about level-setting and improving, so make sure you use that time to get a clear lay of the land. Both teams more than likely have some misconceptions about the work the other does. It’s finally time to clear them up.
Bring them into the research/product development process
I think the biggest distinction that the product team should communicate with the CS team is that they have a good understanding of the emotional state of reactive customers, but aren’t always clear about the problem set of proactive customers. That is the difference between research and inbound. Making that distinction clear with your customer success team is the start of engaging them with the product development side of the house, instead of “break/fix.”
Something as simple as inviting your customer success team to the research outlines and asking them about common customer frustrations can give you a world of information — not just about what the customer wants, but opportunities to get help, even in the way they process inbound.
Also, make sure each product team has a customer success advocate on board. They don’t have to go to every meeting or engage in every conversation, but it helps keep the team involved and may lead to useful insights when the build begins.
Be transparent
You’ve already built some serious inroads if you’ve been doing the above two methods regularly. The next step is to be transparent. This involves a potentially big change in your product strategy: inviting the customer success team in to talk about it.
New hires coming in to shake things up? Let the customer success team know. Doing some sort of tech debt initiative and new features are temporarily suspended? Bring them on board. Keeping the customer success team aware of all the big movements from your perspective will build trust and help mend any damaged fences.
Remember to continue to do the retro as well. Once isn’t good enough — make it a regular occurrence to encourage consistent engagement and communication.
Customer success and product can work well together
Our customer success teams are on the front lines keeping things running smoothly every day. We have an opportunity to use that expertise to make better decisions about the products we bring to market, and how our product development serves customers. The way we get there is by making sure that we stay open, bring them along, and continue to build trust through transparency.
Building the right products is a team effort, and when we all work together, great things happen.
As a former director of strategy for the incubator Cofound Harlem and a product strategist for the agency Philosophie, I’ve had the experience of keeping track of the strategy of various types of companies.
I’ve had to understand their past, present and future.
And in my last role, as the director of product for Informed, I moved from advising companies to building our own process. I had to ensure we execute whatever strategy the leadership and I come up with.
It isn’t enough for me to execute; the team has to, as well. As much as I can work on controlling myself, at the director level, it stops being about me. It’s about the folks I have the pleasure of leading.
You need a process to cover the gaps of your team’s capabilities, so you can make company strategy exist on more than Google Docs.
How can you do that?
This article gives you two tools to ensure you are moving forward with your team and growing a long-term strategy — not just standing still.
Let’s start with a mental model; I think Lean works well here.
Lean methodology
Lean methodology is a mental model that uses the term “Build-Measure-Learn” to create a feedback loop.
Although it is generally used for product development, I’ve found it useful as a starting point for building processes in tech companies.
Why? Lean is a known quantity in many product teams, and it’s always easier to build on a foundation that exists. There is one part of the methodology on which teams under-index. Read on.
Now we have a mental model. What’s next?
Life in product management is about priority, so let’s pick what we want to prioritize. It is my experience that there is one of the three parts of the feedback loop you need to focus on to help build a team that is better at executing on strategy in the long term.
That is learning, which is under-indexed at most companies. That is a shame.
The strategy isn’t just about the next sprint. I believe a good strategy helps grow the team, as they try to hit the goal. That is why tools, such as OKRs, when properly done, force your team to stretch.
Executing strategy well makes your team better, and over-indexing on learning will leave your team better than when you arrived.
My experience in dealing with other companies has led me to see what happens if you “Lean” too hard on the first two words of the phrase in working with teams to execute. You’ll miss the boat. Here is why:
Building teams constantly execute
Build-Measure-Learn
Execution is excellent, except when you find yourself six months into a vision with nothing to show for it.
Let’s make it real with a marketing example:
A visible sign this is happening is in New York City subways. Nothing says a fresh round of funding like a subway ad campaign that just “exists.”
You know what I mean when you see them. The ads have some quirky saying, whisked from the mind of a newly minted top-15 MBA ready to show the world how smart they are.
This approach could work if you’re Coca-Cola, as you already have trust and influence. If you are Series-A Whatchamacallit, who cares, other than the team, when they get on the subway? I’ve been inside companies like this, and what happens is: They are given a strategy, and they are cranking things out.
Here is a quick way of finding out if you are in this situation with your strategy: Ask yourself if you’ve ever just stopped.
The remedy? Retro (retrospective) now and forever. You need to see if what you are doing is working, because my bet here is: The customer never gets a chance to make a promise, because your team is building too much to give them a chance.
That means you miss the boat.
Measure-focused organizations may be worse
Build-Measure-Learn
Instead of working on things, they are making sure they get the right KPIs. This comes in the form of triple checking and quadruple checking. In organizations, this looks like another focus group, another listening session or yet another internal iteration.
No one executes on anything, because they are worried about covering their asses (CYA). CYA tells me you aren’t there yet. CYA tells me you will measure forever. CYA means you won’t put work out in the world when it needs the feedback it deserves.
Our work doesn’t count until someone who isn’t paid by the organization can see it in the wild. We don’t know how this thing works, because we haven’t given it a shot.
Ask yourself this: When is the last time we launched?
The remedy? MVPs. We’re hitting the go button on X date. We are putting something out in the next 2 weeks. We’re getting data.
Your team never made a promise to the customer, because you are too scared to give them a chance.
You can’t go on a journey if you never get off the dock.
What about learning-focused organizations?
Build-Measure-Learn
It is my opinion that, if you are focused on learning, the rest handles itself. Learning-focused organizations never seem to have the need to call in help. Learning-focused organizations focus on two things: reflection and iteration.
Reflection: Ask yourself this question: Have you had a retrospective lately? Also known as “retro,” this gives you the place to pause and reflect on what has happened and how you plan to avoid it next time. It’s a balancing act. Great retros, when running well, have the participants ready to move forward while feeling their grievances have been addressed.
Iteration: What is the next step? Iteration is all about getting to the next step and executing it. How do we take what we’ve built and measured, take its flaws (hello retro), and build it into the next step? Iterating while executing makes sure your team gets aligned with the strategy.
Promises made lead to learning
There is a push-pull with building and measuring that leads to learning. The right metrics and getting product out are both critical, but unless we sit down to discuss what we’ve learned, and how far away it is from where we need to go, we’re not maximizing our teams.
Ask yourself: When is the last time you “learned” anything with your team, and when was the last time you took that learning and put it into the product?
If you can’t come up with an answer, it’s time to get back to the basics. You are building too much or measuring too much, and my guess is the strategy is bad.
What happens isn’t about measuring 10 times before you cut or cutting 10 times before you measure. It’s about executing the long-term strategy, so you can make things happen.
Lean on learning, and adapt the other two for a better process, and execute a better strategy today.
![[Lean] Building an internal growth process for your teams](https://images.unsplash.com/photo-1536392706976-e486e2ba97af?ixid=M3wzOTM3OTV8MHwxfGFsbHx8fHx8fHx8fDE2OTc4NjUwNDJ8&ixlib=rb-4.0.3&fm=jpg&q=85&fit=crop&w=2560&h=1707)
