Tag: product strategy

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

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