What Is Business Strategy – and How It Maps to IT Projects?

What is business strategy? In plain terms, business strategy is the set of integrated choices an organization makes to create lasting advantage: where it will compete, how it will win, which capabilities it will build, and what it will not pursue so that scarce resources go to the best opportunities. It is not the same as a business model, financial target, a vision statement, or a list of projects – though those can support strategy when they express a clear theory of success.

Below you get three things in one place:

1. a compact primer on what strategy is,
2. a step-by-step instruction to produce a one-page business strategy for an IT project, and
3. notes on OKRs and failure modes.

Why “we have a strategy” is often untrue

In many companies, “strategy” has become a verbal tic. A document full of ambition, buzzwords, and growth targets can still fail the basic test of strategy. Growth is an outcome of choices that work in a specific context; it is not something you obtain by raising numbers on a spreadsheet or by motivational speeches alone.

Useful strategy is easy to describe and hard to execute. Richard Rumelt, in Good Strategy Bad Strategy, describes the core of good strategy as a kernel of three parts:

1. Diagnosis – An honest view of the situation: the crux of the problem, the forces in the market, and your relative strengths and weaknesses – not only the story you prefer to tell.
2. Guiding policy – A small number of principles that steer action: how you will compete, serve customers, or operate differently from alternatives.
3. Coherent actions – Consistent moves across product, go-to-market, operations, and technology that reinforce each other. If commercial, product, and IT initiatives pull in different directions, you do not have a strategy; you have a portfolio of busy teams.

Rumelt’s account of “bad strategy” (fluff, avoiding the real problem, mistaking goals for strategy) matches what many delivery organizations experience when roadmaps and targets stand in for choices. The same failure modes appear as empty slogans, goals without a theory of how they will be achieved, or a refusal to face the hardest trade-off. For IT, the cost is concrete: software is expensive to build and to throw away. When the “strategy” is only “be number one” or “digital-first,” delivery teams get no basis for saying no. Everything looks plausible; nothing is truly prioritized.

Strategy vs. goals vs. roadmap

Goals (revenue, margin, retention, NPS) say what you want. They become strategic only when linked to a believable path under real constraints – capital, regulation, talent, time.

Roadmaps sequence initiatives and communicate intent. They are planning and alignment tools. They are not substitutes for strategy unless they embody a chosen direction and explicit trade-offs. A roadmap without a theory of value is just a schedule.

Strategy allocates strength: it concentrates effort on the most promising opportunities and, crucially, defends focus by defining what the organization will stop doing or defer. That is what frees capacity on an IT programme.

For technology leaders, the productive question is not only “What did leadership announce?” but “What problem are we solving for the business, and what could prove us wrong?” Your theory should be falsifiable: if we ship this and change customer or internal behavior in a specific way, we expect a named metric to move within a realistic horizon.

Business model vs business strategy (wording people mix up)

Consultants and founders often separate the two ideas like this (see for example discussions of model vs strategy in the B2B world – e.g. Sellwise on strategy vs business model):

• A business model describes how the organization earns money today: who pays, for what, at what price and cost structure, through which channels, with which assets and partners. It is the current “recipe” – sometimes visualized with a canvas – and it can be unhealthy (e.g. revenue up while margin collapses because every big deal starts with a 10% discount).
• A business strategy answers where you are going and how you will adapt: which segments and bets matter next, which flaws in the current model you will fix, what you will stop doing even when it still brings revenue. It is forward-looking and adaptive; it uses the diagnosis of reality (including economics) to choose trade-offs.

A common metaphor: model ≈ engine, strategy ≈ map and choices on the route. You need both: strategy without a honest picture of the model turns into slides; a model description without strategic choices is not a plan – it is a snapshot.

For an IT project, that means your one-pager should usually ground the diagnosis in economics (who actually pays the bills, which unit economics are broken) and state what this initiative will change in that picture. The template below is built for that combination.

Corporate, business, and IT: how the levels connect

Large organizations often separate:

• Corporate strategy – Which businesses to be in, how capital is allocated across divisions, M&A, portfolio risk.
• Business unit or product strategy – How a given business wins in its market: segments, positioning, pricing logic, channel.
• Functional strategy – How a function (including IT, HR, finance) builds the capabilities and service model the business strategy requires.

IT and software sit in a dual role. They are a function that must run reliable platforms, security, and economics. They are also often the delivery engine for product and operating capabilities – data, automation, customer-facing systems – that make the business strategy real.

Misalignment usually happens when IT is treated only as a cost center and order-taker: tickets flow in, priorities shift weekly, and nobody connects backlog ordering to business outcomes. Alignment improves when IT leadership participates in the same conversation as product and finance about which bets matter and what “good” looks like in numbers – not only in release dates.

Translating strategy into IT: a chain, not a slogan

Treat delivery as a chain of outcomes, each layer testable:

1. Business outcomes – What must improve for the firm to win or survive? Examples: margin in a segment, cost to serve, compliance posture, time-to-market in a channel.
2. Product or programme outcomes – Which customer or user behaviors, or which internal capabilities, would plausibly drive those business outcomes?
3. Team-level outcomes – What will teams ship or change this quarter or half-year, and how will they know it worked? Prefer measures of effect, not effort.
4. Backlog and technical work – Features, platforms, integrations, reliability work, and debt paydown – ordered against the outcomes above, not only against who shouts loudest.

Bring non-negotiables into the room early: regulatory rules, security and privacy requirements, brand risk, unit economics. They become architecture choices, service-level objectives, and acceptance criteria – not surprises in late testing.

A frequent mistake is to equate progress with activity: story points, velocity, tickets closed. Activity is easy to measure; it does not prove strategic progress. Prefer evidence tied to behavior or value: adoption of a flow, fewer failed transactions, latency under a threshold, revenue through a path you deliberately changed, or support volume on a problem you targeted.

Example (composite, anonymized). A B2B firm’s business outcome is to reduce churn in mid-market accounts. The product hypothesis is that customers leave because onboarding takes too long. Programme outcomes might include “80% of new accounts complete a core setup path within 14 days.” Team outcomes might be shipping guided setup, integrating CRM data to pre-fill fields, and cutting a specific error rate – each with a measurable key result. The backlog lines up to those outcomes; work that only adds peripheral features drops in priority unless the diagnosis changes.

Instruction: how to create a business strategy for an IT project

Treat this as a workshop script, not a slide title. The owner should be the business sponsor together with the product lead; engineering signs for feasibility. Aim for under two pages; if it balloons, you are writing a backlog, not a strategy.

Steps (do them in order):

1. Anchor the initiative – Name the programme or product, the sponsor, the review horizon (for example two quarters), and where this initiative sits in the parent company strategy (link, OKR, or “not written yet – we record assumptions below”).
2. Write the diagnosis – In plain language: what is the crux of the problem, who is affected, what changed in the market or internally, and what proves the pain is real (data, churn, cost, incidents). No solution yet. If the pain is commercial, add a snapshot of how money is made today (segments, margin, discounts) – that is the business model reality your strategy will change; see Business model vs business strategy above.
3. State the strategic intent – One sentence: We believe that by [lever] we will move [business outcome] because [theory]. If you cannot state a falsifiable belief, you are still at slogans.
4. Choose the guiding policy – At most three principles that decide trade-offs (for example: “self-serve before hire-more-support,” “integrate with system X before building parallel data”). These are the rules for saying no.
5. Define the outcome chain – Fill one row per layer: business outcome, product or programme outcome, team outcomes for the next period – each with a metric or observable evidence and a named owner. If a layer has no metric, it is a wish, not a strategy.
6. List non-negotiables – Regulatory, security, privacy, reliability, brand, contractual SLAs. These become architecture and acceptance criteria, not a late surprise.
7. Declare “will not do” – Three to seven items explicitly out of scope for this horizon. If the list is empty, you do not have focus.
8. Pick the first validation slice – The smallest release, pilot, or experiment that tests the belief in step 3. State what evidence would falsify the strategy and trigger a rethink.
9. Set the review cadence – When the group revisits this document (for example mid-quarter and end-quarter). Strategy is recurrent, not a kickoff-only artifact.

Template: one-page business strategy for an IT project

Copy the block below into your tool of choice. Replace the brackets with your answers; keep bullets short.

TITLE: [Programme / product name] – Business strategy snapshot
SPONSOR: [Name, role]     HORIZON: [e.g. Q3–Q4 2026]     LAST UPDATED: [date]

PARENT STRATEGY / OKR LINK:
[URL or reference, or: Assumptions: …]

1. DIAGNOSIS (facts + crux; no solution yet)
[2–5 sentences: problem, who hurts, evidence, what happens if we do nothing]

2. STRATEGIC INTENT (one sentence)
We believe that by _____________________________ we will improve _____________________________
because _______________________________________.

3. GUIDING POLICY (max 3 trade-off rules)
• 
• 
• 

4. OUTCOME CHAIN (each row must have a measure or observable)
Business outcome:        [metric / evidence]     Owner:
Product/programme outcome: [metric / evidence]     Owner:
Team outcomes (this period): [metric / evidence]     Owner:

5. NON-NEGOTIABLES
Regulatory / legal:
Security / privacy:
Reliability / SLO:
Other:

6. OUT OF SCOPE (this horizon; be explicit)
• 
• 
• 

7. FIRST VALIDATION SLICE
Smallest release or experiment:
What would prove us wrong:

8. REVIEW DATE
Next strategy review: [date]   Participants: [roles]

If you already use OKRs, map one programme-level objective to box 2 and put the key results in row 4. If you do not use OKRs, the table in section 4 is still the minimum viable “strategy on one page.”

Example: filled template (composite, anonymized)

The company and numbers below are illustrative – they show the level of specificity you want, not a real client.

TITLE: Northwind Analytics Cloud – Business strategy snapshot
SPONSOR: Alex Morgan, VP Revenue     HORIZON: next two quarters     LAST UPDATED: 2026-04-09

PARENT STRATEGY / OKR LINK:
Company OKR: “Grow net revenue retention in mid-market (500–5,000 employees) from 108% to 118% by FY-end.”
Product line strategy doc: /strategy/northwind-midmarket (internal wiki)

1. DIAGNOSIS (facts + crux; no solution yet)
Mid-market accounts show 22% gross churn annualized vs 12% in enterprise. Exit interviews and support tags cluster on “time-to-first-value”: teams stall in week 2–4 of onboarding. Sales promises API parity and custom SSO; delivery is a generic checklist with no guided path. Competitors ship opinionated onboarding in under a week. If we only add features without fixing onboarding flow, churn stays structurally high.

2. STRATEGIC INTENT (one sentence)
We believe that by shipping a guided onboarding path with CRM-assisted setup and measurable completion milestones we will reduce mid-market gross churn from 22% to 16% within two quarters because today’s drop-off is concentrated before users reach their first successful analytics export.

3. GUIDING POLICY (max 3 trade-off rules)
• Self-serve completion before “build custom services” – professional services only after baseline path is live.
• Integrate with Salesforce and Okta first – defer other IdPs until the core path converts.
• Instrument every step – no new onboarding UI without event tracking and funnel visibility.

4. OUTCOME CHAIN (each row must have a measure or observable)
Business outcome: Mid-market gross churn 22% → ≤16%; NRR in segment +3 pp vs baseline.     Owner: VP Revenue (Alex)
Product/programme outcome: ≥80% of new mid-market accounts complete “core setup path” within 14 days (defined checklist in product).     Owner: Head of Product (Jordan Kim)
Team outcomes (this period): Ship guided setup v1 + CRM pre-fill; cut setup-related P1 tickets by 40% vs prior quarter; error rate on SSO callback under 0.5%.     Owner: Engineering lead (Sam Okonkwo)

5. NON-NEGOTIABLES
Regulatory / legal: GDPR + DPA with customers; no subprocessor changes without legal sign-off.
Security / privacy: SSO via Okta first; audit log for admin setup actions; secrets in vault only.
Reliability / SLO: Core setup API p95 under 400 ms in EU-West; maintenance windows announced 7 days ahead.
Other: No storing customer CRM payloads outside EU region for EU tenants.

6. OUT OF SCOPE (this horizon; be explicit)
• Net-new analytics chart types and custom report builder
• Mobile app onboarding (web only)
• Additional IdPs beyond Okta (Azure AD, etc.)
• Re-architecture of the batch data pipeline (unless a P1 blocker)

7. FIRST VALIDATION SLICE
Smallest release or experiment: Guided setup for mid-market SKUs only (feature flag); Salesforce OAuth pre-fill for account name + user roster; one “success” screen after first export.
What would prove us wrong: Completion rate does not move after 6 weeks, or support volume shifts to “missing data” (pipeline) instead of “stuck in setup” – then we revisit whether onboarding is the real crux.

8. REVIEW DATE
Next strategy review: 2026-05-15 (mid-quarter) and 2026-07-01 (end horizon)   Participants: sponsor, product, engineering lead, customer success lead

Where OKRs and KPIs fit (and where they do not)

Structured goal systems – objectives and key results (OKRs) – popularized in John Doerr’s Measure What Matters and rooted in practices at Intel and Google – help organizations execute once direction exists. An objective states what must be achieved; key results are the measurable outcomes that prove progress, usually time-bound and verifiable. Well deployed, such systems make priorities visible, align teams across silos, and force conversations about trade-offs.

They are not a substitute for strategy. They do not replace judgment, leadership, or a healthy culture of debate. Used carelessly, any goal system can distort behavior (narrow focus, sandbagging, gaming metrics). The safeguard is to tie goals to the mission, review them when facts change, and pair numbers with qualitative judgment – especially for quality, risk, and customer trust.

For IT projects, the practical lesson is this: cascading goals can give a shared language between executives and delivery teams, but someone must still perform the strategic work – naming the challenge, choosing what not to build, and explaining how software advances the firm’s theory of advantage.

Failure modes you may recognize

• Strategy theater – Polished decks and offsite workshops, but no real trade-offs. Every team optimizes locally; the portfolio adds up to motion, not advantage.
• Mistaking goals for strategy – OKRs and KPIs everywhere, but no diagnosis of the actual constraint. People hit targets that do not matter.
• Feature factory – High output and busy roadmaps, weak evidence of impact. Shipping is confused with success.
• Ignoring the weakest link – Excellent engineering in one layer while data quality, identity, support tooling, or go-to-market caps the outcome. Local heroics do not fix a broken chain.
• Static roadmap as contract – The plan becomes a commitment device instead of a hypothesis to validate. Learning is treated as failure instead of input.

Quick verification before you fund work

Use this as a final pass after the one-pager is drafted (it mirrors the template, not a second framework):

1. Is the diagnosis specific enough that a stranger sees the crux, not generic “digital transformation”?
2. Does strategic intent name a belief we could be wrong about?
3. Does every row in the outcome chain have a measure or observable, not just activity?
4. Is out of scope non-empty and agreed with the sponsor?
5. Are non-negotiables listed before architecture and sprint work start?

Strategy is about action. IT projects are where strategy becomes systems, data flows, and operations. When the one-pager’s outcome chain is explicit, technology can stop behaving like an order-taker for a vague wish list and start acting as a partner in a testable plan – one quarter, one bet, one measured result at a time.

Product and delivery health: optional diagnostics

A one-pager does not prove that product choices or the delivery loop actually support the strategy. Pragmatic Coders publishes two complementary checklists for a quick stress-test: the Product Health Checklist (PHC 2.0):

FAQ

Further reading

Frameworks and vocabulary above draw on established work on strategy and goal systems. For readers who want the primary sources in full:

• Richard P. Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters – publisher page (Penguin Random House)
• John Doerr, Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs – publisher page (Penguin Random House)

Supplementary articles (Polish – Sellwise) – B2B framing on rolling strategy into practice, company vs sales/marketing level, and business model vs strategy (see also Business model vs business strategy above):

• Strategia w biznesie – jak skutecznie ją wdrożyć
• Strategia firmy – czym różni się od strategii sprzedaży i marketingu
• Strategia biznesowa vs model biznesowy