How to deal with constant change of strategy – 4 best practices

As an organized and structured person I love when everything goes smoothly according to plan. I am not the biggest fan of changing course just as we started to get some momentum. I suspect you aren’t either. Unfortunately, for many of us working in product development shifting priorities and frequent change of strategy is the norm. While there can be good reasons for these strategic shifts, they can make life miserable for development teams. 

It took me a while to learn how to deal with frequent change of plans. Today, I want to share what I learned. I want to first address the topic in general and then share my best practices in dealing with changing priorities. 

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

Changing priorities is a symptom of feature or delivery teams

If you are experiencing a constant shift of priorities – with constant I mean a significant shift every few weeks – you are likely in a company with feature or delivery teams. You are experiencing one of the symptoms of this type of organization.

The product teams do not – or are not allowed to – conduct product discovery. Instead, they build features defined by others, usually by the leaders of the organization. Most of the time, these features are the first ideas one person had to solve a specific problem. Rarely are they the best ideas. Thus, when the feature inevitably doesn’t achieve the expected impact, plans are thrown overboard and priorities shift. 

It does get worse. I’ve been in situations where customer interactions with senior management lead to significant strategic shifts. The new strategy would then last exactly until the next customer interaction. Sometimes it felt as though the quality of that day’s coffee might also have had an impact on the likelihood of changing the course.😉

Regardless of the reason, the product team feels the effect of the changing priorities. In the worst case they are forced to stop what they are doing and immediately start on the now most important thing. They work on it until priorities change again and the cycle starts anew. 

My best practices in dealing with constantly changing strategy

If you are in the situation above of the feature or delivery team, I always advise in pushing towards an empowered product team. This is, however, a long and arduous process requiring explanations upon explanations and lots of negotiating. It requires a change in culture. This is effort well spent, though. 

Until then, you need to deal with the situation. After trying different tactics, I have found four best practices to be especially helpful in in dealing with frequent strategic shifts: 

  • Using a flexible framework for managing work
  • Asking a lot of questions 
  • Publicly fixing priorities
  • Underplanning

Using a flexible framework for managing work

The de-facto standard to manage work in software development is (I think) Scrum. If you are using Scrum and plans frequently change before the sprint is over, the obvious recommendation is to shorten the sprints. You would think that two week sprints – I don’t suggest making them shorter than that – would be short enough to react to changes in priorities. Well, sometimes plans change sooner than that.

In this case it makes sense to ditch Scrum altogether in favor of a more flexible system for organizing the team’s work. Kanban is the obvious choice here. There is no upfront commitment to a few week’s worth of work. After finishing the current task, the team simply takes what has the highest priority at that moment. 

There is a reason Kanban is the default system for customer support teams. For them priorities can change at any moment, for example through outages or integration issues of important customers. 

When using Kanban in an environment of frequent strategic shifts, make sure to hold off on planning or refining stories until the last possible moment. It should happen right before the team starts with the implementation. Thus, you avoid wasting time and effort discussing things that may be obsolete later on.

In this context it is imperative to slice the stories in such a way that they are as small as possible. Then, when plans change you can still finish what you are working on – because you only need a few more hours or days – and don’t end up with a bunch of half completed tasks and rogue branches in gitlab. 

(It always comes back to small product increments, doesn’t it? They automatically solve so many issues in product development. They help catch errors quicker, you get feedback sooner, you become better at deploying, and you are able to react much better to changes in plans or priorities.)

Asking a lot of questions

One way to politely push back against a change in priorities is by asking a lot of questions. Your goal should be trying to understand the reasons behind the change in plans.  

Simply asking questions like “What problem are we trying to solve for our customers? What solution is the customer using right now? What underlying goal are we trying to achieve and how can we measure success?” will already lead to some results. It forces us to jointly think through the issue. 

It’s very important to ask these questions in a constructive and polite manner. In no way should they come across defensive or hostile. You should genuinely try to understand the thinking behind the change in plans, even if you are frustrated.

More often than not, jointly talking and thinking through the strategic shift will uncover flaws in the reasoning. This is the chance to avert the change and possibly guide the discussion away from features that the team should build towards an outcome it should achieve. It might be a chance to take a step towards empowering the team.  

If you can’t avoid changing priorities it’s extremely important to clarify what exactly the new plan means. Again, ask a lot of questions. Don’t just start implementing but try to understand the details first. You need to refine the stories. It must be unambiguously clear what needs to be done. There’s nothing worse than interrupting what the team was doing, starting something new, and then finding out the team built the wrong thing due to a misunderstanding.

Talking through the issues might again uncover some flaws in the reasoning thus giving you the chance to avert the changes. You could also find out that you don’t need to develop anything because there is already a solution for the underlying problem that the stakeholder didn’t think of.

Publicly fixing priorities

In an organization with frequent strategic shifts, these changes are often not well thought through. They happen because there are no hurdles to someone making a decision with such far reaching impacts. You can increase the psychological barriers. 

The most effective way of doing that is publicly fixing the priorities in writing. Ideally, this happens in some big meeting and the results are ceremoniously communicated across the organization. This makes the strategic direction feel more real and the barrier to changing it increases. 

Of course, if the CEO of your company truly wants to change direction, no bit of writing will hold her off on that. But at least she has to think about the changes before communicating them. You also have a better basis for discussion if you can pull out the meeting minutes where the entire company agreed on a plan a week ago. 

Publicly fixing priorities has worked really well for me in the past. We did this in the context of quarterly planning. 

At one point in time, we struggled with frequent strategic shifts. Just to paint a picture: we once conducted almost a week of workshops with five teams to create a plan for the upcoming year. We also created a detailed plan for the coming months, only to completely throw everything out of the window a week later because priorities changed. 

After that, we successfully negotiated a process that fixed priorities for one quarter (although it took some time to get there). In the middle of each quarter, the planning process began for the next one. The Product Owners worked with the leadership team to define a list of priorities for the upcoming quarter. Then, the teams conducted high level estimates of the features, and produced a time based roadmap with estimated dates. We presented the roadmaps causing a final round of (mostly) minor adjustments. Finally, leadership presented the plan to the entire company and the teams went into execution mode. 

There were still changes in priorities but they were mostly minor or due to truly extraordinary circumstances. I believe this process and the public announcement of the plan created a psychological barrier that helped prevent the chaos from before. 


Last but not least, there is always the tactic of underplanning. Essentially, you plan in such a way that you have capacity left over. This remaining capacity can be used to react to changes in priorities or urgent requests and bugs. If those don’t come, you can use the excess capacity to work on reducing technical debt. 

In this case you are essentially keeping a maintenance buffer, generally a thing that makes sense to do. The size of this buffer depends on the significance of the strategic shifts.

Working as the Product Owner for a B2B service, we frequently had very specific – and always urgent – requests from our sales team come in. These were mostly needed to close deals and often messed up our plans. 

Realizing that this was a constant distraction, we then started increasing our buffer and underplanning our sprints. That way, whenever something urgent came in, we were able to react. We usually did a quick refinement session and then worked on the topic right away. If nothing came in we simply pulled additional stories or worked on maintenance.

Two words of caution regarding underplannig. One, underplanning only works if the shifts in priorities are sufficiently small. If the company does a complete 180 every week, no amount of underplanning will help you react to that. Second,  you need to be careful to not overdo it. Excessive underplanning – or overestimation of work for that matter – quickly erodes trust in the team. This will be counterproductive in empowering the team, the basis of which is leadership trusting the team to do the right things.


In the dynamic world of product development, embracing change is a way of life. However, it is challenging to do this embracing if the change means a constant 180 in strategic direction. Pushing for an empowered team is the key in the long run. 

In the short run, there are a few best practices to help with the embrace. You can improve the ability to react to changes by using a flexible framework or underplanning. You can also try to avert the shifts altogether by creating the hurdle of publicly fixing priorities or using questions to uncover issues. It is my hope that these tactics help make the day to day of your product development just a little bit smoother.

Coverphoto from Freepik