What can you not control? Getting this down is important because you need to budget time to deal with it.
What keeps the lights on? There are rituals that helps your team play at their best.
When can we think? Being better doesn’t happen through osmosis, we have to reflect.
These set the pace just as much, if not more, than “goals.”
Do you know?
What about the people you work with?
What are the answers they would give if you asked “what is the outcome our work seeks to make?”
Worth asking from time to time, because I am going to bet you will be shocked at the answers.
Clarity is a lot of work BEFORE you have it.
There are all sorts of inputs that will create a map for others to follow.
Clarity work is a lot simpler once you have it.
You just have to:
Tell them what you are going to tell them
Tell them
Tell them what you told them
Over and over again.
This is simple, but not at all easy.
If you craft the perfect solution in the wrong direction, it means nothing.
If you craft the wrong solution in the perfect direction, you’ve got data.
You don’t have to “choose wisely” here, the choice is clear.
A quick heuristic.
Direction is messy, confusing, harsh, and most importantly (or because of that) is built on trust. If you are reacting – you aren’t setting direction.
COVID won.
That’s it. Whatever response we pulled together didn’t work.
It isn’t over.
We didn’t get through anything.
We’re still here.
Now that the books are starting to come out about what happened in March 2020, I think its critical we are honest about it.
I don’t believe anyone who says otherwise. Not with a straight face.
We’re still here.
We often don’t know what we want until we say what we want.
This is why tasks like journaling are important. We say what is top of mind, pulling what may be churning in our subconscious to the surface. Through this exercise, we get an opportunity to start to build criteria in which we can benchmark the work we do.
From there, it is a lot easier to say what success looks like.
Why is this important?
Well, unless you verbalize it, there is often a vision of success that we default to.
Sometimes, that is good enough, but it rarely ever is.
I see this in product management all the time – most teams will say they are agile however, they view success as delivery unconsciously.
This definition has all types of effects upstream. It’s as if the teams think they are going to Disney World in Florida yet are driving towards Wrigley Field in Chicago.
Both are good places, but not if you think you are going towards the other.
Hiring is one of the most important parts of product leadership. Use these principles to make sure you’re landing the best talent.
Product leadership is difficult.
That difficulty comes because it’s often very different from product management. As a product manager (PdM), your focus is squarely on making sure that your team is consistently making the best decisions they can.
When it comes to product management, you can easily access help to upskill yourself. Plenty of resources describe how you can do this more effectively. I’ve written a few myself. Some great voices in the space, such as Matt LeMay, Teresa Torres, and John Cutler, among others, lay out frameworks that help PdMs figure out how to increase the decision quality of their teams.
But what about product leadership? Well, product leaders’ job is to build product teams, which involves less framework and more coaching. You aren’t the star anymore. Instead, you take teams and make sure that they are ready for primetime.
Accomplishing this requires a completely different skill set from strict product management. You start to assume responsibilities that take you outside of a tracker or prototype and have you spending far more time focusing on the people themselves.
This work includes bringing people onto the team that you’re developing. One skill that product leaders must cultivate is learning to hire effectively. If you aren’t adding the right skills to the team, no amount of work you do individually can fix things when they go askew.
The simple truth is that when you become a leader, you have too much to do, from team to resource management, to continue doing your old job. As an executive told me in a previous product leadership position, “You can’t do both.”
And you can’t. So, you’re now hiring new PdMs to do the work you used to do well. But how do you go about that?
MORE FROM ADAM THOMAS Why Projections Fail — and What to Do Instead
Have you ever heard the saying, “Just because you can do something doesn’t mean you can teach it”? Well, the same thing applies to hiring.
The skills necessary to hire someone who will be a good fit for the role aren’t as simple as one would think. You risk becoming a victim of expertise bias, where you end up looking for someone exactly like yourself. You also have to consider cultural bias, in which the hiring manager prioritizes candidates who look, talk, and think exactly like the other team members. Both of these biases lead to building a team that thinks and looks alike. In a discipline like product management, this can be a fatal error.
No tension on teams means no growth. Unless you get some measure of luck, your team will remain stagnant because no one challenges each other. After all, we’re here to increase the decision quality of the teams around us, and that can’t happen without the team coming together from different backgrounds and points of view.
The bad news, as a product leader, is that you likely won’t be trained on how to do this. The teams around you probably don’t know much about product manager, let alone hiring for it. Even if they did, they hired or promoted you to be a product leader to handle these things.
The good news is that I’m going to give you a quick tutorial on how to avoid some of these traps and push you in the right direction. First, we’ll talk about the importance of being clear about the problem you’re trying to solve with your hire. Next, we’ll use that information to formulate good interview questions. And finally, we’ll talk about being honest about the time you have. Getting all three of these things right drastically increases your chances of making the right hire.
Every team needs a certain headcount. Likewise, every team has a million problems they have to handle. Product leaders definitely understand this since they engage with other teams at the strategic level. Sales could always use another SDR and engineering another back-end developer, just like you can always use another product person.
The fact is, everyone will say yes to another hire if it’s offered. But do you know what you need them for?
The most important part of the hiring process is getting the right mind in the job. The second most important thing is onboarding that person correctly. Third is making sure that the new person knows what they need to do to be successful.
All three factors rely on your understanding what you’re hiring for. What problem are you trying to solve with this new team member?
Product is a flexible profession. As a product leader, I’m assuming you’ve had a couple of product management jobs in the past. Have they ever been similar enough to have the same job description? My bet is no.
Despite that, every product job shares one element: flexibility. As they say, the only constant is change, and that’s as true of product management as anything else. Yet many product job descriptions look the same. And before you copy that mistake, taking a job ad else someone wrote and making some superficial changes, I would like to point you to Kate Leto’s book, Hiring Product Managers. In it, she says that one of the most impactful tools in the discipline is the product role canvas.
In her words, “Ensuring there’s a clear and shared understanding of the role that you’re hiring for is an essential first step to thinking more collaboratively and comprehensively about what a new role might be before the interviewing even begins.“
How you understand the role in your organization’s context is incredibly important for the people who want to fill it. Product means different things to different people. How can you set someone up for success if you can’t define it for them before they walk in the door?
Use the product role canvas to define the problem you want to address before you move forward. Doing so will give you and the rest of the team (usually your designer and engineering peers, but this also can include folks like customer success and sales) an idea of what you are looking for.
Then, you can think about interview questions.
So, you know the problem you need to solve with your hire. With that in mind, you should write a clear job description that matches your problem. Don’t just copy and paste whatever you find on the internet.
Once you publish the job ad, you’ll start receiving applications, and you’ll invite promising candidates for an interview. What do you ask them?
I’ve seen teams blow this part of the process. Instead of being prepared and curated, the questions are either haphazard or clearly ripped from a how-to article. Product is far more calculus than algebra, and so you should know that anything that’s called “the perfect question for product interviews” is only perfect for the context in which the question was created.
Much like a good product, good questions help you tell a story. Even better, you create an environment for the person across from you, usually stressed and hurried, to show you their unique self. Strive to uncover “unique” traits rather than the “best” ones because that best isn’t who a candidate is day in and day out. “Best” is a character they have prepared to show you; unique is who they really are.
Tap into unique by asking questions like these:
These types of questions can lead to stories that give you the unique flavor of a candidate. Uniqueness wins here since you’re looking for someone interesting and adaptable rather and who meets every item on a checklist.
In product, you’re always looking to solve an ambiguous problem, How you rate the uniqueness of a candidate against the problem set you want to solve is important. Think about the problem and the types of both hard and soft skills necessary to solve it.
Your questions should also get the candidate to talk about their experience so they can form a tapestry of their experience. The follow-ups you ask should aim to give you a better understanding of who the candidate truly is instead of the “best” person they have prepared to show you.
Because we’re looking for a story, ask open-ended questions. For instance, ask “Walk me through a time you’ve done X” instead of direct questions about some specific item. This will allow the candidates to tell you their stories.
It’s important to get to the candidate’s uniqueness quickly because we’re on the clock. You don’t have much time to devote to this process.
As a hiring manager, you’re conducting interviews and hiring on top your actual job. Finding time to look over assets and grade things can be a hassle. So, why do teams act like they have a million years to do so?
Generally, you don’t have time to look at that long presentation, nor do you have time to dig into that case study, or to relisten to that hour long interview that the candidate gives you. Sometimes, you may not even have enough time to do more than Mad Libs on a review.
So, create a key for scoring interview answers. This document gives you the ability to do reviews shorthand. You can answer what others need to know without a ton of investment on your behalf.
As a part of that key, define the time that it is going to take to review the answers. Share those targets with both the interviewee and interviewer. Being honest about the time can help you and the team get clear sightlines on how much work you are asking of them. You can even bundle the time (e.g., a standing 30 minute meeting to review interviewees each week) to get through the review process cleanly.
And getting it right is the most important thing you are going to do as a manager. When you’re ready to take your team to the next level, you can’t afford to fail. Be clear about the problem, put the right amount of rigor in the questions, and set reasonable time expectations.
This may seem like a lot of work up front. Over time, though, you’ll spend less time thinking about the hiring process and more time thinking about the candidates themselves while being transparent about needs, which can help your team get a lot stronger in the long run.
Being a product leader is a different job and requires a few different skills you won’t learn as a PdM. Take the time to learn these new skills, and you’ll get better outcomes.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Product Leadership? Click here.
As product manager, how do you take your plans from theory to action? Simple: Tell the right story.
Making change is hard.
Even harder is making change while projects are in motion. As a product manager, though, this is the job. Remember, as a PdM, you are judged on how you improve the decision fitness of the team you are on. Just thinking about better decisions isn’t enough, though. You have to make them happen.
Turning plans into reality isn’t as easy as simply putting an idea on the table. Humans don’t work that way. Sure, you can try to force your agenda on people. Unlike other disciplines, however, product management works by influence, not brute force.
That’s because, while brute force may work, it won’t work for long. PdM’s thrive on influence without control. Using the stick instead of the carrot gets old fast.
But don’t take that lack of control as a license to not act. PdMs who let inertia take over hoping people just get it on their own don’t last long. Playing tattletale isn’t a winning strategy either. Whispering in the CEO’s ear, much like the proverbial stick, may work in the short term since the CEO has the power to make things happen. Thing is, though, people start to realize that you have no actual influence yourself, and they start to find ways to work around you.
No one respects the PdM who can’t influence change without relying on outside help.
MORE FROM ADAM THOMAS Are You Asking Too Many Questions?
So, what should you do if plan alone isn’t enough, but you can’t use brute force to accomplish your goals? In order to turn plans into action, what you need is a good story.
Why a story? Human nature means that stories captivate our brains. As you’re reading this, think about the last three things you’ve remembered for any stretch of time. I’m going to bet at least two out of those three were attached to a story that triggered some emotion in you.
As PdMs, we need to be storytellers. Our influence takes hold through the stories we choose to tell and the way we construct those narratives.
That’s all well and good, but how do you know what you need to include in a story? Well, let’s bring back an old friend: survival metrics. We’ll look at my personal principles of storytelling: leading with proof, repeating the story, and then iterating it inside of your culture. We’ll then explore how to use your story to turn survival metrics into action for your organization.
Before we begin, let’s have a quick refresher on survival metrics, which help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function that prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving everyone permission to act quickly.
Survival metrics create a clear picture of what can go wrong while a project is in motion. By spelling out potential limitations early, you’ve created a warning system for both the team and the company that will make any necessary pivots more effective since you won’t spend time convincing the organization to get on board with necessary changes.
Survival metrics have three levels, each based on the information you’ll get from answering questions about the project. If something is worth stopping the project for, the metrics are STOP statements. Those that lead us to reconsider the direction we’re going in are PIVOT statements. Anything that signals you to lean into the initiative as you build, even if things are a little rocky, is an INVEST statement.
So, you’ve put together a great batch of survival metrics. What happens next?
You need to create a story that can help sustain the metrics and keep them fresh in people’s minds. To do so, employ the three concepts we mentioned above: leading with proof, repeating the story, and then iterating.
Survival metrics’ underlying benefit is that they’re iterative. Every time you launch a project with survival metrics, you’ll notice some metrics go away and a few stick around. Those that you keep returning to are a clear measure of what your company cares most about. As you get survival metrics closer to reality through each iteration, the process you build will grow with your company.
People don’t just accept ideas out of thin air. Concepts need some proof to show that they work before anyone listens.
This is why conference talks work. The people onstage have been vetted. They are real experts who have some social proof supporting their arguments. The idea here, in short, is that people believe an idea is trustworthy because it has been verified by another source that they trust. The psychologist Robert Cialdini described this phenomenon in his book, Influence.
Trustworthiness can come in many forms: Conferences, articles and books can all provide social proof for an idea. This is true for survival metrics, but also for any popular concept. For example, I love opportunity solution trees. Teresa Torres has plenty of social proof, as you can see by typing her name into Google and perusing the pages and pages of results that attest to her expertise.
The trouble is, even if you have social proof, that’s not enough by itself. Social proof helps people see you aren’t just creating something out of thin air. There is more to the story, however.
If you’re focused on social proof by itself, you’ll notice new concepts start strong but never stick. When it comes to survival metrics, you’ll notice a team starts using the concept, but usage fades during release.
Let’s consider an example. A BobCo product leader, Jill, saw someone reference survival metrics in a tweet and began to read about them. She liked the idea and decided to introduce the product team to the concept.
Her two product managers, Alex and Erica, took on the task of implementing them with their respective teams.
Alex simply introduced the premise of survival metrics to the team. Everyone thought it was a concept that he had created himself. Lacking any broader context, the team just waited to see what was next rather than taking action.
Erica, before introducing the new paradigm to her team, read the article herself. To better understand survival metrics, she also watched a video from a conference talk and learned that other companies, such as Mailchimp, had used them. She added that background information in her presentation to the team, explaining where survival metrics come from and how other well-known companies had used them. Rather than just mentioning this new concept, she earned some buy-in by telling a comprehensive narrative about it. Thanks to the additional information, people on the team were curious about how they could use survival metrics themselves.
So, now that you have a story supported by proof, you need to keep telling it.
You’ve used social proof to demonstrate the validity of your metrics. Now, though, people keep forgetting that they’re supposed to rely on them during projects. How do you keep things on people’s minds?
Simple: You keep telling the team. Repeat the concept. Repeat the metrics. Repeat their value. In this case, you’ll repeat survival metrics in meetings, in documents and during standups. Say it over and over.
Repeat it until people get tired of hearing it, and then repeat it again. You’re fighting inertia. Since inertia is difficult to overcome when people are settled, you’ll have to continue to sell your work over and over again.
The story that you’re telling about survival metrics is a story of change. Survival metrics are crucial for an agile organization and its commitment to the Agile Manifesto. Specifically, they allow your organization to “practice responding to change over following a plan.” Keep that principle top of mind and reiterate it along with the survival metrics. Using the agile angle to explain why survival metrics work is the winning move when fighting inertia.
When you’re doing this, try repeating yourself in different ways. Build a slide that finds its way into every presentation. Write a note at the top of the sprint review to review every week. Make a video that appears with every demo. Just keep talking about survival metrics in a bunch of different ways.
In marketing, this approach is called the rule of seven, and you’ll hear it every time you listen to a podcast ad. The name of the product and the company will come up at least seven times, implanting the memory in your head.
Returning to our example, Alex simply said the words “survival metrics” once or twice during the meeting. He never mentioned them explicitly again, instead expecting the rest of the team to remember to use them. Because they were still waiting for more information, though, the team never did anything.
After the first meeting, Erica added the survival metrics and the relevant storytelling elements into all of the templates the team used. That way, everyone would see them again when they started something new. She also added it to the previous project to bookmark it. When the team saw the updated templates, she took the opportunity to tell a story about the metrics again, segueing into the specific metrics they were using.
Of course, repeating the story over and over again will get old, and people will eventually tune you out. This is why the story has to evolve.
So, you’re repeating the point and referencing social proof for support. That is all well and good, but if you do something long enough without adjustment, it becomes white noise.
Let’s be honest: As good as any tactic is, your mileage may vary since every framework you bring in was made elsewhere. Your company’s culture is unique, so a new framework won’t necessarily land right away. Survival metrics are no different. In my experience, it takes at least six months for a product team to take on a new framework as its own.
You have to build your own culture into survival metrics and then let them evolve within your organization’s culture. That’s why you’ll need to have some way to see the continuing validity of the framework and adjust accordingly.
This is where team retrospectives come into play. In those meetings, you can adjust the tactics you’re using by asking pointed questions and investigating, with your peers, how you can make your procedures better.
After introducing survival metrics to his team, Alex only talked about them in one more retro during the quarter. Soon, survival metrics disappeared, becoming just another tool that Alex talked about that never brought any real value to the team.
Erica noticed the new tool wasn’t inspiring action when she first used them with her team, so she took the time to talk to everyone about why the metrics weren’t guiding action and how to better implement them. They created check-ins to talk about the metrics regularly. The metrics started to improve thanks to having dedicated discussions every few weeks. By the end of the initiative, the team got to a point where they felt very confident in the metrics they selected.
Remember, frameworks evolve in the team retro. You and the team are the secret sauce for anything to work.
Changing is hard. Changing in action is harder. You are confronting the idea that you were wrong. That is hard to deal with, no matter who you are.
This is why story is important. Putting survival metrics in action with a story by leveraging social proof, repeating it, and using retrospectives to evolve the concept to fit your culture will maximize what you get out of it.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Product Strategy? Click here.
Too often, customer success and product teams treat each other like adversaries. Here’s how to fix that.
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.
MORE FROM ADAM THOMAS Are You Asking Too Many Questions?
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.
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.
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.
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.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Team Organization? Click here.
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 of if we’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.
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:
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.
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.
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.
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.
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.
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.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Team Organization? Click here.
Case studies are one of the most useful items in the product management toolkit. To build effective ones, you need to follow a simple but vital set of guidelines.
Robert Cialdini’s book Influence: The Psychology of Persuasion, first released in 1984, popularized the concept of social proof. This phenomenon consists of individuals copying the actions of others around them in order to acclimate to a system. People are subconsciously influenced by the behavior of other people within a given environment. Although this idea is simple, Cialdini’s book radically changed my mind with respect to how I interacted with the content that my product team and I produced.
Why was this theory so profound? Well, the book helped me understand why people were ignoring almost everything that we gave them. As it turned out, everything that we wrote was focused on ourselves and not on our customers.
We weren’t influencing. Instead, we were just talking.
Cialdini’s work gave a conceptual framework to something that the best marketers already subconsciously knew: Nothing sells better than reflecting the customer’s own actions back at them.
For example, say you want to buy a shirt. Which of these pitches is more likely to make you buy?
Option A: This shirt is made of polyester, washes well and makes you look professional.
Option B: This shirt is built for the product manager on the go. When you’re sweating the details and pacifying the battle between sales and engineering, you’ll want a shirt that stays tucked in as you rush from meeting to meeting.
Option B draws on social proof to reflect actions that you’ve experienced back at you.
Product management (PdM) is about helping the team improve decision fitness. That includes how we influence our customers to use our products, especially if we’re confident that our product is the right one for them. Social proof helps us accomplish this goal.
Before we can use social proof, however, we need a way to get the information that we want to reflect back to the customer. In other words, how do we come to see the world as our customers see it? How might we put ourselves in their headspace?
Sure, you can scan different websites, browse social media, or even look at your competitors to see what they’re doing. With any of these strategies, however, you’re only getting part of the picture. Like almost anything dealing with product development, talking to your customer directly is going to get the best results.
So, for PdMs to get the data they need to gather social proof and understand how customers see the world, we can rely on case studies. Let’s talk about what exactly these are and how you can use them to help you influence your customers and help other teams, like product marketing and sales, make better decisions.
MORE PRODUCT ADVICE FROM ADAM THOMAS How To Improve Your Product Research
For our purposes, a case study is an in-depth conversation aimed at understanding how a customer uses our product. We want to get to know who they are, why they use our product, and the context in which they use it.
This technique is how you get inside of your customer’s head. When you have multiple, deep customer conversations over a period of time, you’ll get a better understanding of what drives them. You’ll also be able to target your marketing so that it makes sense to them.
Building case studies is no different than doing any other interview. When conducting a proactive conversion with customers, you need to understand what you want, use open-ended questions, and analyze everything carefully.
You can go in a bunch of different directions when you talk to your customers. In fact, if you’re like most PdMs, this is an easy trap to fall into. Everything that the customer says may seem like gold, and it’s easy to follow any string in hopes of chasing down an insight.
So, how do you avoid that trap? You’ll need to write an outline to keep yourself on track. A case study outline is simple and has three components.
Those three components will help you avoid the trap of letting the interviews meander. Now, let’s talk a little bit more about those questions.
Your question set should be short, with no more than five max.
You want to follow up on your initial questions to get as many stories as possible. If you have more than five, you risk letting the interview get rigid since you’ll feel pressured to get to as many questions as possible. Further, asking fewer questions will make sure you have some uniformity to the answers.
Even though you’re just asking a few questions, you’ll want to keep them open-ended. An open-ended question like “Walk me through your shirt purchase. What drove this decision?” is better than “Did you like our service?” The latter could too easily elicit just a yes or no response while the former invites the customer to provide more detail.
You want to have a free-flowing conversation, which means focusing on the customer. Conversations are going to give you the information you need to build that social proof. Once you’ve acquired that information, you can analyze the material and create the case study.
Before conducting an analysis, make sure you sit with these conversations for a while.
Take the time to find good quotations that are interesting and align with your values by transcribing the interviews. Check to see if the language in your marketing materials matches how your customers talk. The closer your work matches their worldview, the more they will trust the product.
This process may seem simple at first. As you start to put this plan into action, however, you’ll see how much data you can collect and how closely you can tailor your product to match the mental model of your customers.
You’ll eventually be able to see if the plan is working when you make changes and hear from the customer again. The next time you talk to them, you want to hear something along the lines of, “Your [page/feature/tool] described my issue exactly, and that’s why I bought the product.”
When you have the data from the interviews, you’ll be able to build artifacts that match your customer’s mental model.
What are some artifacts that can come from doing a case study?
Customers want to tell their stories. When your product is great, rest assured they are doing it anyway. Most of the time, they are happy to spend time with you and your team and give you good feedback. More importantly, you’ll get the social proof you need to stand above the rest of the marketplace.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Product Strategy? Click here.
One of the most important roles of a product manager (PM) is setting the product strategy. The strategy, by way of a roadmap, is the document that drives team alignment. When a group of people adopts a strategy, it transforms the product strategy from just a piece of paper to something that drives team success. Informed teams, including product and everyone that affects product development—from engineers to executives, can deliver consistent results, essential to any organization that wants to grow from pure greenfield exploration into gaining product-market fit.
When you are looking for consistent strategic results that you can sell to the business and the team around you, you’ll need to escape the trap of pure feature velocity (“building stuff”) and get to building the “right stuff” that makes an impact for customers and the business. Consistent strategic results are essential because as teams scale, wasting time and resources gets easier.
Consistency is why the strategy must exist and live in the minds of those who need to operationalize it. That is when the strategy is truly alive when you can see it in action. But, unfortunately, most strategy is dead when it exists, but in name only.
What makes a strategy alive or dead? Well, let’s start by making sure you have a strategy that works first. If you aren’t sure what that looks like, you can find our complete guide here.
Building a product just for the sake of creating and maintaining something isn’t a strategy. Products should have a raison d‘être and exist for something beyond themselves. What drives the company? Why does the founder wake up in the morning? What about your product can the customer not live without? Take the time to communicate externally to find the locus of your product’s truth. Once you simplify that into something repeatable that a team can align around, you are most of the way there.
The alive product strategy has a clear, repeatable purpose. Dead strategy is muddled.
Our customers are important, so it is critical that any product strategy we make also has to meet the customer where they are. But, more importantly, we can’t fall into the trap of “building a faster horse” instead of a car. Our customers don’t deal in features, and they deal in problems. Those problems evolve, and so must our strategy.
Alive strategy evolves with the customer. Dead strategy is static.
Products don’t exist in a vacuum. Neither do its users. The product strategy must incorporate how it fits into the larger ecosystem, determining where it adds value and where friction points remain. As an ecosystem changes, the product’s role within it may also evolve. When determining strategy, you can find insight into how your product makes decisions—whether looking at your competitors or what systems your product builds on to work.
Alive strategy engages with the ecosystem. Dead strategy engages with a point in time.
Although strategic thinkers don’t possess psychic powers, they should cast an eye toward the future and anticipate likely disruptions to either limit or expand the product’s opportunities for growth and usage. Then, with a good strategy, you’ll see what chances the business is willing to take.
An alive strategy makes bets. Dead strategy “knows” the future.
With a view on the horizon, what can your strategy do to mitigate disruption or seize opportunities?
Alive strategy anticipates risks. Dead strategy hides them.
There’s no way to know if a strategy is successful if no one’s keeping score. While the strategy itself shouldn’t be hitting specific metrics, tracking progress and KPIs illuminate progress and offer potential warning signs.
Alive strategy iterates. Dead strategy always starts from scratch.
Simply having a strategy isn’t enough, however. For example, if a tree falls in the woods and no one hears it, did it make a sound?
Unfortunately, many teams that find themselves with a product strategy have to ask. “how does this matter to me?” and, as a result, lose interest. Strategy means nothing if it isn’t alive, in people’s hands, hearts, and heads applying to their work.
So, as we continue this article, let’s ask ourselves some questions. First, does any of this sound familiar to you?
Then your strategy might be dead.
Don’t fear! There is an opportunity here. If you have a strategy, you’ve already done the first step, create a strategy! So, we need to turn it around, and on that note, it feels like a good time to talk about what we mean by “alive.”
Yes, your strategy is living.
In fact, strategy is a muscle and an important one for teams to exercise. Much like the muscles in your body, they need nutrition, and for them to operate at their best, they need exercise.
So, what do we mean by that?
When we mention nutrition, your strategy needs context. Think about point two, mentioned above
“2. Understand customer needs and their evolution
Our customers are important, so it is critical that any product strategy we make also has to meet the customer where they are. More importantly, we can’t fall into the trap of ‘building a faster horse’ instead of a car. Our customers don’t deal in features, and they deal in problems. Those problems evolve, and so must our strategy.
Alive strategy evolves with the customer. Dead strategy is static.”
When you think about your customers, this concept makes sense. Our strategy needs to build towards our customers’ context of the marketplace. What if I told you that it needs also to do so internally – stakeholders who use your strategy also need that context.
So how is that strategy you made a few weeks ago? Is it alive? Does it have its nutrients? Has it gotten its exercise? In fact, when is the last time anyone referenced it?
Let’s talk about alive in another way – author Robert Greene once told author Ryan Holiday this:
“He told me there are two types of time: alive time and dead time. One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing.”
“Strategy is something that grows” is great as a mental model to see product strategy. But, remember, product strategy is a muscle. When a team sits around and doesn’t exercise that muscle, it will atrophy. An atrophied strategy is a recipe for disaster, as it is as good as no strategy at all. In fact, an atrophied strategy is a one-step towards a dead strategy.
So, let’s pose the question again, is your strategy alive? Like any new artifact, your strategy, once well crafted, starts that way. That said, from a distance, an alive product strategy can look like a dead one if you don’t know what to look for.
Don’t let your strategy turn into a zombie.
Grrr, brains
Zombies are scary (and possibly real). But we aren’t talking about those zombies right now. So instead, what we’re looking at is a zombie strategy.
The people we work with are smart and ready to work. A dead strategy, however, will sap their energy and leave our teams to fend for themselves. Moreover, as our teams grow, a culture built on dead strategy is a culture whose problems compound.
Product strategy is our domain, not theirs. When strategy atrophies, they will spend time working on things that make sense to them. Sometimes, the team will get lucky. Oftentimes, they will end up distracted.
That distraction is how you look up in the middle of the third quarter and wonder what happened to that roadmap you set in December. But, unfortunately, you’ve been bit by the strategy zombie, and as a result, the team is now playing catch up.
The bad news, as a PM, is you’ve turned into a necromancer. The good news is that you can step away from that. The first step, though, is to identify if there is a dead strategy in your midst.
How do you identify a zombie strategy? Well, if it’s well built, here are a few indicators. Of course, we won’t leave you without homework either, so expect some ways to clear the zombies out. Then, each section holds a way to move that strategy from dead to alive.
Our brains’ short-term memory holds 5-7 things at a time. Why is that important?
One of the issues that can zombify a product strategy is overloading people with too much information.
We may have an urge to load the strategy with everything we need to get done. You, as a PM, may feel like you are giving proper context – however, overloading the team with context is exactly what will atrophy your strategy. Instead of giving context and helping folks find alignment, you allow the team to turn off and figure it out independently. This is how your strategy sits on the shelf and eventually zombifies.
So, let’s make this real.
Let me ask a question:
If you were to go around your team and ask, “What are the three priorities from our product strategy?” How confident are you that individual team members can list these top priorities? What about within 80% of your expectation?
If you gulped during that question, chances are, you may have a zombie product strategy on your hands. Unfortunately, whatever you thought was happening isn’t. The zombie strategy is eating your team’s mental space.
In fact, brain science provides a reason for that. Our brains are more tuned to negative experiences than positive ones, up to seven times more. So those near-death experiences are negative experiences.
Strategy is a positive one.
The basis of strategy is here. You need to simplify.
Every discipline has its own incentives. It’s important to recognize that the strategy isn’t about you. Human beings are storytellers, and without something more compelling, they will take what is around them to create their incentives. That is why a telltale sign of a lack of an alive product strategy looks like this:
Engineering cares about engineering stuff, same with design, marketing, and sales.
It’s natural with any vocation. Teams are just telling themselves a story and running with it. Since it isn’t compelling, they have to make it up as they go along.
A strategy will atrophy if the members of the team don’t see themselves in the strategy. As a PM, are you aware of everyone’s incentive? If you have to wonder, chances are you don’t.
When building the strategy, remember strategy is an abstraction. That abstraction helps people fit their mental model into the world itself. If that strategy doesn’t help them, they’ll split their time between your strategy and their incentive at best, and at worst, completely ignore your strategy.
Then your strategy is dead.
As an owner of the product strategy, make sure you talk to the point of contact from every discipline. Meet with the team regularly and have coffee with random team members to find out what drives those team members to work.
This is a slower process, but every time you iterate, the strategy gets better. This is because you are working your strategy muscles with each conversation as you make it more alive. As a bonus, your relationship with the other discipline will get better, too.
Do not try to turn the entire ship at once. Our teams have enough on their plate. That is why we, as PMs, have to be very careful when we bring in a new process.
If we do, we have to do so thoughtfully and repeatedly. Once is not enough. Remember, our brains can only hold 3-7 things in short-term memory, so it’s far better to leverage things that are already comfortable in an organization or build it into muscle memory.
As PMs, we live with our strategies for a long time, making sense to us (only). So we want to try a new process to shake things up and partially bring newness to ourselves, selfishly. So, we make the team go through an exercise, something you may find on the internet, and never refer to it again since the pieces fit so well in your head.
Well, while you may remember it, the team around you has their own issues, and more than likely, is overloaded.
When this happens, you’ve walked right into a dead strategy since the team has learned not to take anything you’ve done as seriously.
As a rule of thumb, small edits to the current process are better than a new process. If you aren’t going to plan around a new process to ensure it’s compelling and do it often, don’t do it at all.
There is a pattern here. A product strategy isn’t alive on its own. So simply writing a great one isn’t good enough. Instead, as a PM or product leader, you’ll need to work hard at keeping it alive continuously.
It’s worth bringing up this quote again.
“He told me there are two types of time: alive time and dead time. One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing.”
One is when you sit around when you wait until things happen to you. The other is when you are in control when you make every second count when you are learning and improving and growing.
A great strategy is something you control, iterate, and grow. If you aren’t careful, you’ll turn from a PM into an unwitting necromancer. So your strategy will be less about control and more about waiting.
Strategy is a way to speed up alignment, and alignment isn’t stationary. If you aren’t working those strategy muscles, your strategy will turn from alive to dead. As a result, your team will get further and further away when strategy stands still.
Building a product strategy is not enough; make sure the strategy is alive and aligned not just with the market and the customers but also with the team that is working through it. When other functions use product strategy, it lessens the cross-functional burden and gives the organization a chance to course-correct when things aren’t going well.
Keep your product strategy alive with focused goals, aligned incentives, and repeatable processes.
Disclaimer: This content was originally posted at Product Plan. You can find all my writing from this website here. Want to see all my writing on Product Strategy? Click here.
Precision and accuracy may seem like the same thing, but understanding the distinction between them will let you level up your product management skills.
Would you prefer your work to be accurate or precise? This sounds like a trick question, right? Aren’t they the same thing?
Well, not exactly. Both are important to your product management practice. As a product leader, you’ll need to understand and leverage both concepts to make your strategy a reality.
Both accuracy and precision have dictionary definitions. If you look them up, you’ll see they’re quite similar. Let’s use the concept of the bullseye to make the distinction clearer.
Imagine that you’re an archer taking some practice shots by shooting at a bullseye. I’m judging your shots over the span of time, and I tell you I’m looking at both precision and accuracy. I would judge your performance the following way:
Your accuracy: This measurement tracks how close you are to the center of the bullseye. If you’re hitting the innermost circle, then that shot is as accurate as possible.
In product management terms, consider how right you are when solving a problem. Remember, you can’t ever be completely accurate, but you can approach perfection.
Your precision: Here, I measure how close each of your arrows is to the others. If all your arrows are hitting the same place, then you’re as precise as possible, even if the shots aren’t accurate.
In product management, consider how consistently you bring value to the market. Are your releases consistent?
In product management terms, accuracy is a measurement of your ability to deliver products that the market wants. A good way to track this metric is by the number of big wins your team scores. Precision refers to your ability to consistently deliver useful results to the customers. To make your team thrive, you need to do both.
Both of these concepts are essential to executing your product strategy well. If you’re failing at both, you’ll find your team is powerless. When both are rolling, however, then you’ll find that your team is full of trust and positioned for success over the long term.
Let’s look at this in a matrix since visualizing things makes understanding this principle even simpler:
Let’s talk about each one of these quadrants. Each section of this article will define how they look in practice. If your team isn’t in the top-right quadrant, you’re going to want to fix that. We’ll talk about the consequences of each of the other quadrants and then, in the end, I’ll leave you with a workshop that will allow your team to move to the top-right.
MORE FROM ADAM THOMASHow to Improve Your Product Research
Let’s start with a look at the best-case scenario. What is the ideal state?
When your strategy is both precise and accurate, you solve customer problems and leverage your resources well.
This team can take many forms. Much like enlightenment, the path is different for everyone. But you’ll be able to tell you’re on the right track because things run smoothly.
A team that’s both precise and accurate has the right stuff. Your team is curious, thoughtful and action-oriented. They know how to look at the marketplace and create big wins to make a splash. The team also knows how to keep the marketplace happy with consistent results.
When you ship smaller releases, your customers are generally appreciative. Larger ones generate a buzz in the marketplace. Product usage makes clear that the customer needs what you’re giving them. For most releases, you’ll see over 40 percent usage. Those that aren’t at that level are usually specific add-ons for a particular segment of customers whose numbers may be small, but who are willing to pay for the exclusivity.
Product leaders: When a team is operating like this, your job is to get out of the way and let them cook.
Now that we have a good baseline, let’s take a look at what happens when teams are missing a part of the equation and it’s time for you to help.
Let’s go now to BobCo, whose product team has a precision problem.
Over the last few quarters, they seem to have found some things that work and work well. The only problem is that, out of the 10 items they ship, only one or two of the products are helpful to customers.
Why is this a problem? Home runs are great and tend to bring better visibility to a company and a team. But delivering only big wins, punctuated by long stretches of not much at all, eventually leaves people wanting. After a while, teams expect to have some consistency in their work.
The result? The product team never knows how to justify resource requests to the broader company. Your lack of consistency means you don’t know what will be a hit and what will fall flat. Outside the company, the marketplace thinks you are great entertainment but not a serious player.
BobCo’s product team continues to work hard, but they can’t seem to make the case for growing the product function. The team starts to fade from importance in the organization, and as a result, loses influence. Product trades in influence, so this is a serious problem.
As a product leader, your responsible for the fact that the whole organization is stuck in the mud as other teams catch on to the issues.
How do you fix this problem?
The culprit is likely your lack of iterating on the process itself. My guess is that the most significant fixes will come when your teams have an opportunity to adjust processes. You probably aren’t reflecting on anything. Take a moment to slow down delivery and see how you can get alignment on how you ship.
A useful tool to generate this alignment is a team retrospective workshop.
MORE FROM OUR EXPERT CONTRIBUTORSHow AI Is Shaking Up the Insurance World
Let’s go now to HobCo, a team that has an accuracy problem.
Unlike BobCo, they seem to be able to get the team to provide value regularly. The problem is that they aren’t shaking up the marketplace.
Why is this a problem? Well, it’s basically the inverse of what we saw above. Being reliable is excellent, but over time, that consistency becomes less effective. It’s how you open room for new challengers to eat your lunch in the marketplace. You’ll run into issues with people feeling like the product is in the background. They aren’t making a splash, and people forget the team exists.
The result of all this? The product team recedes into the back of people’s minds. Always being reliable makes your product always a bridesmaid, never a bride. When a new player hits a home run, you’ll have to explain why you missed it.
Hobco’s product team continues to work hard but, just like we saw above, can’t manage to grow the team or its influence.
As a product leader, you’ll watch your team fade in importance. You lose influence, and much like your compatriots at BobCo, your team will be stuck in the mud.
When you find this is your problem, it’s an excellent time to take a look at your discovery processes. How are you talking to customers? Are you identifying who they are and what gets them emotionally invested or divested?
To do this, look at why customers are leaving your product, and find some big swings to take Switch interviews are a great tool for making this change.
Let’s finally look at SobCo, a team that has a problem with both accuracy and precision.
Unlike either of the previous companies, this team is neither accurate nor precise. If you thought the rest of the company ignored the product teams before, well, you haven’t seen anything yet.
Why is this a problem? No one takes product seriously as a team.
Because product is considered trivial, everyone bypasses the product team entirely. If you’re lucky, your company becomes a feature factory that can crank out some products. More often than not, though, everything related to your strategy becomes more scattered. People can’t track what you are building or why it’s important.
Product development still happens, but you just won’t be involved. For a product team, this situation is apocalyptic.
The team itself is now on the brink of extinction. As a product leader, you either have to start digging your way out or start looking for another job.
To start fixing this situation, you need to recognize that the biggest problem now is trust. Other teams are more than likely ignoring you, and for a good reason: They don’t trust that you can get things done. If you want to dig out of this hole, your best shot is to look for something small to tackle immediately. Find some quick wins to get some momentum on your team’s side. You can use those wins to begin re-establishing your team’s confidence in itself as well as earning back respect from the company at large.
I’d recommend finding a coach if you are a product leader in this situation. Even if you’re a new hire, having a second brain here is helpful.
To find tools to facilitate this process, go to Google and pick any framework related to process or discovery. Most will be helpful as a way to find a solid base to build on.
Start small, and good luck. You’ve got work to do.
Precision and accuracy are both important to your product development.
Missing one or the other can lead your team to fade into obscurity and lose influence across an organization. If you are missing both, well, things aren’t great, and you’ll need to work immediately to gain control of the situation.
It isn’t enough to just build a strategy, you’ll need to execute that strategy in a way that sells product to an organization. So, when someone asks whether you would you like to be accurate or precise, the answer is both.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Product Strategy? Click here.
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.
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.
MORE FROM ADAM THOMASSurvival Metrics Are a Powerful Product Tool. Here’s How They Work.
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.
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.
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:
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.
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:
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?
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.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Team Organization? Click here.
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.
MORE FROM ADAM THOMAS How to Improve Your Produce Research
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.
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.
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.
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.
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.
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 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.
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.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Team Organization? Click here.
Product teams often know that a project needs to change direction, but they don’t have a way to make that change safely and quickly. Survival metrics empower them to do just that.
The product strategy you made at the end of 2019 didn’t work. It most likely was invalidated by the events of 2020 — and if it wasn’t, email me because I need to buy lottery tickets soon. As our industry and society have been forced to adapt to new circumstances, the importance of flexibility has become clear. Despite this, one of the things I’ve consistently heard from several teams and product managers I’ve coached/advised is that, although they understand the need to be flexible with projects, they don’t have a way to do so.
Often, broaching the subject of a pivot brings up a bunch of questions from everywhere in an organization. These questions can quickly shift to blame. Next thing you know, what began as a conversation about making a strategic change in a product’s development turns into a political sniping session where the stakes can be extremely high.
I’ve seen this happen at companies big and small. I once saw a project with a nine-figure budget implode all due to a small shift in direction, and it ended up taking almost two years to get to a shippable product. Similarly, at a 100-person company, a debate over one feature led to people threatening whole departments. Yikes.
As a result of these stakes, most teams would rather continue down the road they’re on and launch something, even though the product may no longer be relevant to the market. This rigidity means companies spend an untold amount of money on both development costs and opportunity costs. It’s easier to stick to the way you’ve always done things than it is to change. But that doesn’t change the fact that you can’t afford to waste resources.
Product management’s role is to improve their organization’s ability to make intelligent decisions. Like it or not, it falls on us to enable the company to change direction in a way that serves both the customers and the business itself.
A good change in direction should have three core qualities:
Fortunately, I’ve created a framework that helps PdMs take that pivot from just a thought to reality: survival metrics. Using these will help get your team unstuck and on the road to making better decisions.
Survival metrics help a product team determine if an initiative is worth investing in more, pivoting or stopping completely. They are a forcing function to prevent product teams from suffering due to the sunk cost fallacy. Survival metrics put resource allocation and company incentives, both implied (think politics) and direct (think data), in front of the team before a project begins and again at regular intervals, giving permission to act quickly.
Survival metrics create a clear picture of what can go wrong while a project is in motion. By spelling out potential limitations early, you’ve created a warning system for both the team and the company that will make any necessary pivots more effective since you won’t spend time convincing the organization to get on board with your change.
Survival metrics have three levels, each based on the information you’ll get from answering questions about the project. If something is worth stopping the project for, the metrics are STOP statements. Those that lead us to reconsider the direction we’re going in are PIVOT statements. Anything that signals you to lean into the initiative as you build, even if things are a little rocky, is an INVEST statement.
As Marty Cagan likes to remark, a product manager’s job is tied to the feasibility of an initiative. Is this worth doing based on our current state? Survival metrics help simplify those feasibility markers and make them public in a way that is readable to the rest of the organization.
Here are three questions that help you identify those survival metrics:
You can turn the answers to these questions into metrics, both quantitative and qualitative, through your intuition as product manager. You’ll find some of the answers through documentation, some of them through asking questions of the team members on the ground and some of them through talking to the stakeholders who own the profit and loss of the initiative. You’ll also find some of this data is already available internally in different departments. This information generally isn’t disclosed to the whole organization for many reasons, yet it still affects projects. Part of your work here is collecting it all.
Questions like the ones you saw above will give you a path into finding out how the organization ticks and will help you get to a place where any pivots are fast, politically safe and data-informed. So, spend some time talking to the teams around you. You can do this either informally during a coffee meeting/lunch or more formally with a survey.
Gathering this data can be difficult at first, but it’s vital for creating good survival metrics. When you get this information, it is critical that you translate and prioritize the answers that aren’t direct and then make everything public. By doing so, you’ve turned an implicit agreement about what factors will make the team change direction explicit for everyone to see.
Let’s see how this works through an example.
Imagine you’re a new product manager for a company called Bobco, and the company is looking to make a new chat feature. You begin surveying the various departments that will play a role in building the feature. Almost immediately, you hit pay dirt. You find out from the engineering team that they have had a tough time with their Amazon Web Services spend and will blow past their budget if this tool leads to a 10 percent increase in cost.
The survival metric in this case is simple. If the AWS bill is projected to jump more than 10 percent due to a production release, you will need to discuss ways to lower the projected bill immediately or else the company will not be profitable. This limit may not have been discussed outside of operations meetings due to the ops teams thinking it’s irrelevant to other departments. In fact, you know this information is incredibly important to the team working on the feature. So, you’ll create a survival metric in the form of a PIVOT statement: “If the AWS bill is projected to jump more than 10 percent due to a production release, we will need to discuss ways to lower the projected bill immediately.”
Through your conversations, you also find out all of the following:
Bobco doesn’t use third-party info. This becomes a STOP statement: “If we have to grab information from third-party sources to complete our chat feature, scrap the project and invest the resources elsewhere.” Bobco considers this value non-negotiable, so put it here in the metrics, in plain sight of the entire company.
You talk to the leadership team, and they want to be sure that the problem they’re trying to solve is truly a big pain point for users. This will become a STOP statement: “If the problem definition research is not aligned in a reasonable way after we introduce a scenario, it could mean this problem isn’t clear to our users, and we’re wasting our time.”
You discover that the marketing department feels unclear about the product’s features, which becomes a PIVOT statement: “If we haven’t demonstrated the features to our marketing team in a way that they feel comfortable with the product, take some time to discuss process.”
As you talk to people across the organization, you hear repeatedly that the company doesn’t want to replicate products like those already on the market. This can become a PIVOT statement: “Bobco isn’t interested in making a chat app like Intercom due to market pressure. If our chat app is mimicking Intercom and users bring it up during our usability testing, we should reconsider the project.”
Your investigation shows that beta invites are likely to be greater in number than initially projected. This should be an INVEST statement: ”If our beta invite population is twice our current projection, this could signal real excitement from our customers. We should take time to talk about ways we could expand this project.”
These metrics will be both qualitative (the uncountable, from interviews and observations from your conversations with various departments like the research metric) and quantitative (the countable, like surveys and usage data from things like AWS metric).
If anything is important enough to change the status of the project, such as a team violating the values of a company, going over the budget allotted or even something that would call for more investment like a ton of usage, then it should be reflected in the survival metrics.
Every statement here helps the team get aligned. A lot of what you are surfacing here are questions other disciplines have about the other people on their team. Think about it: As a PdM, you have a perch above the organization that grants you a higher-level perspective. Other teams, who often work heads down, don’t have your context. When pivots happen without survival metrics, these folks might create stories to fill any gaps in their knowledge. These stories compound and can leave a team pointing fingers. Survival metrics prevent finger pointing.
Again, survival metrics allow for decisions that are fast, politically safe and data-driven.
As a product manager, part of your job is taking a ton of information and making it digestible for other departments to help them make more intelligent decisions. To do that, you’ll need to translate the data you’ve found, prioritize them and then set up a cadence to revisit them often. If you need a specific format for your document, take a look at this initiative one-sheet as a way to wrap the survival metrics with great contextual information.
As we saw above, you translate the data you gathered in your investigations into survival metrics. For the quantitative ones, set limits, like the 10 percent AWS budget in our example.
For qualitative statements, making them binary classifiers is helpful. If a qualitative statement leaves someone unable to decide because it has too many choices, then it’s useless. If you have some researchers on your team, they’re likely a great resource to help translate qualitative statements into metrics. They deal with qualitative statements and research often and can help bring some clarity.
We saw above that the company didn’t want to imitate the Intercom chat feature. We can translate that into a qualitative metric that says if users mention similarities during testing, we need to pivot.
You’ll now have to prioritize all of the metrics against your team’s strategy and company mission. The truth is that some metrics will be more important than others, and those that aren’t important will have to be abandoned. At some point, we’re measuring too many things to be effective; five to seven metrics is the sweet spot. You’ll need to determine which metrics are most likely to make any changes fast, politically safe and data-informed.
Naturally, you’ll use the signals you’re getting from the organization. If these signals are weak (meaning anecdotal or not supported by many signs), feel free to ignore them. If they’re strong (tied to strategy, bolstered by a ton of evidence), elevate them. This will get easier to evaluate the more you use survival metrics.
The company’s mission statement and product vision are a great place to start your work. Including anything you find there in your metrics is important to clarify the importance of both statements to everyone in the organization and help move them from abstract to operational.
Returning to our example, since we saw that Bobco really doesn’t like stealing data from its customers, we must have that value reflected in the chat app’s survival metrics.
Let’s also imagine that we find that the beta population metric you found from the CEO isn’t really important at all. Perhaps you find that most of the sign-ups for the beta weren’t from genuinely interested users. If so, it’s worth removing that INVEST statement before you present it to the team.
Now that you’ve translated the statements into metrics and prioritized them, you’ll need to make sure that you communicate these statements to the team often and tie them to what’s happening during product development. That’s why checking in every two sprints and tying those metrics to a retrospective is a good way to see if something is still functioning as a good metric. Keeping the survival metrics fresh allows the team to see their usefulness and make sure you aren’t losing the feasibility of the initiative as a whole.
Now, that deployment is a little clearer, I want to make sure we don’t mistake this for another popular concept: success metrics.
We could think of survival metrics as a riff on success metrics, but this wouldn’t be right. Success metrics alone don’t let you know when you need to adjust.
Success metrics are a common evaluative framework for product development teams, and they’re a great way to measure outcomes. Survival metrics, however, are focused on the product’s development rather than its outcome.
Survival metrics have to be differentiated from success metrics because a project may have been worth it even if it isn’t “successful” when you get to the end. For instance, Steph Curry doesn’t make every shot, but that doesn’t mean he needs to totally revamp his shooting form. His process still has value even if it’s not successful 100 percent of the time.
Both success and survival metrics are important because they measure different things. Success metrics are customer-focused and think about end-state. Survival metrics are far more focused on the team itself, gauging viability as the project is in flight.
As teams use them more, survival metrics get stronger in two ways. First, they get stronger because each time the team works on a new product, they have more confidence pivoting when the project doesn’t make sense. Secondly, teams can build on the insights of the other teams across an org through reading other survival metrics. This becomes a virtuous cycle by which every department makes stronger metrics and improves their ability to respond to change in real-time.
Given the landmines that often exist, changing projects isn’t just a switch you can flip. When using survival metrics, though, we can face the reality of institutional opposition to change and move forward with the knowledge that we can, as a team, make necessary decisions about a product’s future with the wind of the organization at our back.
Disclaimer: This content was originally posted at Builtin. You can find all my writing from this website here. Want to see all my writing on Product Strategy? Click here.
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?Sed ut perspiciatis unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo. Nemo enim ipsam voluptatem quia voluptas sit aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos qui ratione voluptatem sequi nesciunt. Neque porro quisquam est, qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit, sed quia non numquam eius modi tempora incidunt ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit qui in ea voluptate velit esse quam nihil molestiae consequatur, vel illum qui dolorem eum fugiat quo voluptas nulla pariatur?
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
When the hard part is over – it’s all downhill.
Put on your skis.
Let gravity do the work.
