At some point in your career, you may be asked a deceptively simple question: What is your strategy?

You might know your business well. You understand the customers, recognize the problems, and have a list of improvements your team could make. You may even have delivered successful projects and helped the organization achieve its targets. Yet when someone asks you to turn all that knowledge into a strategy, the blank page suddenly feels intimidating.

The difficulty often comes from not knowing what the word actually requires. Is a strategy a vision for the future? A roadmap of projects? A financial target? An organizational chart? A list of initiatives that leadership wants completed over the next few years?

These things can contribute to a strategy, but none of them is sufficient on its own.

A strategy is fundamentally a set of connected choices about how a business will address its most important challenges, achieve its objectives, and allocate its limited resources. It explains what is happening, which direction the organization will take, and what actions must follow from that decision.

Once that becomes clear, strategy stops looking like an exclusive skill reserved for senior executives and consultants. It becomes a discipline that can be learned, practiced, and improved.

Imagine being responsible for product and technology in a business expected to grow over the next several years. Leadership wants a strategy, and the deadline is approaching. You know the business needs to improve, but you are unsure where to begin.

One department starts outlining a new organizational structure. Another focuses on financial targets. Someone else writes a vision statement describing what the business should become. Each document contains useful ideas, yet the organization still lacks a shared explanation of how it will reach its goals.

This is what happens when people begin writing before agreeing on the problem they are trying to solve.

The documents may look strategic because they contain ambitious language, long-term objectives, and proposed initiatives. But without a common framework, they can become disconnected collections of ideas. A vision might describe a desirable future without explaining the obstacles standing in the way. A roadmap might list projects without explaining why those projects deserve priority. A financial target might establish an ambition without showing what needs to change to achieve it.

The answer is not necessarily to produce a more impressive document. It is to create a clearer way of thinking.

A useful strategy framework gives everyone a common sequence for examining the business, making choices, and translating those choices into coordinated action. It makes the thinking visible before the organization commits to a large collection of projects.

Tip: Before writing a strategy document, agree on the questions it must answer: What is happening now, what is preventing progress, which choices will address those obstacles, and what must change as a result?

The first part of a useful strategy is diagnosis: understanding the situation well enough to identify the real challenge.

This requires more than listing strengths, weaknesses, opportunities, and threats. It means examining how the business actually works, where value is created, what customers experience, how money flows through the organization, and which constraints prevent better results.

For example, a company may believe its growth problem is a lack of new product features. But a closer examination might reveal that customers struggle during onboarding, the sales process attracts poorly matched prospects, or the product depends on capabilities that cannot scale with demand.

Each diagnosis points toward a different response.

If onboarding is the problem, building more features may increase complexity without improving growth. If the sales process attracts the wrong customers, adding marketing activity may generate more unproductive leads. If the underlying technology cannot support increased usage, launching additional products may make the operational problem worse.

The purpose of diagnosis is to move beyond symptoms and identify the obstacle that matters most.

This also requires distinguishing evidence from assumptions. Customer feedback, operational data, financial results, and conversations with people doing the work can help reveal what is happening. But information alone does not create a diagnosis. The important work is interpreting that information to explain why the current situation exists.

A strong diagnosis narrows the problem. It gives the leadership team something specific to address rather than a vague ambition to improve everything.

Tip: When examining a business problem, ask what is causing the result rather than immediately proposing a solution. A more accurate diagnosis can save months of work on the wrong priority.

Once the challenge is clear, the next step is deciding how to address it. This is the guiding policy: the overall approach that directs the organization's response to the diagnosis.

This is where strategy requires difficult choices.

If the business has limited engineering capacity, it cannot treat every requested feature as equally important. If customers value reliability more than novelty, the company may need to prioritize stability over launching a long list of new capabilities. If growth is constrained by a complicated customer experience, simplifying the product may matter more than expanding the number of available features.

A guiding policy gives the organization a consistent way to make these decisions.

It does not need to describe every project or operational detail. Instead, it establishes the principles that determine which opportunities deserve attention and which should be declined or postponed.

This is also why strategy cannot simply be a list of goals. Goals describe what an organization wants to achieve; a guiding policy explains how it intends to approach the challenge. Two businesses can pursue the same growth target while making entirely different strategic choices about customers, pricing, product development, distribution, or service.

A useful policy makes those choices explicit.

It also creates boundaries. If the organization has decided to prioritize a particular customer segment, projects aimed at unrelated segments may need to wait. If reliability is the primary constraint, teams may have to delay attractive new features to address recurring failures.

Those decisions can be uncomfortable because every opportunity has supporters. But a strategy that accommodates every priority provides little guidance when resources run short.

Tip: Write down the few choices that should guide everyday decisions. If your strategy cannot help the team decide what to postpone, reject, or prioritize, it probably needs sharper boundaries.

A diagnosis explains the challenge, and a guiding policy establishes the approach. Coordinated action connects those decisions to what people actually do.

This is where strategy becomes more than an exercise in planning.

Suppose a company determines that customer retention is limited by a difficult onboarding experience. Its guiding policy is to make the product easier to adopt before expanding its feature set.

The resulting actions might include simplifying the setup process, improving documentation, measuring where customers abandon onboarding, and directing engineering capacity toward the most damaging usability problems. Sales, product, engineering, and customer support would need to coordinate around that shared priority.

The important point is that these actions reinforce one another. They are not separate projects that happen to appear in the same presentation. They form a connected response to the same diagnosis.

Coordination also means deciding what not to do.

The organization may need to postpone a major feature launch, decline a customization request, or stop maintaining a low-value capability. Those decisions release time and resources for the work that matters most.

Without such trade-offs, teams can end up carrying their old commitments while adding new strategic initiatives on top. The strategy then becomes another layer of work rather than a guide to allocating effort.

A useful plan should make ownership, sequencing, dependencies, and expected outcomes clear enough that teams can act without repeatedly reopening the original strategic debate.

Tip: For every strategic priority, identify the actions, owners, dependencies, and existing commitments that must change. Strategy becomes credible when it changes the work people actually do.

One common mistake is treating each department's strategy as an independent plan.

Product may prioritize a new customer experience. Technology may focus on modernization. Sales may pursue a new market. Operations may try to reduce costs. Every department could execute its own plan successfully while the business as a whole moves in conflicting directions.

The problem is not necessarily that any department has made a poor decision. It is that the decisions have not been coordinated around a shared business objective.

A product and technology strategy should explain how those functions will enable the broader direction of the business. It should not exist simply because every department is expected to produce a strategy document.

For example, if the business strategy depends on serving more customers without a proportional increase in operating costs, product choices might emphasize self-service experiences, while technology choices focus on automation, system reliability, and the ability to support higher usage. Those choices reinforce the same business objective.

If the business instead competes through highly customized service, the required capabilities could look very different.

This connection matters because technical improvements do not automatically produce business value. A system can be modernized without addressing the most important customer problem. A product can gain features without improving retention. A team can deliver more software without making the business more effective.

The right question is not simply whether a department is improving. It is whether the improvement supports the organization's chosen direction.

Tip: For each major initiative in your function, explain which business challenge it addresses and how its outcome supports the broader strategy. If the connection is unclear, revisit the priority.

It is easy to assume that strategic thinking comes naturally to certain people. Senior executives seem comfortable making decisions with incomplete information, while experienced leaders can quickly organize a complicated business problem into a few clear choices.

But this ability does not have to be mysterious.

A repeatable framework gives you a way to practice. Diagnose the situation. Choose a guiding policy. Coordinate actions around that choice. Then examine what happens and refine your understanding as new evidence emerges.

Your first attempt will not be perfect, and it does not need to be. The purpose is to create enough clarity for the organization to move in a deliberate direction, rather than waiting for an ideal plan that may never arrive.

Strategy also becomes easier to learn when it is shared. Working through the diagnosis with colleagues exposes assumptions that one person might miss. Discussing trade-offs reveals conflicting priorities. Reviewing the proposed actions helps determine whether the plan is realistic given the team's capacity and constraints.

Over time, the framework becomes a way of thinking rather than a document to complete.

You begin to recognize when a problem needs better diagnosis, when a team is avoiding a difficult choice, or when a list of initiatives lacks a coherent connection. You also become better at explaining why a decision makes sense and what evidence might cause it to change.

The deeper value is not producing a polished strategy presentation. It is developing the judgment to make connected decisions under real-world constraints.

Tip: Apply the diagnosis, guiding policy, and coordinated action framework to a small, current problem before using it for a multiyear plan. Practice makes the process easier to understand and improve.

For an engineering manager or director, prioritization is where strategy meets the calendar. Your team has a fixed number of engineering weeks each quarter. Feature requests, platform work, incident follow-ups, security fixes and tech debt all compete for the same weeks. If you do not choose, the loudest stakeholder or the latest escalation chooses for you.

In my own teams, the most useful habit has been to make the trade-off visible. When a new request lands, I do not ask "is this important?" because almost everything is. I ask "what does this replace?" and put that question to the person asking, with the current commitments on the table. The conversation shifts from pressure to choice.

Directors carry a second job: keeping several teams' priorities pointed at the same diagnosis. Two teams can each be busy and productive while pulling the platform in opposite directions. A short written guiding policy, shared across teams, does more for alignment than another planning meeting.

AI tools can make the diagnosis step much faster. They can summarize months of incident reviews, cluster support tickets by theme, or draft a first pass of options and trade-offs from your planning documents. That is real leverage for a leader who used to spend days collecting the evidence.

What AI cannot do is own the choice. A model will happily give you ten priorities, all well argued. Deciding which one matters most, and telling a stakeholder that their request will wait, is still leadership work. Use AI to sharpen the diagnosis and test your reasoning, then make the call yourself and explain it to your team.

A strategy document can be beautifully designed and still fail to guide a single meaningful decision. Conversely, a relatively simple document can be valuable if it gives people a shared understanding of the challenge, the choices that matter, and the work that follows.

The difference is whether the strategy changes behavior.

When priorities compete, the strategy should help people decide what deserves attention. When a new opportunity appears, it should provide a basis for evaluating whether the opportunity fits the chosen direction. When teams disagree, it should make the underlying trade-offs easier to discuss. And when circumstances change, it should provide a starting point for deciding what needs to be reconsidered.

That does not mean a strategy should remain fixed regardless of new information. A strategy is a reasoned response to a particular situation, not a promise that the original assumptions will always hold. If the diagnosis proves wrong or the environment changes significantly, the organization may need to adjust its choices and actions.

The discipline lies in making those changes deliberately rather than reacting to every new idea as though it deserves equal priority.

You do not need to know everything before you begin. You need a clear enough understanding of the problem to make a defensible choice, a practical set of actions to test that choice, and a willingness to learn from the results.

The next time someone asks for a strategy, resist the urge to start with a blank document and a list of ambitious goals. Start by understanding the business. Identify the obstacle that matters most. Decide how to address it, then align the work around that decision.

Tip: Judge your strategy by the decisions it clarifies, the activities it helps you stop, and the outcomes it enables—not by the length or sophistication of the document.

Strategy is not a secret language reserved for people with impressive titles. It is the discipline of understanding what matters, choosing a direction, and organizing action around that choice. Once you approach it this way, the blank page becomes less intimidating because you no longer need to invent a strategy from nothing. You have a process to follow, questions to answer, and a way to turn uncertainty into purposeful action.

Hit reply and tell me: what is one piece of work your team stopped or postponed that made everything else move faster? I read every answer.

Keep going, one small spark at a time.

Erwin