I’m struggling to write several posts and I realized I need to define my terms.
I keep seeing managers confuse the strategic and tactical. That leads to large and unchangeable roadmaps and a lot of emphasis on predictability. I don’t know how to offer the level of predictability they want for large and unchanging work. Worse, many of these managers also want business agility. Business agility requires change. Let’s differentiate between the strategic and the tactical.
In this post, I’ll take a first pass at definitions, so we can separate the strategic from the tactical.
Strategy Occurs At Several Levels
I see strategy necessary at these management levels:
- Organizational strategy, to define the value the organization offers to the employees, customers, and other stakeholders.
- Product strategy, to define the value the products offer to the product’s users/customers.
In addition, you might need these product strategies too:
- Product architecture, to shepherd the technical value of a product.
- Test architecture, to shepherd the testing tactics.
I’m sure I’ve missed something. If you ever have to answer the “what’s the value” or the “why” question, you might be at the strategy level.
However, I’ll focus on the management strategies now, for the organization and for defining the product.
Organizational Strategy Explains the Organizational Value
Every organization needs a single overarching strategy. Why does the organization exist? (See more about this in Practical Ways to Lead an Innovative Organization.)
When the company chooses a strategy, it decides these questions:
- What expertise will we offer?
- Who are our customers/users? Not all users are direct buyers. For ease of reading, I’ll call these people “users.”
- What benefit(s) do they get from us, as a whole?
When managers decide the answers to these questions, they decide on the value the organization offers. That value allows them to create an overarching goal.
Companies might want to change their value and overarching goal every so often. That’s when they iterate on their strategy. The managers might realize the overarching goal changes as they change the project portfolio.
Notice that organizational strategy requires agreement among the managers.
Do you have more than one division? If so, you might find this more difficult. That’s because divisions often have different users. Division 1 sells to businesses—and Division 2 sells to end-users.
Division 1 and Division require different product strategies. With any luck, they all create and agree with the same organizational strategy.
Your organizational strategy enables these two decisions:
- Which products and services to offer to which users. This means you can create a product roadmap and a backlog.
- When you choose which products to fund for now, you define the project portfolio.
How often should your strategy change? When the world changes or when you want to change the value you offer as an organization. As a guideline, I like to review the strategy every 6-12 months. Why that often? Because even without a pandemic, the world changes fast.
That organizational value defines your products and services. I’m going to call them all products.
Define Each Product Strategy
Regardless of your size, each product you define requires at least this much for a strategy:
- Who the product is for. (Your ideal users.)
- The value you expect those people to get from this product.
If you can’t write that down, you can’t build a roadmap or a backlog. You might want a one-page, a canvas, or some other brief description. Why brief? So people can read it when they decide to fund the project in the project portfolio.
All of my clients have too much work to only fund products. They fund projects. You might like Project Work vs Product Work and Projects, Products, and the Project Portfolio: Part 1, Organize the Work to understand my thinking about projects vs. products.
Let’s review. You have an organization-wide strategy. That allows you to create product-based strategies. Now it’s time for tactics. The first tactic I use is the project portfolio.
Tactic: Project Portfolio Implements Your Strategy
Once you know your strategy, you can define which products and services you want to fund now. (See Leadership Tip# 10: Commit Coherent & Meaningful Work to a Team.)
The portfolio explains the tactics you commit to, for some time. The tactics reflect that overarching goal you all agreed on, for the organizational strategy.
How often do you iterate on the project portfolio? Here are some examples:
- If you’re a startup, probably once every week or two, as you learn what your users want and what you want to offer.
- Monthly or bi-monthly to get the most business agility, assuming your teams can deliver at least once a week.
- Quarterly if your context doesn’t change that much.
Tactics should change often. Strategy doesn’t. If you think you need to change your strategy more often, you might not have defined the value you offer.
I wait to start roadmaps once I have the project portfolio. Yes, I know I’m strange.
Tactic: Product Roadmaps Show Where the Product is Headed
Many organizations invest a ton of time in a roadmap first before they commit to the project in the project portfolio. That’s misguided because people commit to tactics before they have feedback.
How many long and “unchangeable” roadmaps have you seen before the team even gets the roadmap? Too many.
Roadmaps are tactics, not strategies. This means they need to change, and often. (See Multiple Short Feedback Loops Support Innovation.) (Backlogs are even more tactical because they work at the one-to-six-week timeframe. Expect to see more from me re roadmaps and backlogs in the future.)
My guiding principle to know if this thing is strategic or tactical is the rate of change I expect. (Not want, expect.)
How Often Do You Want to Change?
Strategy changes less often because we don’t tend to have the same kind of feedback loops for the value we want to offer. That value helps us articulate which products and services we want to offer.
We need tactics to change more often because we learn as we progress on creating and delivering those products and services. We use a variety of feedback loops. (In a pandemic, both strategy and tactics change all the time because we might need to offer different value because the world changed.)
My approach to strategy and tactics:
- Gain agreement on the organization’s “why.” (Strategy)
- Create common overarching goals for the managers so they can agree on the project portfolio. (Strategy)
- Create that project portfolio and agree on when to iterate on it. (Tactic)
- Create product roadmaps so the teams can see ahead and backlogs for now. (Tactic)
When you define a purpose, you’re in the strategy realm. When you define the product details, you’re in tactics.
Do you agree? Disagree? Let me know, please. Thanks. Now I think I can write the posts I want to finish.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Purpose vs. Product: Differentiate Your Strategy from Tactics (Portfolio & Roadmaps) Opinions expressed by Java Code Geeks contributors are their own. |
