#233 – What does it sound like when you change your mind?
Tag: product
-
Black Epics
Black Epics is a podcast dedicated to sharing the stories of successful Black Product Managers.
Photo by Josh Kahen on Unsplash Ronke Majekodunmi – How to build strong coalitions
Tonya Edmonds – How to Successfull
Vince Aidoo – The Value of Learning from Failure
Ayo Omojola – Fighting Covid and Pushin
Rafael Balbi Jr. – Key Learnings in Becoming a Principal PM
Sasha Kai Parker – Incorporating Innovation into Product
-
What Do Product Managers Produce?
Product management, unlike many other technical disciplines, doesn’t create a discrete output. So, what should you be spending your time on?
Photo by airfocus on Unsplash Product managers (PdM) are responsible for helping companies make better decisions consistently over time.
In a previous article, I talked about how wide-ranging the job can be. Product managers do a lot, but the most effective thing a PdM can do is focus on raising the decision-making capabilities of those around her.
After writing that article, I heard from a few folks who wanted me to expand on the idea that “PdM’s have no discrete outputs, and to focus on them is a waste of time.” On the surface, this statement is about outputs over outcomes. Outputs don’t tell us much about how to make better decisions, whereas mapping outcomes over time tell us a lot about who we are as a team. Focusing on shipping code or designs as a PdM may feel good short term, but in the long term, it doesn’t really help the team.
I wanted to take a step back and add another point: Focusing on responding is a choice that has an immense impact on how PdMs spend their time. You own your time as much, if not more than anyone else you work with. You aren’t attached to the deadlines that other disciplines have. For example, an engineer needs to ship code on time, or the sales person needs to close the deal. A PdM’s time is more fluid since deadlines are much more ambiguous. The catch, however, is everyone else feels like they own your time too.
Your time management directly impacts your ability to manage the job as a whole. Without finding space to learn how to respond instead of just reacting, you won’t be able to manage what happens around you.
What do I mean by that?
Let’s spend some time dissecting PdM time management. We’ll examine how time management impacts responding over reacting and how focusing on outcomes is your most important job.
THE PRODUCT OF PRODUCT MANAGEMENT
Product Managers (PdM) are responsible for helping companies make better decisions consistently over time. We do a lot, but the most effective thing a PdM can do is focus on raising the decision-making capabilities of those around her.
Product Management Is Time Management
There’s always a demand on your time, isn’t there? If there’s one thing that PdM’s won’t ever run out of, it’s requests. These ceaseless requests are why time management is important. You’re expected to raise the level of decision-making while managing an unknown number of inputs from stakeholders who often aren’t quite sure what you do. They just know that, whatever it is, they feel better when you’re there.
In short, you’ll find yourself becoming the company’s safety blanket if you aren’t careful. Some of you who are reading this can look at your calendar and see the signals:
- A calendar full of meetings, none of which have a theme.
- An inbox of soft requests from all over the business
- A Slack that might as well be painted red.
If you see any of those things happening, I have some bad news for you: You can’t raise the decision-making quality of the team around you since you’re constantly reacting to the needs of others.
Let’s make this real by checking in with John, a PdM at BobCo. John has been with the team for three months. Since there was no product manager before him, his work helped the team gain insight into the company’s vision and align their work with it. He has been super helpful to everyone, always raising his hand and trying to solve problems, wherever they are in the business. This attitude gained him a ton of trust early.
That trust didn’t come without a cost to his thinking, however. In short, he didn’t have any. Every morning, there was the same routine:
- Wake up to 30 Slack messages. He does triage and respond to the most important 10, saving the rest for later.
- Attend a meeting. Although he’s there in body, he isn’t in spirit because he has to deal with those 10 major Slack messages.
- Another meeting, which he uses to process email. Thank goodness, most things have transferred over to Slack internally, but there is still some code he can push to production. Doing so will speed up the sprint and help the team reach its goal of 24 story points.
- Phew, the third and final meeting of the day! Wait, what were the last two meetings about? No matter, everyone else felt great with him there. Now, he can help with a quick sales deck.
- This process continues until the Slacks stop going off.
The past three weeks have been like this, and while he feels busy constantly, he’s realized that nothing ever gets done.
Responding, Not Reacting
In his seminal behavioral science book, Thinking, Fast and Slow, psychologist Daniel Kahneman described two distinct systems for human thought.
System one refers to our gut reaction. This type of thinking is reactive and quick drawing on our emotions and current state to move as fast as possible.
System two is our responsive system. This approach is slower, focusing on logic and taking effort.
System one thinking drives quick solutions and bandaids. When you’re running into an issue with a lack of resources to push something over the finish line, here are two ways your brain may try to handle it.
System one says, “It’s no big deal, I used to be an engineer. I can just code that up!”System two, by contrast, thinks, “This has happened three times in the last quarter. We need to adjust our product development methodology to understand why we are falling short.”
Which one of these sounds more like decision-making? System two does. System one leaves the PdM in trouble because, not only is he messing with code that he hasn’t spent a ton of time with, now he doesn’t have time to think about the overall issue either. Without looking at the big problem, the PdM will continue to drown as more red buttons appear on Slack.
Let’s go back to John. He’s realized that his calendar looks crazy and he is falling behind his OKRs for the quarter. This doesn’t make sense, though, because … well, he’s so busy!
He reaches out to Jill, the director of product, for an informal coffee and coach session. Coffee and coach is Jill’s way of informally coaching the product team on how to spot problems. John wondered, with how much Jill oversees, how she had time on her calendar for such a session.
The coffee, starting with small talk, soon gets to the meat and potatoes.
“Jill, I find myself underwater. Even though I’m shipping stuff and answering my Slack messages fairly quickly —” his Slack goes off again. “Sorry about that! Anyway, I don’t see any long-term progress.”
Jill sipped her coffee; this is the part of the job she loves because she knows there is a growth moment for a PdM in front of her. This is what evolving in your role looks like.
“John, I want you to look at your phone, but before you do, I want you to tell me, on a scale of one to five, how important is that last Slack message to your overall goals this quarter? After you tell me your prediction, I want you to read that message and tell me the actual number.”
John tells her three, playing it safe. Then he looks at his phone and sees it’s nothing serious, really a one.
Jill smirks “ I can tell by the look on your face that the message wasn’t that important. Do me a favor: Look at the last 10 messages you’ve gotten. Do any of them crack a two? Could any of those be delegated, if not ignored outright?”
John shakes his head as he goes through the messages.
“What you are seeing here is that you’re becoming a safety blanket. The company likes you and trusts you. But I bet you can’t tell me anything from your last five meetings that was important and how it worked with your goal.”
John sat there, quiet.
“No worries — we’re going to fix this. In fact, this is a big part of your growth as a product manager. Your homework for this week is to look at your calendar and decline every meeting that doesn’t have anything to do with your goal and for which you can’t delegate the work. I also want you to delete the IDE from your company laptop and make no slides.”
Now John looked worried.
“Tell them you’ll need to withdraw and let them know if they have trouble, reach out to me. I then want you to leave your laptop at work and take the next few days off. When you come back the week after, don’t accept any meetings outside of your team rituals and turn off your Slack notifications. Answer them outside of meetings. Meet me here the Wednesday after next for breakfast, and we will talk next steps.”
Our Best Asset as Product Managers
As product managers, we have no discrete output. When it comes to our teams, the product manager is not responsible for anything people can wrap their hands around. We don’t write code, we don’t make the UI and we aren’t making the sale.
What we can handle, though, is the heavy lifting of our teams’ decisions when it comes to process, empowering everyone to make better decisions. So, every moment you focus on outputs, you’re taking time away from helping your team in the long term by avoiding the harder problems that accompany crafting successful products.
Useless meetings are outputs. Responding to every Slack message, direct and indirect, is an output. Coding is an output.
If you’re doing one thing, you aren’t doing another. If you chose to focus on output, you aren’t choosing strategy. If you pack your schedule all the way and leave no room to process, you are choosing to stay still. Managing your time like this is hard, but it’s the job.
Without removing yourself from unnecessary entanglements and delegating, you’ll find yourself on a treadmill. You’ll never gain a discerning perspective. You won’t find yourself with the time to deliver decisions.
Let’s check back in on John and Jill during breakfast.
John arrives; surprisingly, he finds Jill unbothered, drinking coffee, as usual.
“I am surprised you aren’t sweating, Jill. I had so many irons in the fire, I thought you would feel the burn or at least get a little singed. No one came up to you asking where I was?”
Jill smiles again.
“Nope, everything is fine. Your presence wasn’t as missed as you think. Tell me, with that week, what did you get done instead?”
John smiles with renewed vigor.
“Well, I was able to get into the data in a way that I’ve been putting off. I found that one of our initiatives was a waste of time, so I’m planning on scrapping that next week and putting the energy behind some follow-up discovery that has a high probability of success.”
Jill nods.
“During our retro, I facilitated instead of Slacking, and we had a really powerful conversation. I found out about two blockers, one of which you fixed pretty quickly. I was surprised.
Jill takes a sip and remarks, “Amazing what you can see when you look,” smiling.
John finishes off his answer by saying, “And I was able to put the research back into the product strategy, and we found a way to move some work and get back on track there.”
Jill smiles. “Now you have something impactful to go back to those other teams with and see if you can pull them along. That’s how we merge trust with data.”
Jill and John talk through how they can do that as they wrap up breakfast.
MORE IN PRODUCT
Hiring the Right Product Marketer Can Make or Break Your Startup
Decisions > Output
Every time we make a choice, we don’t make another.
If our heads are down, we can miss the forest from the trees. As product managers, our job is to help the team avoid running into a tree face first. We do that by having the confidence to say no, managing our time, and focusing on putting together the pieces of the puzzle.
When we do that, everything else will fall into place.
-
To stay agile, don’t let your product team get trapped in a loop
To ensure your product team is truly following the Agile Manifesto, you have to give yourselves time to adjust. That can’t happen when you’re stuck in a positive feedback loop.
Photo by airfocus on Unsplash Product managers (PdM) oversee more than features. Simply focusing on them is a mistake and will leave the product person in charge of nothing more than a feature factory. Feature factories turn PdMs into project managers, which means doing far less research about why we’re making what we make and more simple delivery. Although PdMs can do project management, that’s a poor use of our skills.
Let’s see if this sounds familiar. A stakeholder says they know customers need a widget for a huge enterprise deal. They say to just trust them, they’ve talked to the customer and know what they need. We don’t have time to research, and a competitor is already working on this. Just get in there and build.
Take the requirements, build what they say, and produce features. Many teams take those orders and follow through on them. It’s easy to do, and no one gets in trouble.
Well, nobody except the company. The team builds plans that satisfy stakeholders’ fears instead of meeting the actual customers’ needs.
Here is the truth: Companies that do this are executing a terrible version of agile. Worse, they generally don’t understand they’re dismissing the Agile Manifesto. They probably also paid a lot of money to consultants to “transform” their product development processes. Either that or the company is a startup, arrogant and drunk off of the ability to fundraise instead of delivering to the customers.
Either way, instead of operating based on the Agile Manifesto, which we know works, the product development team turns agile into shorter forms of a waterfall development model, a more risk-averse form of linear product development, with none of the benefits.
The manifesto, which built much of the architecture that holds up the top 10 companies of the S&P 500, has turned into a shadow of itself. Likewise, the team’s “transformation” turns into anything but.
AGILE DEVELOPMENT AND FEEDBACK LOOPS
The agile methodology values responding to change over following a plan. In order to do that, teams have to work in negative feedback loops that allow built-in breaks for adjustment. Getting stuck in a positive feedback loop means you risk transforming from an agile team into a feature factory.
Responding to Change
Let’s focus on the manifesto’s fourth tenet, responding to change over following a plan. The ability to respond to change instead of blindly following a plan **cough** generally in the form of a roadmap **cough** is the difference between teams that just say they’re agile and those that truly are.
Fortunately, I’ve already given you a tool to help here: Survival metrics help teams focus on the fourth tenet by assisting a product team in determining if an initiative is worth investing in more, pivoting, or stopping altogether. At their best, these metrics provide a shock to the system that forces the team to think about what adjustment to make. This jolt can get teams out of positive feedback loops in which they continually make the same products based on inertia.
But here’s the rub. If you only define survival metrics once and never update them, then you aren’t adjusting to change. Instead, survival metrics become just another plan to blindly follow.
Survival metrics are about change. Change doesn’t just happen at the beginning of a project, either. It’s a constant factor in agile product development. So, you have to adjust your survival metrics to keep up with your development. If you don’t, you’ll end up doing a version of the small waterfall model. Your handoffs will be smaller with none of the benefits that agile brings.
The easiest way to avoid blindly following a plan is to create a negative feedback loop. We can use a tool we’ve talked about before, premortems, alongside another PdM best practice, retrospectives, to create the breaks that allow us to adjust our survival metrics as time goes on.
How do you do that? Well, let’s walk through the process. We’ll follow Bob and Rachel, two PdM’s at WidgetCo, over a two week sprint.
Before we do, though, let’s go negative.
Going Negative
Would it surprise you to learn that agile is built on negative loops, not positive ones? The difference between the two is simple. Positive loops offer teams no way to adjust since they are designed to accelerate, while negative loops have a break (think of this as an adjustment period) that helps you get closer to reality.
What does that mean for agile development, you ask?
Well, I would argue most teams live in positive loops. When have you seen your team change direction? The Agile Manifesto tells us to respond to change over following a plan, but ask yourself how often do you find yourself just following a roadmap you built a year ago?
Negative loops happen when something stops the loop, allowing teams to adjust. Think of the negative loop as one where you must respond to something.
Feedback Loops in Practice
Let’s look at this distinction through the lens of two teams. Rachel’s team naturally goes with the flow and, as a result, works in positive loops. Bob’s team, on the other hand, works in negative loops so they can adjust when things change.
Rachel’s team has a shiny, new roadmap. They blindly trust the plan, and after developing survival metrics, they focus on just getting the next feature out. They decide that retros are a waste of time that just slow them down. Instead of doing one every two weeks, they just continue to build whatever the plan tells them to as long as no one is visibly angry.
Bob’s team also has a shiny, new roadmap. They trust the plan but verify it before beginning. They run a premortem and create survival metrics using the data they get from the workshop. They work with the metrics for two weeks. After that time, they take time to do the retro they have planned. When they look at their work, they find something they didn’t expect.
Using the Premortem
The premortem is a workshop where the team gets together to envision what could possibly go wrong during a project and adjust the plan to account for those eventualities. This may sound like ordinary planning, but what makes premortems different is that the workshop format allows a mixture of voices that can lead to new insights.
A neutral observer needs to facilitate these workshops. This facilitator needs to move the conversation forward and keep notes. Without a facilitator, this workshop can go off the rails.
Without further ado, here is a template for the workshop:
- Check-in. Spend a few minutes trying to understand everyone’s mental state by asking, “How are you feeling?”
- State the objective. Ask everyone to write the objective of the product down on a piece of paper, then have the facilitator check all the sheets. If the objectives match, hooray! That means everyone has done the reading. If they haven’t, then spend the next few minutes aligning the team around the goal.
- The project has failed. Tell the participants to imagine that the project has failed, and ask them to write one or two reasons why. Do this as a brainwriting exercise. You want everyone’s unfiltered point of view.
- Vote. Which problems seem the most likely? Pick the top three.
- Discuss. Talk about the “why” for each of these problems amongst each other and come up with a few action items to avoid the impending disaster.
- Build. The facilitator works with the team to turn the action items into something the team can track. This output can either be eigenquestions if they are going to guide the product delivery process or new survival metrics if there is a trackable change in the process.
- Vote again. Hold another vote to see if this new set should unseat the other survival metrics the team started with. Remember you only want five to seven survival metrics in total. Ask whether these new metrics or the old ones will move in the next few weeks.
Rachel’s team doesn’t take this process seriously and skips it, preferring to follow the roadmap.
Bob’s team does this workshop and finds two of the original survival metrics aren’t going to move the needle. They initially thought they had to adjust their development based on the proposed marketing budget. After an infusion of capital and the hiring of a new head of marketing, however, they realized they had much more leeway.
They replaced the marketing metric with a survival metric focused on team connection by assessing how aligned the team is on the overall objective. If Bob felt alignment was off, then the team would need to adjust their communication plan. They also find that operations team is nervous about the AWS bill, so they added that to the list of survival metrics. They also found out the infrastructure bill was an issue after some development, and put it on the list as well.
Two weeks later, the retro provides the perfect time to do a survival metric retrospective on the last sprint.
Survival Metrics Retrospective
So, in the retro, we analyze what has happened, and we probably have to adjust to a new reality.
Retrospective exercises help your team make these adjustments by making reflection a regular part of the team’s routine. Instead of going with the plan, they have the opportunity to stop themselves and change by cobbling together action items. Because of that, the team gets to adjust over time.
You want to answer several critical questions with a survival metric retrospective, but the most important is this: “Are these metrics affecting our product development over time?”
Essentially, survival metrics are useless if they aren’t touching what really happens with product development. They are active metrics, designed to help change direction when things are happening. If you aren’t feeling the burn of the survival metrics, it is time to change direction. The workshop will help you to see how well they’re working.
The workshop works as follows:
- Check-in. Just like before, spend a few minutes getting everyone’s mental state coordinated and understood by asking, “How are you feeling?” Retros are a bit tougher than premortems since they generally come with more trepidation because we’re looking at work we’ve actually done instead of hypothetical situations.
- State the objective. You may ask why you need to do this again. Well, this is also a chance to make sure that the team understands what they are trying to do. It also gives you, the PdM, an opportunity to adjust your communication strategy. For the PdM reading this, any opportunity to repeat objectives is a good one because objectives have a short lifespan in a team’s mind.
- Consider. “How have these metrics affected our product development over time?” Go through the metrics one by one and ask how they affect development. If nothing is happening, get rid of it. Time for new metrics.
- Ask. What is actually affecting our product development? These answers are potential new metrics.
- Adjust. The facilitator works with the team to adjust. Sometimes there isn’t anything to change, but most of the time, there is. The important thing is to walk through your current metrics to see if they reflect reality.
Rachel’s team doesn’t do this type of evaluation and keeps the same metrics. As a result, the exercise becomes another useless concept that takes the team’s time for no reward. After two initiatives, survival metrics go into the dustbin.
After a few more cycles, Rachel and the team look at the feature’s usage numbers with shock. The numbers were nowhere near where they expected. The initiative also came in over budget. They didn’t adjust, and the team ended up losing long-term trust as Rachel had to explain the poor usage numbers.
Bob’s team takes this opportunity to change three more metrics. The team has a good hold on what’s useful and eventually stops the initiative. They saw the writing was on the wall. Since they were able to go through the retro process, they were able to speak to other parts of the business about why what they were building wasn’t effective. The team finds that what they have built will blow the budget out of the water, and since they were a cost-conscious company, raising this fact to leadership kept them from building something that wouldn’t be useful.
Over time, Bob’s team gained the trust of the whole organization. Bob eventually got promoted since he became known as the PdM that shipped all impact, no filler.
MORE IN PRODUCT MANAGEMENTHow to Rescue your MVP from Obsolescence
Don’t Fear Negative Loops
The negative loop is important because we have to respond.
Responding to change keeps strategy alive. Remember, as PdMs, our job is to raise the decision quality over time. We can’t do that if we aren’t adjusting to change in front of us. Leveraging negative feedback loops through premortems and survival metric retros from time to time take you away from the humdrum of following a plan to get closer to the dynamics of what is really happening.
-
What is product discovery?
Product discovery is a process typically undertaken by product teams, UI/UX researchers, UX designers, UI designers and company stakeholders.
Photo by Hudson Hintze on Unsplash The process is performed to define a problem, explore potential solutions and build a working prototype that will present value to customers. Modern product discovery and validation is essential to startup success, for example, those utilizing the outcome-driven innovation framework see an average product success rate of 86 percent.
What is discovery in product design?
- In order for a startup or an enterprise to achieve success, new products must be brought to the market that fill a consumer need. Uncovering what that need is and determining the most efficient way to provide a solution is what is known as product discovery.
Product discovery is typically undertaken by diverse teams of stakeholders from throughout an organization, such as product teams, UI/UX researchers, data analysts, product designers, executives and others who are closely aligned with customer needs and insights. This helps create a link between the customers and the business before any work is done, ensuring that the intended product will be useful and not fail due to a lack of adoption and users.
The roots of modern intentional product discovery and validation can be traced back to the 1990s, when Steve Blank created the customer development philosophy and published the book, The Four Steps to the Epiphany: Successful Strategies for Products that Win. Eventually, Blank’s methodology facilitated the start of the lean startup movement where customer development is considered a main pillar. Simultaneously, Anthony Ulwick developed CD-MAP, which would eventually set the course for the creation of outcome-driven innovation and the jobs-to-be-done theory.
What are the key elements of product discovery?
- A few key elements of product discovery include the journey map, empathy map and consumer persona.
When conducting product discovery, it is first important to ensure that empirical user research is done so qualitative and quantitative data can be gathered. This allows discovery teams to challenge their own assumptions about what a user needs and gather data on potential product use cases and customer pain points. From there, teams can form design artifacts that allow the data to stay top of mind and be easily referred back to throughout the discovery and development process. These artifacts often include journey maps, empathy maps and consumer personas.
Journey maps are a set of actions that the user is expected to take to achieve their goal. The actions taken are marked as “locations,” and the product is expected to reduce the amount of actions needed to accomplish the goal. Journey maps must be based on empirical user research to accurately determine what the product will accomplish. Empathy maps are a four-quadrant diagram that are used to record what customers think, hear, say and see in regards to their challenges and the product’s opportunities to present a solution. This helps companies understand user feelings on products and services. Consumer personas are an approximated segment of users that come to be known as target customers. Personas are named and matched with demographics, psychographics and behaviors that help identify a potential customer.
What are product discovery techniques?
- Techniques for product discovery include identifying risks, understanding underlying user needs and identifying the optimal solution.
Product discovery is all about identifying solutions to customer challenges. By doing so, companies seek to build products that provide continuous value to both the user and the business. This requires risks to be clearly identified before teams can begin building a prototype. These risks include: value risk, or whether customers will adopt the product; usability risk, or whether users will know how to utilize the product; feasibility risk, or whether it is capable to produce a product with the allotted time and resources; and business viability risk, or whether the solution will also work for other aspects of a business.
Once these risks are identified, stakeholders have a better understanding of user needs and can create an optimal solution through ideation, prototyping and testing processes.
-
As product manager, what story should you tell?
As product manager, how do you take your plans from theory to action? Simple: Tell the right story.
Photo by Jo Szczepanska on Unsplash 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.
Storytelling as Product Tool
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.
3 KEYS TO A GOOD STORY
- Lead With Social Proof.
- Repeat the Story.
- Iterate Within Your Culture
What Are Survival Metrics?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.
We Have the Metrics. Now What?
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.
Leading With Social Proof
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.
Repeating the Story
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.
Retrospect Into Evolution
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.
-
What do you do when product and customer success won’t play nice?
Too often, customer success and product teams treat each other like adversaries. Here’s how to fix that.
Photo by Clay Banks on Unsplash What kind of relationship do you have with your company’s customer success team? I often ask product teams this question, and the answer is usually that there isn’t a relationship at all. And if there is, it’s hanging on by a thread. The product team never connects with the customer success team except when it’s time for an “enablement” session. The session is designed to allow other teams to understand a product. This meeting, though, is likely to just be a quiet presentation and Q&A.
Meanwhile, the customer success team tends to see the product team as the product feature repository. They just drop off feature requests and then go back to their own work.
Both forms of communication are reactive. Customer success hands off customer problems with solutions and dates to the product team. The product team uses customer success as a shield against the customers themselves. Neither team leverages what the other knows to maximize their ability to collaborate on solving big customer problems and innovating in the marketplace.
But that dysfunction isn’t the most significant issue. The organization is building a culture of resentment. The teams will continue to resent one another until something changes. So, they’re losing in two ways. They lose the opportunity to leverage the intelligence of both teams, and, because of the resentment, the business misses out on some moonshots that could change its overall trajectory.
Before we talk about the tactics we can use to make things better, we first need to address that resentment. Remember, it’s the product manager’s (PdM) job to increase the overall decision fitness of the organization. By decision fitness, I simply mean how well the team makes decisions. Good product management leads teams to consistently make better decisions. You won’t be able to level up in this area if there are no clear lines of communication between customer support and product.
So, let’s talk about how you can identify some of the issues both teams have with each other, create more precise lines of communication, and tie it all to your culture so that it stands the test of time.
Identifying Issues
Your customer success team is likely the lowest paid and the least listened to team in the building. Their job is often a taxing one. It’s a matter of when and not if customers are going to yell at them. The customer success agent is on the front lines of frustration, listening to customers vent during their lowest moments of using the product.
Your job as a product leader is to take the opportunity to sit down with them and listen to what they have to say. If the poor relationship between teams that I described before sounds familiar, they will likely have a lot of valuable information to tell you.
Let’s set the stage with BobCo, where two leaders, Jill, the new director of product management, and Bob, the new director of customer success, are connecting for the first time. They plan to get the company on a better path and leverage each other’s team for better product outcomes.
Bob and Jill both took the time to listen to their teams for the first 90 days of their tenure. They also talked to other disciplines, like engineering and sales, to get a solid overview of the organization.
Both connected with a random distribution of people, taking advantage of their newness to the organization, and led one-on-one conversations with everyone on each team around three subjects.
3 GOALS FOR ONE-ON-ONES
- Establishing competence — “Here is who I am and what I’ve done.”
- Laying out their vision of the future — “This is what I want to do.”
- Building a bridge between the other team — “How can my team help yours?”
Replacing Resentment With Trust
Bob and Jill both know that the secret to identifying issues is to build trust. That trust must first start with themselves, so Bob and Jill spend time listening to each other and developing a shared vision of their futures.
They spend their first few conversations feeling each other out. Once they get to know each other a bit, they agree that a team conversation will give them a jump-start on understanding how product and customer success can work together.
How should they frame this conversation between the two teams? I’m a big fan of the team retro process laid out by NOBL.
A team retro gives the facilitator and the relevant team at least 60 minutes to get everything out on the table. Remember, the retro process isn’t about blame; it’s about level-setting and improving, so make sure you use your time together to get a clear lay of the land. In our example, both teams more than likely have some misconceptions about the work the other does. It’s finally time to clear them all up.
Both Bob and Jill are coming into teams that already exist. Like most of us, they have to deal with the culture that’s already there. In this case, it’s one that is marked by the resentment that I mentioned earlier.
Without presenting a solid foundation to both teams, one that establishes competence and tells a story that people can trust, and showing that they trust one another, they know this process can fall apart.
A team retrospective can raise issues that plague teams and businesses. Both leaders are committed to handling the pressing problems upfront, by writing them down and following up. They present regular status updates to ensure that no one had to work to find out what was happening. They also keep each other accountable by holding routine check-ins. All of these steps can go a long way to establishing trust.
Building Bridges
So, you’ve done the first team retrospective. Put the next one on the calendar in about a month. Keep this meeting a consistent part of both teams’ workflow. Every time each team talks, you’ll build more trust. But you’re not done there.
After the retro, Bob and Jill realize that just talking about the issues won’t be enough. Instead, they need to change how the teams communicate. This change means moving from a reactive approach (enablement and feature requests) to a more proactive one. Making this shift requires bringing both teams into regular contact during product development.
So, they pick one point during a sprint for the customer success team to meet with the entire product team to talk about development and see how customers may engage with the product as it’s being constructed.
This connection point helps the customer success team understand how to talk about the product with customers and get their insights. Because they now know how to frame these insights, the product team is more likely to receive this feedback instead of brushing it aside.
And this new structure leads to an important point. Customer success teams have a good understanding of the emotional state of reactive customers but aren’t always clear about the problem set of proactive customers.
Bringing the customer success team inside the process allows them to guide the product team in addressing the customers’ emotional needs as it’s building the product. For example, say you have a section of customers that are angry about your latest widget. The customer success team can take a look at the next iteration of the widget and tell you exactly what they are hearing, which will help the product development team avoid potential landmines.
Jill knows by bringing Bob and his team around in the middle of the process, the team can make sure they solve more pain points and build a better story to present to the customer. Bob knows by bringing Jill around, his team can frame customer requests more effectively.
Keep in mind that the PdM should under no circumstances consider this feedback qualitative research, however. The customer success team’s involvement isn’t a replacement for talking to customers. But it is a great way to make sure each team is making the most of one another’s expertise.
Be Transparent
Bob and Jill know that working together will lead to stronger teams, but they need to make sure they can keep it that way. After all, these are two teams that have had some contention before. Bob and Jill need to keep the newfound trust going.
The continuing retrospectives will help to identify any trouble between the teams as it happens. This relationship isn’t going to work like before, though, and change is fragile. So, leaders will have to talk often about both successes and failures. Transparency is the bedrock upon which you build trust.
You’ve already made some serious inroads if you’ve adopted the retros and invited customer success into the development process. The next step is to instill a culture of transparency.
Bob and Jill set up a report designed for the business; they call it the BobCo Product to Customer Report. Inside, they highlight anecdotes from customers and how the different product development teams are each building products that meet the needs of the customer. Those anecdotes fit the story the product team is trying to tell, and speak to how those customers will be affected by the change. They also include data about research, renewals, churn and team changes.
Are new hires coming in to shake things up? Is the team doing some tech debt initiatives that mean new features can’t happen right now? Are you holding office hours? All that information should go into the report. This report then goes to the rest of the business to build trust and allow them to keep an eye on the product strategy.
MORE IN PRODUCT MANAGEMENTWhat to Do When Product Theory Isn’t Your Product Reality
Get Everyone on the Same Page
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.
-
Helping product teams get better results by putting people first with adam thomas
How does the level of trust after a decision is made impact product teams (and other teams in your organization too)? How much waste might be happening in your organization because of cognitive biases and what are practical ways to avoid falling into the traps of these biases when it comes to decision making?
We explored these questions and many more with Adam Thomas, a product person and technologist based in Harlem, NY who is focused on strategy, team organization, and product management. Adam is currently the Lead Product Manager over at SmartRecruiters, a columnist at BuiltIn, and also shares weekly product management tips and other fun resources in his newsletter.
Adam believes that product management isn’t just about getting done what’s on the roadmap; it’s fundamentally about people. So he looks at things in a way that leverages behavioral science, psychology, philosophy, and more to build extraordinary teams that thoughtfully bake culture into what they are developing.
In this episode of the In Trust podcast, we talk to Adam about how he helps product teams get better results by putting people first. His practical perspectives and astute observations apply far beyond product management. Whether you’re a product person or a leader in a different domain, you’ll want to give this podcast a listen and take notes.
Overview of Episode 39: Helping Product Teams Get Better Results By Putting People First with Adam Thomas
Talking Points
- Adam’s posture and philosophy as a technologist and product person
- Why Adam rejects the box-checking, order-placing view of product management
- Adam explains something he calls product calculus
- Unpacking how trust comes into play specifically after decisions are made
- Why there has to be a trust in failure
- Why leaders can better serve their entire teams and their work by looking at work and culture through a lens of cultural anthropology
- Adam’s practical tips for leaders to study the culture that they are immersed in
- How sometimes one little push can change your entire organization
- The high tax that bias plays in the workplace and how it is a silent killer of teams, processes, and development
- The importance of conducting post-mortems on decision-making to understand how bias might have come into play
- How regular pre-mortems can help minimize the bias tax
- The importance of having a high cadence for company communications and how this can help bake in accountability into a workplace
- The importance of talking about both successes and failures
- How to reduce your chances of getting into trouble at work to nil
- Starting small and building the muscle to take bigger and bigger risks
- The basic thing you can do to have better meetings, more focused conversations, build trust, and other benefits
- Where to learn more about Adam and read, watch, and listen to his work
Quotables
“I’d like to get completely away from that, let’s just call it determined roadmap. That preordained idea that we have some understanding as to what the future looks like, and instead move towards a place where we heighten our communication and we heighten our understanding of, not just the infrastructure of the company or sales requests, but also the people inside of that company, in order to live in that ambiguity – live in the space of just the unknown that exists inside of building things and making things. Be honest with ourselves around the concept of what I like to call product calculus, the fact that we’re never reaching something. It’s never a determined place that we’re reaching. We’re always approaching something.” – Adam Thomas
“I’ve seen companies create these huge plans, the leadership team is aligned, they have a big party, everybody goes, ‘This is awesome. We’re gonna really kill it over the next year.’ And then afterwards, six months or a year later, all the competitive advantages they had are gone and they have a product that no one uses no one cares about. A lot of that falls squarely on the product team because they didn’t have the trust inside of the organization post these decisions in order for other folks to trust them enough to carry them out. So I think decision trust is a huge, huge, huge piece of what product folks do.” – Adam Thomas
“There has to be a trust in failure, because I have never seen someone make something right the first time. No matter how much information I’ve sent back and gathered, I’ve never done it right. I could sit back for a year and gather information and talk to customers and do this and do that and I’ve never been right just saying, ‘this is what we’ve made. Ta-dah!’ So there has to be a level of comfort in the failure of what you do because the failure is coming. How folks trust your ability to deal with that and then to take that as a learning lesson, as opposed to playing the shame and blame game, really affects your ability to build stuff. Not just once, but consistently throughout your tenure as a product person.” – Adam Thomas
“As a leader, you should constantly be studying the culture that you’re in.” – Adam Thomas
“One thing to change the world: sometimes it’s just one little push and you can change your entire organization.” – Adam Thomas
“If I were to sit back and look at your operating expenses as a business, and I would suggest shadow your teams for three to six months, I could probably put a percentage on how much waste is happening based on bias. My bet for a lot of companies is that waste is upwards of 20 to 30%…With cognitive bias, since it’s so subtle, it’s such a silent killer of teams, processes, and development. It’s something that goes underneath the radar.” – Adam Thomas
“If you are communicating clearly, and you are being thoughtful, and I can tell that you’re showing your work, the chances of you getting in trouble are practically nil. You would have to do something extremely diabolical and in bad faith. I think most places work that way, especially once you understand what is the level of work that you need to show and who you need to communicate with.” – Adam Thomas
Show Notes
- Adam’s website
- Adam’s newsletter
- Adam’s YouTube channel, Product & Life As Usual
- Adam’s film podcast that he co-hosts with Mtume Gant, Within Our Gates
- Final Account documentary film
- The Father feature film
This episode sponsored by:
The Future Is Trust
Embracing the Era of Trust-Centered Leadership
There’s a lot of uncertainty about the future, but one thing we are sure about is that The Future Is Trust. Which also happens to be the title of our forthcoming book.
The Future is Trust: Embracing the Era of Trust-Centered Leadership officially goes on sale on June 15, 2021
We are so excited to bring this reimagination of what a leadership book can be.
Check out thefutureistrust.com for book launch details, special previews, exclusive pre-order specials, and more.
-
Bluf your way to success – adam thomas on the product experience
BLUF Your Way to Success – Adam Thomas on The Product Experience
The one thing every product person needs is a new acronym that comes from the military, and Adam Thomas is here to help. Sarcasm aside, Adam’s made good use of the BLUF technique: Bottom Line Up Front, a short template, clearly laying out what the team is working on and how they plan to do it. He joined us for a chat about alignment, how this complements Mat LeMay’s One Page/One Hour approach, and why his template stretches onto a second page.
In this episode, sponsored by Amplitude,
- Everything you ever wanted to know about alignment
- The difference between Epics and Initiatives
Quote of the Episode
Any system starts to fall back into disorder given any amount of time, and alignment is prone to entropy like any other system.
- Follow Adam on Twitter, LinkedIn and YouTube
- Adam’s Website – and his new consultancy, Approaching One
- Initiative template for BLUF (Bottom Line Up Front)
- Product Work Beyond Product-Market Fit article
- Chris Butler – Your Strategy is Too Sacred article
- The Pyramid Principle – Barbara Minto
- John Cutler, Why Happier Autonomous Teams Use One-Pagers
- Matt LeMay on The Product Experience
- Seth Godin’s take on Thrashing
Get in Touch, Rate Us and More!
- Visit The Product Experience homepage for more information and more episodes!
- Know the perfect guest? Great! Suggest them here
- Chat to us on Twitter or in our dedicated Mind the Product #podcast Slack channel
- Review us on your podcast app so that we can use your feedback to be better
- Like our theme music? It’s Hamburg-based Pau, featuring ProductTank Hamburg’s Arne Kittler!
-
How to create a minimum viable product (without code!)
Photo by eniko kis on Unsplash “I have an idea.”
It’s the most dubious phrase that comes from our teams.
Why?
Because if they have enough pull, we can spend hours building an idea that makes sense to that person, or even internally, and do nothing to the marketplace.
I’ve seen it a ton of times in my career, someone swears they have a genius project, and bang, soon enough there is 300 hours into something that has a 2% usage rate.
Uh oh, and back to the drawing board.
As marketers, it is our job to understand the market and in some respects, save our teams from making the mistake of building what they swear is right when the market will eat it and spit it out.
That is where no code MVPs make sense.
Today, we are going to talk about what No Code MVPs are, how do you leverage them in the wild, and how to talk to teams to make sure you get to use it first.
What is a no-code MVP?
There are three things to consider when talking about a no-code MVP:
- No-Code means no code. You won’t be going to your engineers to build this thing, and to most folks, that is a huge win. You get to maintain control, learn more about your customers, and if successful, get some of the marketing out of the way before the feature launches.
- MVP is Minimum Viable Product – a LEAN concept that means the smallest thing you can get out the door. Some folks may quibble about what “viable” means in this context, however, the thing to take away here is that we are really trying to understand the viability of our hypothesis.
- Your hypothesis is what you want to learn. Everything you build should have a falsifiable hypothesis. This is important because you need to know when to move on.
Put them together, and you have a No-Code MVP.
Now, you need to build something that allows you to test your hypothesis. The simplest way I’ve seen this done is a landing page. These days, it seems like all email service providers have internal landing page creators, so pick yours and rock and roll.
The writing on the landing page, as well as any supporting documentation and materials (I like to write a fake blog post to help get my thoughts down) should focus on the hypothesis.
Leveraging the no-code MVP
Now, we’ve built something that collects emails. Who should we send them to?
It depends on your appetite for risk. If you like a controlled population, look at your “beta” users – these are folks that you or your team has already predetermined enjoy the cutting edge features. Set a success rate and go for it.
If you don’t have a population set aside, or you don’t mind spending some money, you can leverage Facebook.
Facebook has some great tools to create lookalike audiences, and if you are comfortable with them having that data, you can extract your customer list to build a lookalike audience that excludes your current customers. This method may be good if the something new is completely different than your current offering.
Now, it’s time to play the waiting game.
If you have success metrics set up, after a set amount of time, see if they match up. If they don’t you can feel comfortable that this isn’t something they want.
If they do, now it’s time to talk to these customers. Don’t know how? Well, I have another article for that right here that will help guide you.
Talking to your team
Now that you have the data you need, you’ll need to present to the team.
Talk to your stakeholders, present the data, and if this is the first time you’ve done this, take the time to tell them about the process.
Remember the why – your no-code MVP is designed to save other teams time and get them back to working on things that are impactful.
You’ll have plenty of data, from potential polling to quotes to help make a decision on whether to move on. Use it to sell your case to those stakeholders.
No Code is the Way To Go
With enough time in tech, you’ve sat in a room with a team that had a similar experience to thought exercise that led this article.
I haven’t met a professional yet that doesn’t like to have everything they work on sit on a shelf. No one likes to waste the money, momentum, and more importantly time it takes to get something out the door.
Leverage that No Code MVP to save your company time and money, and as a bonus, build some trust along the way.