Adam Thomas | Product Management Expert

Tag: team

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

  • Use a premortem to predict the future

    Use a premortem to predict the future

    What if there were a way to figure out the problems that a project would encounter before you started work on it? With a premortem, you can do just that.

    selective focus photography of people sits in front of table inside room
    Photo by Annie Spratt on Unsplash

    If there is one constant we can count on, it’s that mistakes will happen.

    When we start a new project, though, that can be the furthest thing from our minds. We often approach a new challenge with a sense of optimism. Of course, we need to bring enthusiasm to our work. The downside is that we are then opening ourselves to being blindsided by problems we could have foreseen.

    Over time, this can become a major problem. In the CI/CD world we live in, it’s never a question of if we’ll have new projects, but how many. As product managers, we own the decision fitness of a company, and the organizational debt that comes from those blindsidings adds up, ultimately affecting the company’s ability to reach its vision.

    This responsibility becomes clearer when considering the questions that we tend to get and also the ones we ask ourselves. Often, these questions boil down to some version of “How do we know this will work?” We get so many variations of this question that a lot of PdM tooling is just figuring out how we can answer that one query in all its versions. Retrospectives are designed to help answer that question for past projects, but how can we ask it of future endeavors?

    This question keeps product coaches and executives up at night, partially because there is no solution. If you knew the future, you wouldn’t need to be a product manager because you ought to just play roulette all day. For those of us without clairvoyance, though, the best we can do is minimize our risks and raise potential problems as soon as possible. After all, we know mistakes are unavoidable.

    So, how do you do that?

    Let me introduce the concept of the “premortem,” which is a workshop that can help identify problems before they happen. One of the outputs of organizational debt is fear, and this workshop helps shine a light on that fear so that teams can find alignment. I know this sounds a little scary, but as we walk through a premortem definition, how it creates an accurate map of an organization’s incentives, and how you can infuse it into your processes, you’ll see how you can use that fear to find holes in your own team’s alignment.

    What Is a Premortem?

    A premortem is a workshop that allows participants to give voice to their fears about potential sources of failure on a given project. It differs from its more well-known sibling, the postmortem, in that you do this before the project begins. The facilitator of the project asks the team to work backward from a hypothetical potential failure to understand how it happened and which behaviors you can avoid or adopt to dodge catastrophe.

    What does bringing up problems before a project do for your team? It gets to a fundamental truth of organized structures: We often deal with the same issues over and over again. Bringing that fact up and making organizational fears and assumptions transparent to those around us is a great way to start to address the problem and end its grip on a team.

    A premortem requires a facilitator, a note taker and representatives of the different teams that have some responsibility for the project’s success. The facilitator should ask and do all the following:

    • Based on a standard time horizon for a project in your organization, ask the group to brainstorm about some realistic ways this project could fail.
       
    • The facilitator should bundle these concepts together based on topic. In facilitator speak, this is called “affinitizing.”
       
    • The team can then prioritize the problems, first by talking about the groups, and then by voting on which topics are most important to the business.
       
    • Then the facilitator should ask the group to brainstorm again about how to avoid these potholes.

    This process, which should take 60 to 90 minutes, will help teams clearly identify fears that they face that may currently be lurking under the surface. The meeting will help the teams to give voice to their anxieties and get everyone on the same page by specifically discussing the issues each group faces.

    Why Is a Premortem Important?

    So, let’s talk about potential failure, which is the foundation for this exercise. What if I asked you, “How will this imaginary project fail?” You might have trouble coming up with anything. In fact, it may seem very strange that anyone would even ask this question.

    In practice, though, you’ll find that coming up with answers isn’t so hard. Let’s shift away from this article and imagine that you, as the product manager, are in a room with your team. You think about the last time a project failed and why. During this session, you recall that two teams didn’t interact well, which hampered the project.

    In fact, you aren’t the only one who thinks this. Other people on your team do so as well. The facilitator asks, “What are some realistic ways this project could fail?” You all have plenty of things to say.

    Next, you’ll work through why these things happened. As the team expands on the important failures, you’ll gather far more information on what happens when teams interact. The conversation will generate a great deal of insight into possible problems.

    Finally, you’ll jump into solution mode and talk about what actions you can take to mitigate the risks you have mapped out. This is process improvement at its best, as you’ll be working with real problems and solutions tied to the fears of the team, based on the themes you’ve seen earlier.

    Premortems Map Out an Organization’s Incentives

    The process in the middle of the workshop, where we affinitize and come to an understanding of what the problems are, has a few components to it that will help you become a better product manager.

    What makes the understanding section so powerful is that the person speaking will often share stories in which perceived slights took place. The stories you hear through the premortem will help you understand what fears folks in the organization are facing, both implicit and explicit. Sometimes, you’ll be lucky enough to hear the team articulate their fears in a fully formed way.

    It’s a shortcut to understanding the politics of an organization. Politics aren’t quantifiable, so the information isn’t going to be as straightforward as a hard, quantified number. The qualitative anecdotes you hear, however, will help you identify how your organization works.

    If you don’t understand the politics of the organization, you’ll soon wonder why various teams are apprehensive about certain tasks they’re given. This is where having a map, developed through a premortem, helps you to navigate problems.

    Dealing With the Responses

    You’ll notice two types of responses from the teams you speak with. They may talk about themselves, which we can call an internal assignment (i.e., self-awareness). Other times, they may talk about other teams, which we can call external assignment (i.e., blame). You should gauge the seriousness of each response by comparing them to the values of the company and asking the respondents to rank their importance on a scale of one to 10. Doing so will help you determine a course of action. Both internal and external assignments are worth investigating further.

    Let’s look at a hypothetical example. Imagine that you’re talking with your marketing department as part of a premortem. You might get something like: “We got thrashed because our Q3 launch didn’t go well. We were just swamped.” This response would qualify as an internal assignment. It’s also pretty tame since it seems like a one-off issue.

    Alternatively, sometimes the responses are very clear external assignments: “Our last release gave us way too many bugs because QA didn’t catch them, and they ruined it.” This is an external assignment and an alarm at that since the blame is absolute, especially if they use dramatic language like “ruined.”

    As a product manager, this is where we put our detective hats on and hit the pavement, looking for the reasons why the incident happened. You are looking for sharp critique, blame, or the other failures teams talk about. Sometimes, you can find them in the postmortems of other projects or in written documentation in places like Confluence or notes buried in your company’s Google Drive. Try this with internal assignments.

    Other times, the answers will be with the people in the org themselves, and it’s worth scheduling an informal follow-up chat to get more details. Conference rooms can work for something like this, but more often than not, getting some coffee or lunch will work even better. You want this conversation to be as casual as possible so that no one feels as if they’re under attack for placing blame. Remember, this is a fact-finding mission, not a blame game. This approach is particularly useful for external assignments since talking can clear up misunderstandings.

    As a product person, it’s important to build relationships across the organization to find out where resources are and also identify hot button issues between teams. Premortems can help you accomplish this.

    Making Premortems Real

    Not all companies are created equal, and so you need to understand what ties the company together. This is where company culture and values come into play.

    These concepts that you often see on the walls and on the website’s “About” page are the key to getting a premortem to happen within teams. Oftentimes, the values you see are at least implicitly agreed on, and since they are, you have the opportunity to use those principles as a shared framework to bridge the gap between groups. They are the lighthouse that can lead your team to safe harbor.

    As you put the workshop together, make sure you refer to these values in the description. Do so both in writing as you send out communications and also when you get the team in the room. Since everyone agrees with these principles, at least in theory, people will be far more comfortable with the meeting. They should begin to see it less as a sniping session to get their political enemies and more as a way to get everyone on the same page.

    Having a clear code of conduct helps to let people know that there are rules in place to maintain respect between people and teams. Everyone is looking to improve, so it matters how we talk to each other. Snark, sniping and backbiting are all counterproductive. Make sure that whoever facilitates lays out the ground rules and enforces tact in the conversation. Finally, this type of workshop requires clear communication and context. If you can’t get in a room together, video actually matters here.

    Face Your Fears With a Premortem

    Our first calls are almost never right. Same with our perspectives on the teams we are working with. The more alignment we have in the organization, and the higher our trust is inside of our teams, the better we are. We’ll need to have a map of where we are to be effective.

    Premortems are a great tool to make that happen. By exploring the past before we engage with the present, we give ourselves a chance at a better future.