Adam Thomas | Product Management Expert

Category: Product Strategy

  • An alive strategy vs. Dead strategy

    An alive strategy vs. Dead strategy

    grayscale photo of person holding glass
    Photo by GR Stocks on Unsplash

    Product Strategy is Important

    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.

    A Refresher of the Six Pillars of an Alive Product Strategy:

    1. A product must have a purpose.

    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. 

    2. Understand the customer’s 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. 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.

    3. Understand your value chain and how it’s evolving.

    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.

    4. Determine what change is likely to happen.

    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.

    5. Define actions against those changes.

    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.

    6. Measure success and course correct.

    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.

    About WistiaReport a problemCopy link and thumbnail

    Strategy Doesn’t Need to Just Exist

    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? 

    • Feeling unsure of what to do, even though the strategy is there.
    • Having a ton of distractions, even though the strategy is there.
    • Operating in the past, even though the strategy is there.

    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.” 

    An Alive Product Strategy

    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.

    Download The Product Strategy Playbook ➜

    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.

    A Dead Product Strategy Will Become 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.

    Download the Product Roadmap Strategy Workbook➜

    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.

    3 Ways to Identify a Dead Product Strategy

    1. Team members can’t remember what’s important.

    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.

    Download Practices and Processes for Effective Product Teams➜

    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.

    Simplify your strategy 

    The basis of strategy is here. You need to simplify. 

    • Evangelize. Become a broken record and talk about the strategy regularly. Remind people at the end of every team meeting of the important pillars of your strategy. When people start getting sick of hearing it, you’ve only begun.
    • Prioritize. Be clear about what is important, and get rid of the rest. Cut until it hurts – a strategy that doesn’t make any choices will atrophy.
    • Positivize. Remind people of the small wins regularly. Remember, teams think negative first, so overwhelm them with positivity. 

    2. Strategy incorporates incentives for all

    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.

    3. Strategy relies on consistent process

    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.

    Alive Product Strategy Starts with You

    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.

  • What Do Product Managers Produce?

    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?

    man in red and black crew neck t-shirt using silver macbook
    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 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.

    man in black suit standing beside woman in gray long sleeve shirt
    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 does a product manager actually do?

    What does a product manager actually do?

    Product management requires flexibility and adaptability in its practitioners. So, with so much nuance, how do we define what product managers actually do?

    man standing in front of group of men
    Photo by Austin Distel on Unsplash

    Product management (PdM) is a flexible discipline. It means different things to different people for a few reasons. 

    • Different organizations require their product teams to do different things. Sometimes you find yourself in an environment that appreciates SAFe while others are fully “Empowered” with everything in between as well. 
    • Your day is never the same twice. If I asked one PdM to list ten things they did this week and another one to do the same, the lists likely won’t match up, even if they’re both in the same organization.
    • There is no discrete output. Engineers produce code, designers produce experiences, and salespeople produce revenue. Product, however, can do any of these things, depending on the circumstances. 

    I could continue a list like this for quite some time. The theme would remain the same for each item on it, however: Product goes where it is needed. So, with so much variation in its day-to-day practices, how do we define, at a high level, the role of the product manager and the work it entails?

    After several years of doing the job, I’ve landed on the following definition: “Product managers should help their organizations make better decisions over time.” For us to support the teams that deliver the outputs that make companies successful, we have to take charge of improving the quality of decisions that everyone in the organization makes. 

    PdMs should spend time prioritizing issues based on business and technological need, and then come together with different parts of the company to solve those problems. This process becomes a cycle. The longer product people work in this cycle, the better and faster they get at understanding problems and using the right tools to solve them.

    In my article on survival metrics, I talked about the need for teams to be fast, data-informed, and politically safe, and I think these are three modes of operation that allow product managers to get comfortable with the change that comes with focusing on complex problems. Your job as a product manager relies on dealing with complexity, and your value to the business is in how you can help it navigate those decisions over time. 

    So, what constitutes fast, data-informed, and politically safe decision making? And how can you draw on these principles to remain flexible so that you and your organization consistently improve in the quality of your decisions?

    WHAT DOES A PRODUCT MANAGER DO?

    After several years of doing the job, I’ve landed on the following definition: “Product managers should help their organizations make better decisions over time.” For us to support the teams that deliver the outputs that make companies successful, we have to take charge of improving the quality of decisions that everyone in the organization makes. 

    Fast, Data-Informed, Politically Safe 

    Don’t think of the concepts fast, data-informed, and politically safe as having fixed definitions like everyday words do. When you incorporate them into your thinking, you’ll find that they’re flexible enough to fit several different situations. 

    So, what does each of these principles mean in practice?

    FAST 

    How might I increase the speed with which I make any necessary choices? In product development, and especially in agile product development, the shorter your decision cycle, the sooner you can adjust to the changes that dealing with complex problems necessitates.

    DATA-INFORMED  

    How might I improve how closely our team performs to reality instead of the ideal? Teams often make decisions in workshops or based on what comes from the boardroom rather than what’s really happening in the business and the marketplace. Better decision-making involves taking the influence that the stakeholders wield and pushing back with data based on reality. 

    POLITICALLY SAFE 

    How might I enhance the psychological safety of the team around me? When people feel heard, they feel safe, which means they’re willing and able to take risks. Political safety extends that concept to the team level so that teams feel better with interpersonal tension. As a product manager, the more trust you can foster across teams, the better the decisions you’ll all make. 

    Operating with these frameworks allows you to make better decisions over time. Think through some of your past decisions to see how you can improve your processes in these three ways. Doing so will help you define the role of a PdM to your team.

    The frameworks are important to lean on because you are going to be fighting a lot of fires. In fact, I’m sure your Slack is going off right now. 

    Fires, Fires Everywhere

    Put down your laptop. I’m sure no one is going to come around the corner and threaten you for not immediately answering that incoming Slack. 

    Why did I ask you to do this? You have to stop reacting. You need time to think. You need time to respond.

    Let me know if this sounds familiar to you:

    • Stakeholders are pounding on your door, demanding “innovation.”
    • Bugs threaten the viability of the next release.
    • Sales added something to the roadmap again.

    I bet you’re nodding your head. Well, sorry to break it to you, but this kind of adversity is the nature of the job. Product classes usually leave out that, although managing all of those things and more is important, your primary job is to facilitate better decision making. And this happens when you are able to respond rather than react. 

    Responding Versus Reacting

    Responding means that you’re thinking about the outcome you want instead of whatever is ahead of you. As a PdM, you must keep the outcome in mind so you can remain flexible and apply the fast, data-informed, and politically safe principles.  

    Let’s go a little deeper here. Imagine that we have two product managers, one named Jeff and the other Anna. They are both dealing with a push for innovation from leadership, a hyper bug tracker, and pressure from sales on the upcoming release. Everyone wants a meeting. Jeff says yes to them all and finds himself in meeting after meeting, dealing with every single one of those fires. 

    Anna pushes back on the request and promises a response in three hours. She then takes those hours, looks at all of the requests, sends some probing questions via Slack to those involved, and creates a list of tradeoffs and possible outcomes based on company strategy. 

    Who would make a better decision about what to do next: Jeff or Anna? The answer, I think, is clear. This hypothetical illustrates the difference between reacting and responding. Those that simply react will find themselves being output-driven. They can’t see past the next fire. Reactionary teams are always trying to figure out how to “launch” the next thing. 

    By contrast, those that respond are able to take a step back and adjust to the entire picture. They’re able to communicate in a data-informed way that helps teams gain trust in one another. Responsive teams are focused on the “why” behind the outcome. Those responsive teams focus on the big picture since they spend time thinking about strategy. 

    How does this make a team faster? Well, PdMs who take time to think before they act understand the priorities of the business better. So, once they have a better grip on what’s important, they can ultimately move faster without getting bogged down in details.

    MORE IN PRODUCTHow to Survive a Crisis, According to Eventbrite’s CPO

    Remember That You Do a Lot

    A lot of your work happens in the background. There isn’t a day-to-day PdM map to follow. Because of that, this job gets frustrating. Moreover, proving impact is hard since a lot of your time can be devoured by people asking you to put out their fires. Creating the space to respond is incredibly important to help you improve the decision making in your company. 

    That said, implementing this kind of culture is also the most rewarding part of the job. Helping teams dig through ambiguity is the essence of product management. Making sure everyone is making better decisions shows up not just in the releases, but the overall efficacy of the company.

  • What is product discovery?

    What is product discovery?

    Product discovery is a process typically undertaken by product teams, UI/UX researchers, UX designers, UI designers and company stakeholders.

    person holding ball
    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.

  • How to conduct better product management interviews

    How to conduct better product management interviews

    Hiring is one of the most important parts of product leadership. Use these principles to make sure you’re landing the best talent.

    three women sitting beside table
    Photo by Tim Gouw on Unsplash

    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?

    Free Toolkit: Successfully Onboard Remote Employees

    Download this remote onboarding toolkit to access actionable resources you can implement and see the impact of immediately.

    DOWNLOAD NOW

    Hiring Pitfalls

    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.

    3 STEPS TO BETTER HIRING

    1. Focus on the problem you’re solving.
    2. Craft good questions.
    3. Allot the proper time.

    Focus on the Problem You’re Solving

    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. 

    What Questions Should You Ask?

    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:

    • Tell me a story about X on your resume.
    • What was the hard part about making X real?
    • How did you convince opposing forces about X to make it work?

    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.

    How Much Time Do You Have?

    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.

    Free E-Book: Core Values in the Workplace

    How to create core values that will inspire your workforce.

    DOWNLOAD HERE

    Hiring People Is Hard

    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.

  • As product manager, what story should you tell?

    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.

    sticky notes on corkboard
    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.

  • Why projections fail — and what to do instead

    Why projections fail — and what to do instead

    Projections are useful because they give the rest of the organization a concrete idea of what you’re working on. Unfortunately, they can also set unclear expectations and raise questions that go unanswered. But a better tool exists.

    text
    Photo by David Pupăză on Unsplash

    We don’t know what is going to happen.

    Let me repeat it.

    We don’t know what is going to happen. 

    So, why do product managers (PdMs) plan as if we do when it comes to our strategy documents? In a previous article, I mentioned the trap that most roadmaps fall into. They give the rest of the company a time, date and feature. The plan usually ends up disappointing the business as a whole, though, as the date and time must often be moved, and after release, the feature doesn’t perform as promised. 

    The way to step out of this trap is to acknowledge the ambiguity of product management and tie the outputs, like that roadmap, to the outcomes you want. Turn the phrase “We will build feature X” into the goal, “We want to drive our customers to do Y.” When you do so, you train the business to give product development the flexibility it needs to solve problems instead of just delivering software.

    PdM’s affect the decision fitness of a company. If we were simply keepers of the roadmap, the job would be simple enough. The thing is, we aren’t. And roadmaps aren’t the only place where PdM’s fall into this trap.

    Let’s take it up a level. Managing strategy means we have to work on the way it’s communicated throughout the organization. Unfortunately, when product managers talk about strategy and explain where the business is going, we can fall into the same trap we do with roadmaps. We tell the company that we have a projection for the next few quarters. When we say this, we then watch the brows unfurrow, safe in the knowledge we get to live to fight another day.

    So, this all sounds like a win, right? Well, projections are great until they aren’t. They’re susceptible to the same problems as feature-based roadmaps. You’re selling a one-way trip to the future, except you aren’t Doc Brown. It’s not a matter of if you’ll blow up, but when. And although one or two small explosions may not make people freak out, do it enough, and at best you’ll sideline the product team. At worst, you (and maybe your whole team) will be tightening up your resumes. 

    So, let’s talk about how to keep the positive aspects of a projection while giving yourself the flexibility to shift when you need to. 

    SCENARIO PLANNING

    In product management, scenario planning is a way to address the shortcomings of simple projection. It presents multiple possible futures for a business and invites stakeholders to participate more fully in the product team’s strategy. Scenario planning involves making various assumptions about what the future will hold and how your environment will change over time. You lay out the scenarios that could happen, the risk/likelihood of each one happening and what factors can trigger them. 

    So, What’s the Alternative?

    Let’s go back to product calculus. 

    Remember that we have to respect the ambiguity of product management. I still haven’t found the person who was right on the first, well, anything: not on the first piece of research, software package or product roadmap. Any solutions that end up working long-term may have the right general idea upfront but usually require some iteration to be perfected.

    The problem with using a projection is that it only gives you one shot to get things right. Much like a roadmap, as much as we tell ourselves that we’ll be able to make changes, once we put a projection out there, changing it is virtually impossible. What you say gets disseminated throughout the organization, and people play telephone. Once it’s out, you can’t put the genie back in the bottle. 

    So, why not just ditch projections altogether? Well, not having one is even worse: The rest of the organization doesn’t know what you’re thinking. If they can’t see anything coming from your team, there’s a slim chance that they’ll actually use your strategy.

    If projections turn into traps, but we still need them, then what’s the best way forward? The answer is scenario planning. 

    Scenario planning involves making various assumptions about what the future will hold and how your environment will change over time. You lay out the scenarios that could happen, the risk/likelihood of each one happening and what factors can trigger them. 

    The Ups and Downs of Projections

    Projections are popular because they give organizations a vision of the future that’s tangible, future-forward and trackable. Those are positive qualities that you’ll want to retain in your shift to scenario planning, so let’s take a look at what that entails and the associated problems. 

    TANGIBLE

    Getting everyone in the company to read your strategy is a difficult task. As much work as you do to get people to engage with it, they often don’t. That means you need something concrete that will stick in people’s minds, even when the strategy document itself doesn’t land with the audience. 

    Projections are a great way to do just that because they give teams an easily summed up idea. It’s one point, and you can pop it on a slide and then go to sleep. Unfortunately, that simplicity is a trap. All it takes is a few slips of that projection, and people start to tune you out.

    FUTURE-FORWARD

    You need to show everyone that you’re looking to the future. Owning the decision fitness of the company is always forward-looking, even if we need to research the past heavily to get better at looking into the future.

    When you make a projection, you tell a story that sheds light on a particular future, but it hides many things that build to that future. You end up unintentionally obscuring the risks.

    TRACKABLE

    How do you know what’s changing in the market, the customer base or even the company itself? Projections provide something you can go back to in order to get an idea of what has changed.

    The problem is that you usually only get to pick one, and unless you pick well, you are hiding too much complexity. By showing only one metric or idea, you obscure the path it took to get there and increase the risk of outright failure. The right metric can lead people in the right direction, but unless you are an expert and know the domain and customer in an otherworldly fashion, you are going to get this wrong eventually. 

    Now, let’s make this real by looking at a projection-based organization versus a scenario-based one. 

    Projecting Into the Future

    Let’s take a look at the company BobCo, looking to plan its second half of the year. The business is looking at product development and is focused on getting the outcome they need. 

    So, their head of product, Keith, decides to make a projection.

    Before he creates the projection, he first does all the necessary leg work. He contacts different groups to get their perspectives, digs into the market intelligence and talks to the executive teams to get an idea of where they think the vision needs to go.

    He sits down and, keeping his eye toward the future, makes a slide deck to show the company leaders at the next all-hands. The deck outlines the projections for the next quarter for product development, how they tie to the strategy and what that means for the future.

    So, he goes through the slides and carefully details all the important factors in the projection. He includes the risks the team faces and the markers they need to hit to make their targets. With that said, he puts a single goal on the screen.

    “We will reduce churn by 1.5 percent over the next two quarters.”

    Everyone applauds, because they feel like they knew where they’re going now. The projection works.

    Except.

    Once the meeting is over and the leaders return to their individual teams, they only remember one thing: the churn rate. Everyone thinks, “Oh good, product is going to reduce the churn rate.” Nobody sees the role they have to play here. They see this metric as a promise rather than a goal.

    To everyone in the meeting, the churn rate became tangible. But they didn’t remember the risks that were associated with making that goal. You see, that was just another slide on the way to the projection. As a result, the risks were obscured. Same thing with the larger story Keith told; it was just in service of that 1.5 percent metric. All the associated opportunities were lost as well. 

    Teams don’t know what they need to do, or even how to understand what keeps them off target. They can’t imagine any alternatives, or track any of the changes that might happen.

    When teams aren’t aligned with the strategy, you’ll find that when they run into roadblocks, they’ll just guess about their next step. Those guesses vary wildly and can end up slowing down or, even worse, reversing progress.

    So, while the team had some alignment around the ultimate target, by the time Q4 ended, they found themselves only a third of the way there. Everyone then wonders what they could have done differently and when.
     

    Planning Scenarios

    Let’s take a look at BobCo a year later. They’ve decided to scrap the projection approach because it didn’t work last year. They also didn’t understand why they weren’t able to communicate when things broke down. 

    The company needs flexibility. So, instead of projection, Keith chooses scenario planning. 

    Not surprisingly, the company has the same goal as before: to reduce churn.

    Keith prepares the same way he did last year. He talks to everyone and gets their thoughts down. He includes the tangible anecdotes, the items that are future-forward and figures out how to track everything. 

    Where he changes his approach is in how he outlines the slides and the assets he produces. Before, the presentation built up entirely to the big finale: “Reduce churn by 1.5 percent.”  This time, though, he wants to bake in flexibility by clearly tying the outcome to a set of conditionals. His slide now says the following: 

    “We’re going reduce churn by 1.5 percent by the end of Q4 IF”

    • The market trends continue as marketing predicts, letting us activate more customers.
    • Our engineering team has the freedom to leverage outside resources to build better.
    • HR consistently grows the headcount at the pace they’ve done for the last few quarters to continue a fresh influx of ideas.

    The “IF” is important, as it invites people to be active participants in the plan instead of passive listeners. Now, their brains are moving. They can see that the goal isn’t guaranteed after all. 

    The job isn’t over, however. He goes on to add a bit more context to those three bullet points.

    OPPORTUNITIES

    • The market trends continue to jump by 10 percent as marketing predicts, letting us activate more customers than last quarter by 15 percent to keep up with our place in the market, AND
    • Our engineering team has the freedom to leverage outside resources by bringing in a consulting team for less than 2 percent of potential profit to build better projects that will increase our upsells by 15 percent,  AND
    • HR consistently grows the headcount at the pace they’ve done, maintaining our hiring targets at an 80 percent hit rate for the last few quarters to continue a fresh influx of ideas.

    THEN we will reduce churn by 1.5 percent.

    The AND establishes a story here. Whose roles are important? Well, the company now knows what product needs from marketing, engineering and HR. This is already more useful than just a statement about reducing churn. 

    These AND statements also set the stakes. If the company can’t do all three of these things, well, product isn’t going to hit the churn numbers.

    So, what happens then? Keith’s presentation also lays that out:

    “If we don’t hit our targets, we will”

    • If we run into issues in marketing, engineering or HR, and we can’t recover by week three of Q3, we will revise our churn number to 1.25 percent and adjust our internal messaging. 
    • If it is past week three of Q3, and we revise the churn target, we will shift to our secondary target, increasing pricing to adjust for our loss. In this case, we will shift our teams and provide more support to marketing and pricing.
    • If we are failing with all three requirements, we will stop everything and reconvene to stop the bleeding. Our teams will be made aware, and we will call a town hall immediately. 

    With these statements, what was fuzzy before is now tangible, future-forward and trackable. Even better, Keith has added flexibility with the next step predetermined in each case to keep everyone moving forward.

    At the end of the quarter, the team ended up shifting to pricing. They’re able to do a proper post mortem to find out that the churn target was too ambitious for several reasons. The next time they do scenario planning, they’ll be able to iterate and get even more precise. 

    Use Scenario Planning

    Strategy is complicated and ever-changing. We need tools that can help us make the most of the time we have with our teams and equip them to do practical work.

    Projections are tangible, future-forward and trackable, but they come loaded with risk. Derisk them by switching into a scenario planning model. Not only will you get the same benefits, but you’ll also train the organization to think about what-ifs and be more open to the ambiguity that comes with product management.

  • You need to know when to fire a customer

    You need to know when to fire a customer

    We work so hard to build a customer base that we despair at the thought of ever losing one. But sometimes, your relationship has run its course, and it’s smarter to let them go.

    red fire digital wallpaper
    Photo by Cullan Smith on Unsplash

    hen you build a product, you work so hard to attract those first customers. Cracking into a marketplace is difficult, and even when they have one foot in the door, it’s hard to keep them. Figuring out how to attract and retain customers consumes a huge amount of our time in the product world.

    That being said, you also need to learn how to fire them.

    I can already hear the objections: “Fire them? What about that hard work?”

    Well, for your business to accomplish its mission, learning when and how to fire customers is a key skill. The truth is that both the business and its customers change over time. Sometimes, that change means that the partnership between the two has run its course. When this happens, you have a choice. Either you recognize the time has come and help that customer get to where they need to go, or you try to hold on, kicking and screaming.

    Let’s eliminate the second option right now. Trying to keep your customers while they are kicking and screaming will leave scars. The effort, like blindly answering and accepting feature requests or requests for proposals (RFPs), to keep them is going to drain both you and your company. The cost is significant, causing companies to lose resources, headspace and may eventually move you away from your mission.

    One day, you’ll look up and be unable to recognize your own company. If you’re a mission-focused company, then that type of change is non-negotiable. Keeping customers isn’t worth giving up on your original vision.

    To avoid letting this happen, you have to be willing to fire customers. You need to do two things to fire them effectively:

    1. Identify customers that don’t fit your point of view.
       
    2. Send them on their way with some kindness and grace.

    As leaders, and especially those of us who are mission-driven, we must be able to identify and part with those customers who no longer serve us well. Not only does doing so enable us to lead with razor focus, but it also helps signal to our colleagues that we are committed to the work itself.

    In this article, I want to point out how you can identify customers who aren’t aligned with your mission. I will also address some ways to end the relationship without burning bridges permanently. Although some of these things are counterintuitive, they’re all designed to make sure that you, as a leader, are staying focused on what’s most important to your business.

    Identify Customers That Don’t Fit

    Earning that first dollar is challenging for a business, and keeping it is even harder. For founders especially, these dollars are an affirmation that your vision is viable, and every customer that you gain feels like a success.

    Once you’ve got a sizable customer base, the job turns from just acquiring any customers to acquiring the right customer. I understand that the word right is doing a lot there, so let’s break it down.

    The right customer is the one that fits your mission and vision. You solve a problem for them, so they’re willing to pay you for that solution. They’re excited to grow with you. These criteria may seem simple, but they don’t describe every customer that you have. Some are neutral, and some are actually the wrong customers.

    Neutral customers aren’t enthusiastic supporters of your brand, but they’re comfortable enough with your service. They tend to slip in and out out of your revenue stream. They may eventually turn into the right customer and discover a passion for your product. Crucially, though, their indifference means that they don’t put pressure on you to change like wrong ones will.

    Wrong customers want your company to do one of two things:

    1. Go backward. The folks who push you in this direction are most likely older customers who joined when you first started. They liked your product in its early stages but don’t like what you’re doing now or where your product is headed. You’ll notice this customer talking about the old days a lot.
       
    2. Change your mission. This group is likely to talk to you about everything except what your product is trying to do. Get ready for feature requests that overwhelm your team, tickets for your customer success operators that are far removed from your use cases and plenty of other distractions.

    These groups are not mutually exclusive either. The person who wants to go backward can also push your team to go in another new, unnecessary direction too. Either way, the result is bad for your company. Going backward is as bad as spending time trying to accommodate every single request you see, no matter how small. Both strategies will put you out of the game.

    Identifying these customers is important so that you can make your offloading process clear. Build a profile of a hypothetical problem customer so that you can identify red flag behaviors. Some things to look out for are improper or inactive feature use or a customer that complains often and contributes little to the bottom line.

    You can set up user personae and include one for the problem customer. These personae, once uncovered, should be referenced with the customer experience team (customer success, customer support, support engineers, internal product and design) often to adjust and iterate as the mission changes.

    Segmenting your customers will help you get a better handle on how to serve them all.

    Helping People Move On

    Now you have a good idea of how to identify those customers who don’t align with your vision. Once you’ve determined this, it’s critical that you transition them to someone who will provide a better fit. So, how do you help them move on?

    Let’s start with what you shouldn’t do — just dump them. These customers, whether ideal or not, have shown you the respect of paying for your services or products. They put their faith in you, and even if they’re no longer a match for your business, dumping them either explicitly (by just cutting them off) or implicitly (by ignoring them) is a bad idea. Not only is it rude to treat someone this way, but you’re also running the risk of damaging your brand’s reputation.

    So, what should you do? First, you need to understand them. Then, you shift those customers to their next place rather than unceremoniously dumping them.

    UNDERSTANDING

    Now that we know who these customers are, it’s worth understanding just how the relationship got to this place. This is counterintuitive because we’re often just focused on engaging with the customers that are the best fit for our product. Nevertheless, we can learn a lot from a disaffected customer.

    There is more than likely messaging on your platform or marketing that speaks to the customers that didn’t fit. Asking these customers questions over the phone or by survey like “What confused or frustrated you?” will give you a hint as to what made them think that your product solved their problem. You now know what to remove in order to avoid attracting this type of customer. The data you get from the customer, whether from surveys or phone calls, will also give you some insight into the next step.

    SHIFTING

    The customers have told you what they’re looking for. Now, it’s part of your job to find out where to direct them. There are competitors (yes — your competitors) that may fit their needs better. You may also be able to recommend a solution that won’t charge them. Moving those customers to other places in your niche has two effects.

    First, it strengthens your standing in the marketplace by focusing on just the customers that work for you and your business. Second, you can start to divert them before and during the onboarding process to avoid the trouble these customers can cause down the road.

    Not all customers are for you, but that doesn’t mean you should abandon them altogether. Pointing customers who no longer fit your brand to a competitor who might makes you a leader in your space and improves your influence, strengthening the overall ecosystem. Don’t downplay the long-term benefits of doing so, either. Your competitor can become your greatest partner as the seas change.

    The same goes for moving the customer off of your platform to something free. You’re building trust with that customer that may pay off big time in the future. Even as they’re leaving your service, they’re likely to remain an evangelist for your brand. Plus, getting these customers out of your pipeline frees space for the ones you need to pay attention to.

    Fire Customers With Respect

    These aren’t one-time actions. Identifying and moving those customers should be a continuous process. Every time you make space for the right customers, you are on the path to growth.

    I know it’s hard, as the customers who started with us or the ones we’ve gained along the way are important to us. They trusted us. That being said, it’s worth returning the favor by helping them continue on their journey.

  • How good product strategy makes decisions easier

    How good product strategy makes decisions easier

    Product development requires a team to make a host of decisions. Your strategy should make that decision-making process as easy as possible.

    man wearing gray polo shirt beside dry-erase board
    Photo by Kaleidico on Unsplash

    Product strategy is hard.

    And let’s be clear: it should be. It’s a messy world out there, and strategy is all about trying to bring some order to that chaos.

    Like many things, though, the difficulty of the project doesn’t negate its importance. No matter how hard strategy is, you still need one. And the inputs that go into product strategy, from how your company is positioned in the market, to its current financial solvency, to the resources you have to allocate, to any number of other things that provide a cavalcade of options to align the company with your customers’ wants and the direction of your leadership. With so many different ways to go, how do you know if you’re doing it right?

    How well the product performs based on market projections is often how an organization as a whole grades product. This performance is our responsibility, especially since product managers are usually either making, advocating or evangelizing the decisions that affected it. Accordingly, the best companies judge product leaders based on their ability to understand which inputs are important, manage them, and craft a strategy that ultimately brings the ideas to life successfully in the marketplace.

    That organizational adjudication is all well and good. After all, good market performance is what the company wants out of a product. But it raises the question of how you should judge your own or your team’s product strategy on a granular level.

    Well, like most aspects of product management, it depends. Every team is different, which means each one will require different metrics for grading its work. I don’t promise a silver bullet for this problem, but as a product person, you should be used to that by now.

    What I can offer instead is a couple of key ingredients to any grading rubric. Effective product strategy lowers decision fatigue while simultaneously increasing team flexibility by providing psychological safety around decision-making. You need to think about how well your strategy does that. So let’s talk about it.

    RELATED READING5 Ways to Become a More Effective Product Manager

    WHAT IS DECISION FATIGUE?

    Every decision we make tires us mentally. Decision fatigue, then, refers to the tendency of our decision-making ability to deteriorate in quality over the course of a long session. This phenomenon should remain top-of-mind for product managers. After all, what is product development but a bunch of decisions we make in order to improve the probability of launching a successful product?

    Every decision we make has a cost. And that’s true not just of our decisions, but those of our teammates as well. Each time the team picks a particular course of action, the next decision becomes harder to make and is likelier to be flawed. This process is heightened every time we struggle with a particular decision. The more work you have to do to decide, the more fatigued you get.


    PRODUCT STRATEGY SHOULD MAKE DECISION-MAKING EASIER

    Now that we’ve explored decision fatigue, let’s talk about the role of product strategy and how it helps teams stay focused.

    Product strategy takes many forms. If you’re in a highly competitive industry, it could have guidelines on how you’ll attack the competitors. If you’re focused on growth, it’ll detail ways to get there. If you’re technology-driven, you’ll look for places where your technology will be more effective. So the particulars of your strategy will change based on your market and your goals.

    What doesn’t change, however, is that when a person is on the strategy team, they need to feel comfortable making a decision. Feeling unsafe is a drain on your internal energy reserves. We’ve all felt how bad leadership and unnecessary ambiguity take their toll on our ability to make rational decisions and produce consistent business results. Psychological safety is a good bulwark against decision fatigue.

    Your job as a product manager is to raise psychological safety by giving your people good product strategy. This means being as clear as possible about everything you can. Your strategy should clearly communicate the assets that the team has to work with, the boundaries that exist, and provide some narrative that team members can use to assist them with decision-making.

    For example, let’s say I’m creating the strategy for an innovation team. I want my document to list assets such as the number of hours allocated to different disciplines within the project. I also need to alert the team to boundaries they face, like which tools and technologies are off the table. Finally, I need to tell the team about any narrative that should guide their work, such as the company’s target of raising revenue by 5 percent. The strategy lays all this information out in one place for easy access.

    A good strategy gives a team concrete guidelines within which to operate. A team that doesn’t have to think about where they need to start or what might be off-limits is a team that can focus directly on the problem at hand. If your product strategy doesn’t provide enough background to help them make decisions, you’ll find that they either:

    1. Make decisions that may not be the best ideas for the company at the time, or
       
    2. Don’t decide on anything at all.

    Tack onto this the fact that teams can and will do both of these things in the process of a project. Worse, they’ll do them with little to no consistency, making it hard to predict which mistake you’ll have to confront. All of this means it’s a matter of time until the team zigs when it should zag, especially as decision fatigue sets in.

    Let’s be clear here, there is a difference between being descriptive and prescriptive. Good strategy is the former, not the latter. We use strategy to help teams understand what the world is, not exactly what to do. That’s why providing safety by giving the team context to make decisions is so important. When they feel safe, not only will they deliver more consistent outcomes, but you’ll also find they operate with more creativity as well. When team members feel that they’re not in danger of making mistakes, they feel more freedom to experiment and engage their creativity.

    In short, a good product strategy is a document that reduces uncertainty and the overall number of decisions that must be made while also providing cover for those decisions. Your team should be able to take a look at your strategy and feel comfortable that following it leads to fewer headaches down the road.

    TESTING YOUR STRATEGY

    Let’s say you have a product strategy that’s ready. Your leadership team thinks that it will lower decision fatigue and empower people to make decisions. At this point, you should ask some questions to sharpen it up. Note that these can go too far, though, and balance is important.

    Is my product strategy reducing the number of decisions my teams are making?

    The best way to lower fatigue is to cut down on the number of “boring” decisions your team makes. Your strategy and the accompanying artifacts (design systems, roadmaps, etc.) should help people narrow the possible choices and paperwork involved in any decision so that they can focus on what really matters.

    If you overdo things here, though, you’ll find that teams become robotic because they will wait for top-down direction on every subject. This kind of decisional paralysis is particularly bad for teams in complex environments, like innovation teams, who need extra flexibility since they run into failure so often.

    Is my product strategy lowering the context needed to make decisions?

    Another way to combat fatigue is to limit the amount of information someone needs to make a decision. Your strategy should identify which decisions are negotiable (i.e., what technology to use) and which are non-negotiable (i.e., if you have a limited budget). The accompanying artifacts (epics, initiatives, etc.) should reinforce which items are non-negotiable by using active, clear language. Avoid fluff.

    Remember, it’s important to not fall into the trap of being prescriptive. Product strategy describes the world; it doesn’t prescribe which actions to take.

    Is my product strategy making it safer to make decisions?

    Product strategy should raise psychological safety by providing protection for front-line employees making decisions. Your accompanying artifacts (team charters, value docs, etc.) will enforce what is “right” by giving teams insight into what leadership and other stakeholders define as good work.

    Don’t fall into the trap of overgeneralizing here, as you’ll then run headfirst into “toxic positivity culture” and people will be afraid to criticize anything at all. If everything is good, nothing is good. Standards matter.

    Overall, you should focus on making sure your product strategy is helping your product teams work to reduce decision fatigue without reducing the quality of people’s decisions. Good product strategy is designed to make sure that your teams are all rowing together to improve the probability of good decisions. Eventually, that leads to good customers and a great business.

  • Beware the tyranny of customer feedback

    Beware the tyranny of customer feedback

    man in grey crew-neck t-shirt smiling to woman on counter
    Photo by Clay Banks on Unsplash

    The customer is always right – right?

    This adage – one that many of us grew up with – is a guiding principle of product development. If we can just listen to the customer – if we just give them what we want, our path to product success can’t be too far off.

    Isn’t that customer obsession? Wasn’t Amazon where it needed to be? Well, no.

    In fact, quite the opposite. Just blindly listening to customers is a surefire path to stay mediocre, or worse. It holds you hostage, forcing you to follow through on these blind promises you’ve made and, if you succeed, you end up with a bloated product. If you fail… well, goodbye trust.

    Using open feedback systems, driven by customer desire, is not customer obsession. It’s customer abdication, and it holds you back from being clear-eyed about the decisions you will eventually make when doing customer development. Here is why:

    • The Ferrari Problem – customers want eye candy and aren’t thinking about how you’ll need to maintain it, or if it matters.
    • Customers have no context – they don’t know their market and live in a completely different world than you do.
    • Maintenance – systems which are open-to and guided-by customer feedback tend to need high maintenance to keep them useful. What tradeoffs are you willing to make to add confidence to the system?

    Let’s explore these problems in-depth, and talk about how to avoid these problems with tools and concepts that are more likely to bring you better outcomes for your product development.

    Vroom Vroom, I Want a Ferrari

    If I offered you a Ferrari, would you take it? Sure you would.

    Now let’s talk about maintaining the car.

    • Your oil changes are now specialized and cost 10 to 20x what they cost now
    • Any part is now specialized and you’ll need to find a specific mechanic with a smaller margin of error
    • Good luck finding the right gas station

    Did any of this come to mind during the offer? My guess is: no, it doesn’t. My bet is even if you got a Ferrari, you wouldn’t use it. This is what I call the Ferrari problem – when we, as human beings, consider only the “thing” we’re acquiring, and not anything around it.

    Your customers are human beings.  I repeat, they are human. They will spend time telling you about how much they want a feature… and then they’ll never use it. They just wanted it because they thought it’s cool.

    How do you avoid this?

    Focus on the problems – customers are well aware of the problems they need solved. They are your best source.  

    Contextless Customers

    You are probably looking at this on a phone or laptop. If I asked you about the microchip market, you might be able to answer. Let’s ask a few more questions:

    • How about the supply chain?
    • What about the other choices on the market?
    • How about any of the trade-offs necessary to ship this device?

    I don’t expect you to be able to answer these questions unless you are a product manager from a company like Lenovo or Apple, and work in their hardware division.

    You are a customer.

    Now think about your company – my guess is that you are able to answer these questions pretty easily, but your customers can’t. Every time a customer requests something, they don’t ever have this context in mind. In fact, they are just thinking about the problem.

    Instead of just expecting them to tell you what they want, ask them about the world around them. Ask them to tell you stories about how they interact with the product.

    Open System, Open Problems

    I once built a Content Management System (CMS) when I was younger (I am aging myself 😉) and, to my surprise, it worked. The little marvel allowed me to start my first company, The Gamer Studio, and bring on writers to start publishing content.

    So I opened it up to feedback and feature requests, provisioned some usernames and passwords and I thought I was on my way… until it happened.

    The first incident about corrupted data. Then the next, and suddenly it was a hack here, a hack there. For all the my openness to user feedback and feature requests had been well intentioned – after all, I just wanted to build the best product for my users – the reality was that it had led me down a path of feature bloat, technical debt, and a code-base that I had no hope of maintaining.

    I eventually had to shelve it and do the hard work of manually transferring everything to Typepad. Sure, I made a system and opened it up to customer feedback, but I didn’t consider the maintenance costs I was also opening myself up to. I often see the same thing whenever a product team starts using a live “customer voting platform”.

    These are open to all types of influences that run counter to your goal – for example, what happens when there is a voting “brigade” being led a single customer with a disproportionate amount of influence? Or a particularly nefarious competitor looking to skew your insights and roadmap?

    Not only that, but you also fall into the trap of other parties, both external and internally, deciding your priorities based on bad or irrelevant metrics. For example, stakeholders in other teams or organisations using non-significant (or even, strictly speaking, irrelevant) vote counts to push an agenda. A CEO running a meeting and saying “It’s the top-rated feature request” when it has 17 votes has a particular sting to it.

    Instead of voting on features, if you need to have customers vote on anything, let them vote and comment on problems. Put this at the beginning of your discovery process to help shape your research.

    The Theme Remains: Focus on Problems.

    Customers are a fantastic resource to understand (valuable) problems. However, defining solutions is where we run into more troublesome problems.

    Take the solutions out of your customers’ hands, and give that responsibility back to your team.

  • What is good documentation, anyway?

    What is good documentation, anyway?

    man in black t-shirt holding black dslr camera
    Photo by KAL VISUALS on Unsplash

    Is anyone reading what you are writing?

    This is a serious question and one you should be asking yourself regarding documentation.

    As product people, we act as the keepers of documentation throughout every stage of the product development process. We didn’t ask for the role, but since product’s principal job is to foster alignment, it’s in every product manager’s best interest to advocate for best practices surrounding documentation.

    Documentation is one of the best tools for maintaining long-term alignment and serves as a heuristic to see how the team’s communication holds up. It is one of the few artifacts that weaves its way through the entire product development cycle — even before a single line of code is written. And after a product ships, it becomes critical for engineers and customer support teams.

    The perils of poor documentation

    Without documentation, our teams end up making decisions that aren’t aligned.  While this might not affect the product today, you can rest assured that you’ll lose a lot of sleep trying to get them back on track tomorrow. 

    Those of us who have been around long enough have a story or two in which great documentation saved a launch, a product, or even a company. On the flip side, there are plenty of stories where a few sentences would have saved weeks or even months of work. 

    Unfortunately, documentation isn’t sexy. Although it mitigates disaster, it does so quietly. As a result, it’s easy to forget about documentation or even complain that it is “useless.”As a mentor once told me, “No one loves the janitor, even though they prevent catastrophe since it happens in the background.” 

    One day, it will be 3:00 a.m. and the world will be watching. In that moment, you’ll want your documentation to be well-organized and useful. That’s what documentation is — a friendly helper in a time of need.

    So, why is it hard to get anyone to read it?

    Well, since it isn’t sexy, we rarely take the time to give it the care it needs. We end up with documentation that is fragmented, inaccessible, and ad-hoc. In a crisis, these are the worst traits for documentation to have.

    As good product managers, we need to change that for the long term health of our products, and we can do that through the lens of visibility, accessibility, and systemization (VAS). 

    What is good documentation anyway?

    We can’t talk about documentation without being clear about what good documentation is. This is where the VAS acronym comes into play. Good documentation is:

    • Visible. You can see an answer when you need an answer.
    • Accessible. You are able to get to more information quickly and easily.
    • Systemic. Your documentation is always improving within your work system.

    Good documentation is visible

    Where is your documentation? 

    When people are looking at documentation, they are usually in the middle of an anxious moment. This is the wrong time for anyone to be wondering where something is.

    With documentation, the answer needs to be first, in multiple places, and shouldn’t require any thought on the person looking it up. Speaking of looking things up, good documentation relies on different ways of making information visible. Images, videos, indexes, and tables of contents are all useful tools to help the reader find their answer faster.

    Talk to your team about how they like information to be presented, then organize that information in a way that they can understand. In fact, talk to them about your documentation itself and why it’s important. Remember that documentation is for all types of people, so you should be prepared for different styles and preferences. 

    Good documentation is accessible

    However, being visible isn’t enough. Folks should be able to get to it, too

    There is nothing worse than documentation that is hidden, or even worse, password-protected. Open up your documentation. That’s the easiest way to make it more accessible. 

    Once you do that, audit your documentation so that anyone that works at your company can read it. As Nielsen tells us, documentation needs to be plain. No codes, no esoteric messages — just plain language.  You never know who might need to rely on that documentation in a pinch. 

    Make it easily searchable. Anyone who wants to read about anything should be able to access it intracompany — full stop.

    If the path to help isn’t clear for the level of information, then everyone loses, and your documentation doesn’t serve its purpose. 

    Good documentation is systemic

    Sure, it’s great that people can access your documentation, but how do we improve it? Do you think about documentation through the product development process, or is it something that is tacked on at the end? 

    If the answer is the latter, it shouldn’t be. Your documentation should iterate just like your product. I don’t just mean slapping a changelog on top of your documentation. Whenever you are looking at a feature or product, take a moment with the rest of your team to decide what is useful and what isn’t.

    This sounds like a lot and can be whenever you do it for the first time. However, when it happens in every sprint, you’ll see it can be done in as little as an hour. 

    Your documentation should have milestones, no different than anything else in your app. 

    Documentation is critical

    Your documentation functions as a great janitor. At its best, documentation serves as a way to save time and mitigate risk by giving folks an asynchronous method to get the answers they need.

    Good documentation matters because both the team and your customers will need you when you aren’t around. However, this won’t matter if it isn’t visible, accessible, or built into your system of product development. And as a result, you’ll see other levers utilized (customer support or cancellation) for issues that are solvable through documentation.

  • How to create a minimum viable product (without code!)

    How to create a minimum viable product (without code!)

    white and black Polaroid One Step 2 instant camera on white board
    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.

  • Why you should exchange your epics for initiatives

    Why you should exchange your epics for initiatives

    a group of people sitting around a table with laptops
    Photo by UK Black Tech on Unsplash

    So, it’s four weeks into a project, and you’re running into a few problems. First, your teams aren’t sure what resources they need to bring to bear. One engineer, for example, is now half-time after you’d have sworn you had her for a full six weeks. Second, no one is really sure about what this project is about. The team seems to get to similar places when discussing the “why” behind the project, but it takes a lot of prodding. And finally, leadership isn’t really clear on how this project supports the company strategy.

    You’ve been working with an epic you wrote weeks ago. After the kickoff meeting and the creation of a shared product requirement document (PRD), we should be aligned. 

    Is this just how this works? 

    Or is there a better way?

    I’ve run into this situation frequently in my ten-plus years of product management and team-building experience. Keeping teams aligned after the initial kickoff is a struggle, and that goes double for leadership. 

    That is why I have shifted from working on “epics” to crafting initiatives. This seemingly small change has had a huge impact on how my teams, colleagues, and leadership think about the work. It’s also made us more aligned.

    Before we discuss the initiative model, we’ll go into epics and why they let the above scenarios happen, how initiatives drive better team alignment, and how to get started with initiatives at your company.

    What’s an epic (and why does it encourage misalignment)?

    Epics are what most companies use when they work with an Agile process. They are a mass of work that is made up of user stories — the smallest components we use to parse out work the sprint level. An epic consists of a couple of sprints of work.

    Epics are organizing tools to help bundle up user stories, tracking work across sprints. That’s it. 

    An epic is simply not structured to promote alignment. In fact, epics can damage alignment by encouraging siloing of various teams. There is no real process, and how much effort is put into epics depends on the product manager who writes them. I’ve seen both well-written epics that consider everything that can possibly happen to lackluster ones that are just a few sentences. With no structure, the results are haphazard and usually end up in the place above, with no alignment after a few weeks on a project.

    Also, the product development team is often looking at the epic first if they look at anything at all. Most other documentation feels esoteric and heavy. If you’ve had a PRD that someone outside the product team has looked at more than once, I’ll buy you a drink.

    To align properly, we need something short enough to capture folks’ attention while also providing the most important data. Part of our role as product people is to be the protectors of company efficacy. All wasted effort is money burned, and that is something we should strive to avoid.

    That is where the initiative comes in. 

    What’s an initiative (and why does it encourage alignment?)

    An initiative is another way to structure your team’s work. Unlike an epic, it fosters alignment because it forces you to lay out assumptions upfront. Epics are a continuance of the status quo, which in most places, means a reliance on hidden inferences. The initiative process helps push those assumptions into the light, making sure you don’t go into the project without help. Bright, clear definitions let you understand underlying long-term priorities.

    By writing out the company history and simplifying it, you’ll get a better understanding as to why this project either fits or doesn’t fit into the organization’s direction. This compounds with later projects, as you get better tools for storytelling.

    The conversations you’ll have around this document as you are building it as well as after it’s done brings a level of trust. It’s consumable and available. Unlike storing epics in Jira or GitHub, where people who aren’t technical aren’t likely to go, this document is something you can ship to leaders and start sprints with while keeping everyone aligned.

    BLOGLearn how to calculate your product engagement score

    How to get started with initiatives

    For your next project, you’ll be tempted to write an epic like you’re used to. Don’t. 

    Instead, you’ll want to take a step backward. To help you understand what an initiative looks like and how it can help you and your team stay aligned, take the time to write one for a past project. You can skip the asking part. You’ve already done the work — it’s just a matter of writing all of this down and making sure you understand the importance of each part of the document. 

    Why is this step important? Because you’ll need an example to show to stakeholders to make sure it serves their needs. Every company is different and you may need to adjust the initiative to build a document that truly works for everyone. This goes double for the product team. My bet is they have the same annoyances you do and gathering their feedback on this document will get the entire group on the same page.

    Building the initiative

    The act of writing an initiative trains us to think objectively about the work we are doing. By going through this process and forcing ourselves to “check” if we should move forward, we have the opportunity to stop bad projects before they start.

    Each section, when done correctly, forces a conversation across the organization, giving us a temperature check on the internal politics and keeping leadership aware of how product work happens. Projects look less like gut decisions and more like a product.

    There are five parts of the initiative one-pager, and each is important to keep everything in line. Each of these five sections addresses common sources of misalignment and misunderstanding. By explicitly tackling each of them, you’re going to ship better products and have a better time doing it. You’ll also be encouraging alignment and collaboration throughout the process. They are: 

    1. Abstract
    2. Company objectives
    3. Success/failure
    4. Resources and responsibilities
    5. Time scale

    All five of these sections should fit on one page, and each section is designed to be a check on the next section. If your abstract isn’t clearly helping your company reach its objectives, you should have the ammo necessary to scrap the project. Same with company objectives, success/failure, and so on. 

    Abstract

    For this section, you’ll need to sit and write about what you are trying to achieve, who is it for, what is it for, who is affected by the work, what success looks like, the history of the team, etc. This section is where you’ll spend most of your time. However, it’s the key to understanding what you are spending all of this effort to build.

    This is the paragraph that outlines the work, and it needs to be short. Someone should be able to read it and repeat it. When writing the abstract, one technique to consider is the protostrategy method from Chris Butler — build a five-page outline, then cut that down to one page, and eventually, to a single paragraph. After completing the other four sections, you’ll come back to the abstract and finalize it. 

    Company objectives

    How does this initiative tie into the overall product strategy? Your project should have a direct line to the company’s objectives and goals. 

    To get started, you’ll need to reread the company’s product mission/vision/strategy docs and relate your project to these overarching themes. Do not try to force a connection between your abstract and the company objectives. This should serve as a check to see if this is worth doing. And if it isn’t, you should stop here and make your case as to why this is a waste of time.

    Success/failure

    What does success look like? What about failure? 

    To start determining the answers to these questions, look at the abstract and start pulling the numbers. Think about survival, failure, and success, and explain it in terms anyone can understand. You’ll need to be very clear here. Describe exactly when to pull the plug, keep going, or double down. This will be the key to mustering your resources. 

    Resources and responsibilities

    How are we going to staff this? Who is going to do what?

    You want to collect all of this information in one easy-to-share place. You don’t want any surprises when the actual work gets going. Begin by looking at what (and who) is available and start talking to the folks involved to make sure they have an understanding of what’s at stake and what you need to get it done. If you are finished with the above three sections, you’ll have the data you need to move forward. However, remember it is their resources that you are going to need — they can say no.

    Time

    How long will this take? Leadership will want to know how you are going to use the resources available to complete your project, and on what timeline.

    Start with an estimate of how many sprints the work will take. Try to remember Parkinson’s Law (things take as much time as you let them) and balance it with the Law of Slack (we never finish things on time.) You are never going to nail this, but an estimate will help folks make a “go, no-go” decision.

    Finalizing the abstract

    Now’s the time to look back at the abstract and finalize it. Can you contextualize the project more accurately now? With the data above, you should be able to write a clean, easy-to-read paragraph. 

    Does this sound like a lot of work? It is, but it’s worth it.

    Be prepared to spend more than a few hours creating this document. Consider this, though. You are leveraging millions of dollars worth of time to your project. The thousands of dollars of work hours that you’ll spend getting this together is worth the investment. 

    Initiatives help us stay aligned

    Wasted effort happens in every project. As a PM, you can’t stand over and watch everything that happens. But while we can’t avoid it, we sure can work to minimize it. 

    This initiative sheet does that, giving you a process for sharing the important parts of a project in a general way that folks can understand and reference. 

    The ultimate goal is the improvement of our decision fitness as a team, which is always worth thinking about. Otherwise, well-meaning product teams end up building something that has no tie-in to the project, then wondering why it sits on the shelf.

  • How lessons from wargames can help you ship products and build strong teams

    How lessons from wargames can help you ship products and build strong teams

    low angle photography of cranes on top of building
    Photo by Danist Soh on Unsplash

    We all know that product is hard, so here are some themes from a very playful activity that will help you get better at it.

    Shipping products is rough, full of false starts, lousy execution, and a lack of will to kill products quickly. But a bad strategy creates a state of false hope, and can leave you and your team punched in the face after months of work.

    As a product executive, I deal with the strategy all the time. One of my favorite jobs was as a product strategist at Philosophie. Philosophie focuses on innovation work in the enterprise, where ambiguity is the norm, not the exception. My job there was to focus my energy on finding the best strategies to create positive outcomes from the ambiguous problems of our clients, who usually didn’t have the time to deal with them.

    Every engagement was different, and I had to learn how to apply different strategies to solve those ambiguous problems. The great thing about strategies is they translate well to other areas. They aren’t one to one, something I used to help a startup could potentially help a fortune 100 company, and vice versa. That translation is a good thing because to become a better strategist; one must implement a strategy. Like all product work, it doesn’t happen in your head. This wasn’t the first place I learned this, however. It goes back to one of my first loves, wargaming.

    Wargaming is a hobby where people gather to simulate combat from different time periods. A game usually has a team trying to achieve an objective, using a rule set, dice and lead figurines to do so. In short, it is a bunch of people gathered around a table “pushin’ lead” and having a good time. Like wargaming, success, no matter how impressive your strategy, is not guaranteed. However, like wargaming, the right concepts can help any product manager increase their chance of success.

    Wargaming looks like this:

    blue and red boat during daytime
    Photo by Elias on Unsplash

    Pretty cool right?

    The great thing about wargaming is when there is a challenging scenario, both skill and luck play a role in finding success. Doesn’t that sound rather like product management?

    We may get lucky with building something. With that said, if you want your product to make a recognizable impact on someone’s life, strategy is essential. If one isn’t in place, the team will fail, given enough time. Good news! I think there are some quick heuristics that I’ve learned playing wargames that can help you make sure that your product strategy is well rounded.

    I’ve picked out three that have helped me think about my next steps, shape overall vision, and communicate effectively with the teams I’ve worked with to help us execute successfully.

    1. Rules Affect Implementation, not Direction

    You better know the rules if you want to execute, with that said though, your strategy shouldn’t be strictly based on the rules.

    In wargaming, the rules exist to bring in some order. We have to know what system we play in to make sure the scenario is clear and fun. At the beginning of the game, the person in charge, known as the game master, goes over the set of rules for the game.

    low angle photography of cranes on top of building
    Photo by Danist Soh on Unsplash

    In product, it may be the opposite. The market, stakeholders, and team dynamic make the rules. No one talks about them publicly, and you often have to figure them out as you go along. No matter though, either way, if you don’t know the rules, they can send you right to a confusing failure if you aren’t careful. With that said, you can’t let the rules dictate your strategy. If you are overly worried about a “morale roll” or a “stakeholder,” you can lose sight of the ultimate objective.

    Remember: Strategies = Sets of rules. Knowing the rules changes your strategies on implementation, not the strategy.

    2. The Goal Comes First, Everything Else is ego

    At the end of the game, no one is going to care if your tank survived or you took Persia – did you win? In both product and wargaming, sometimes the name of the game is resource allocation. Questions like, “Where can I reinforce my attack?” or “What workshop can I do to improve alignment?” are always going in and out of your head. You can’t, however, forget that ultimately, every answer should serve the objective.

    Sometimes, in wargaming, that means letting a territory go. In product, that may mean a feature has to die. If you don’t have a clear objective, every decision afterwards is tainted. If you have to stop and reorganize, do so. With that said, moving forward without your goal is a losing proposition.

    Do whatever it takes to remember the goal in all things, even if that means you take the brunt of the punishment. Failure often happens because people get far too worried about what things “look like” and ego instead of the objective. Remember: Objectives = Vision. Sometimes we care about the aesthetics or the beauty of the code… in reality, we have an objective, and your job is to connect all the pieces together so the goal wins over everyone else.

    3. Get Your Ideas out of Your Head, Then Commit

    Talking with your teammates means focus and focus wins. When you huddle with your team, the best idea has to win. Ego leads us to believe that we have the best ideas. As a product manager, you may think that means your ideas are best. They aren’t, so don’t fall into the trap of having your title determine the strength of your ideas. That’s what happened to Napoleon at Waterloo.

    Everyone has something to contribute, so get your thoughts out of your head. More importantly, facilitate other people to get involved. More ideas are better than fewer, so after they are out on the table, commit to the best idea.

    low angle photography of cranes on top of building
    Photo by Danist Soh on Unsplash

    The key to good teamwork is high-velocity communication. It means you listen, use your judgment to sift out bad ideas (even your own) and once the team has weighed in, decide and commit. Operationally this means that you should get your ideas out on the table and see what lives. Once they are out there, find the best option and commit to it.

    Commitment doesn’t equal blind fanaticism. The landscape changes and leaders are malleable. Product is all about finding shifts and exploiting them.

    Listen to your team and keep people updated. Don’t be afraid to take a break to understand next steps. Sometimes continuing to work for the sake of “progress” will leave an army, or product, dead in its tracks. Remember – decide and commit. You don’t have the best idea all the time, and one way the best idea is going to win is high-velocity communication.

    Key Takeaways

    Product is about helping teams to visualize a direction and execute to make it happen.

    As Dwight D Eisenhower said, no plan survives first contact with the enemy. You’ll make mistakes along the way, especially when the “game” is on the line, much like when you are in crunch time with a product. The world is ambiguous, and your job is to help see that through. Strategy gives you flexibility and a position to pivot from, as well as a method to communicate with your team.

    Remembering that rules affect implementation, not direction, that the goal comes first, everything else is ego, and that you should get your ideas out of your head and commit, helps you, as a product person, keep communication and trust high. As a result, you’ll ship well and more importantly, with consistency.

    Product is a constantly shifting environment. Understanding the rules, knowing your resources, and communication can be the difference between success and failure.

    A good strategy is a way for us to stay consistent and make sure that we keep our teams prepared for what comes our way. Even though it doesn’t guarantee victory, it does help us grow a community and build trust with our teams.

    So, go out there and roll some dice. Your team will thank you later.