Complete this here or copy it into your own document. Edits are not saved when you leave the page.

Copy template

A quick stocktake of a business's internal strengths and weaknesses against external opportunities and threats, before deciding what to do about any of them.

Strengths: What the business does well, relative to competitors
Weaknesses: Where it falls short, relative to competitors
Opportunities: External trends or gaps it could exploit
Threats: External risks that could hurt it

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Strengths: Deep integration with the retailers' existing POS systems, built over 6 years
Weaknesses: Sales cycle averages 90 days against a market norm closer to 45
Opportunities: Two large competitors have just been acquired and are distracted by integration
Threats: A well-funded new entrant is undercutting on price by 30%

What it leaves out. No weighting between items, and no evidence standard: a strength backed by data sits next to one that's just an opinion, with nothing to tell them apart.

Use instead when. Porter's Five Forces, when the question is specifically about competitive pressure rather than a general stocktake.

Assessing how much competitive pressure an industry puts on the businesses in it, and therefore how much of the value they create they'll actually keep.

Threat of new entrants: How easily a new competitor could enter
Bargaining power of suppliers: How much suppliers can dictate terms
Bargaining power of buyers: How much customers can dictate terms
Threat of substitutes: How easily customers could switch to something else
Rivalry among existing competitors: How intensely current players compete

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Threat of new entrants: Low: the software and integrations take years to replicate
Bargaining power of suppliers: Low: cloud infrastructure is a commodity with many providers
Bargaining power of buyers: High: large retail chains can and do negotiate hard on price
Threat of substitutes: Medium: spreadsheets and manual reporting are a real, if worse, substitute
Rivalry among existing competitors: High: four well-funded competitors chase the same accounts

What it leaves out. Partners and regulation. The original model has no sixth force for complementors or for the kind of regulatory shift that can reshape a market overnight.

Use instead when. SWOT, for a faster, less structured first pass, or PESTLE when the driving forces are macro rather than competitive.

Scanning the macro environment a business operates in, across six categories, so a strategy isn't blindsided by a trend nobody was watching.

Political: Government policy and stability
Economic: Growth, rates, inflation, currency
Social: Demographics, attitudes, behaviour
Technological: New technology changing what's possible
Legal: Laws and regulation specific to the business
Environmental: Climate and sustainability pressures

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Political: Data-residency rules are tightening across the EU market it sells into
Economic: Retail customers are cutting discretionary software spend as margins tighten
Social: Store managers increasingly expect consumer-grade, self-serve tools at work
Technological: Generative AI is lowering the cost of building basic reporting tools in-house
Legal: The EU AI Act now applies to some of its forecasting features
Environmental: Retailers are asking vendors to report the carbon footprint of their own operations

What it leaves out. Prioritisation. PESTLE is good at listing what could matter, and says nothing about which of the six actually does.

Use instead when. Porter's Five Forces, once the macro scan has narrowed the question to competitive dynamics specifically.

Mapping growth options along two axes, new versus existing products and new versus existing markets, with risk rising the further a business moves from what it already knows.

Market penetration: Existing products, existing markets
Product development: New products, existing markets
Market development: Existing products, new markets
Diversification: New products, new markets

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Market penetration: Sell more analytics seats into the retailers it already serves
Product development: Build a new forecasting module for the same retail customer base
Market development: Take the existing product into hospitality, a market it doesn't serve yet
Diversification: Launch a consulting arm for a different industry entirely: the highest-risk quadrant

What it leaves out. How. Ansoff says where the risk rises, not how to execute any of the four options, or which one the business is actually capable of pulling off.

Use instead when. The Opportunity Tree, when the question is which specific bets within a quadrant are worth testing.

Classifying a portfolio of products or business units by market growth and relative market share, to decide where to invest, hold or exit.

Stars: High growth, high share: invest to maintain
Cash Cows: Low growth, high share: harvest the cash
Question Marks: High growth, low share: invest selectively or exit
Dogs: Low growth, low share: divest or run for minimal cash

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Stars: The forecasting module, growing fast with a strong lead over competitors
Cash Cows: The core reporting product, mature and profitable but growing slowly
Question Marks: A new AI-copilot feature in a growing category where the business isn't yet the leader
Dogs: A legacy on-premise version few customers still use

What it leaves out. Market share and growth aren't the only things that predict future value, and 'relative market share' is often harder to measure honestly than the two-by-two makes it look.

Use instead when. A weighted-scoring model, when more than two factors genuinely drive the investment decision.

Tracking performance across four perspectives so a business doesn't manage to financial results alone while the things that produce them go unwatched.

Financial: Results that matter to owners and investors
Customer: How customers experience the business
Internal Process: How well core processes run
Learning and Growth: Whether people and systems are improving

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Financial: Revenue growth of 18% year over year
Customer: NPS holding at 42 despite faster growth
Internal Process: Support ticket resolution time down from 3 days to 1
Learning and Growth: Engineering onboarding time cut from 6 weeks to 3

What it leaves out. It doesn't say which perspective should win when two point in different directions, and it can multiply into more metrics than any team can actually act on.

Use instead when. OKRs, when the organisation needs a smaller number of focused, time-boxed priorities rather than an ongoing scorecard.

Setting a qualitative, ambitious Objective and pairing it with a small number of measurable Key Results, so a team knows both what it's aiming for and how it'll know if it got there.

Objective: A qualitative, ambitious statement of intent
Key Results: 2 to 5 measurable results that would mean the objective was met

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Objective: Make onboarding fast enough that new customers never need to ask for help · Key Results: 1) Time-to-first-report falls from 9 days to 3. 2) Support tickets tagged 'onboarding' fall by 50%. 3) Self-serve setup completion rate rises from 40% to 75%

What it leaves out. OKRs say nothing about resourcing or sequencing; a team can set an ambitious objective with key results it has no realistic capacity to move.

Use instead when. A Balanced Scorecard, when the need is ongoing operational tracking rather than a time-boxed stretch goal.

A checklist for writing a goal precisely enough that two different people would agree, without discussion, on whether it was met.

Specific: Precisely what will change
Measurable: A number that proves it
Achievable: Realistic given resources
Relevant: Connected to what actually matters
Time-bound: A deadline

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Specific: Reduce customer churn among retail accounts
Measurable: From 6% monthly to 4% monthly
Achievable: Judged achievable given two dedicated customer-success hires already budgeted
Relevant: Directly protects the recurring revenue base the growth plan depends on
Time-bound: By the end of Q2

What it leaves out. Meeting all five letters doesn't make a goal a good one; a SMART goal can still be the wrong goal to be chasing.

Use instead when. OKRs, when the goal needs to be ambitious rather than safely achievable.

Naming exactly one person Accountable for a decision or task, so responsibility doesn't quietly diffuse across a group that all assumed someone else had it.

Responsible: Does the work
Accountable: Owns the outcome and signs it off, exactly one person
Consulted: Gives input before the decision, two-way conversation
Informed: Told after the decision, one-way update

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Responsible: the analytics engineer who builds the new retention dashboard
Accountable: the head of product, who signs off that it's ready to ship
Consulted: the customer-success lead, asked which segments matter most before the build starts
Informed: the wider product team, told once the dashboard goes live

What it leaves out. Meeting all four letters doesn't guarantee a good decision; a RACI describes who is involved, not whether the decision itself is the right one.

Use instead when. A simple owner-and-due-date list, for small tasks where a full RACI is more process than the task warrants.

Scoring backlog items on a common scale so competing feature requests can be compared on more than gut feel.

Reach: How many people it affects per period
Impact: How much it affects them, on a fixed scale
Confidence: How sure the team is about the estimate
Effort: Person-weeks to build it

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Reach: 2,000 users a quarter
Impact: 2 (high, on a 0.25 to 3 scale)
Confidence: 80%
Effort: 4 person-weeks

What it leaves out. The confidence number is a guess dressed up as a percentage; it can make a shaky estimate look more rigorous than it is.

Use instead when. MoSCoW, when the conversation is about what must ship this release rather than a comparative score.

Sorting requirements into four bands of necessity for a fixed release, so scope discussions are about trade-offs rather than everything being 'important'.

Must have: Release fails without it
Should have: Important but not release-blocking
Could have: Desirable if time allows
Won't have (this time): Explicitly out of scope for now

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Must have: CSV export of the core report
Should have: Scheduled email delivery of reports
Could have: A dark-theme option
Won't have (this time): A native mobile app

What it leaves out. No ordering inside 'Must': ten must-haves are still ten competing priorities, and MoSCoW doesn't say which comes first.

Use instead when. RICE or weighted scoring, when the team needs a rank order, not just four buckets.

Classifying features by how satisfaction responds to their presence, to separate what merely avoids complaints from what actually delights.

Basic: Expected; its absence causes dissatisfaction, its presence isn't noticed
Performance: More is better, in a roughly straight line
Delighter: Unexpected; absence isn't missed, presence creates disproportionate satisfaction
Indifferent: Customers don't care either way
Reverse: Some customers actively dislike it

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Basic: Login working reliably
Performance: Report generation speed
Delighter: An AI-written summary nobody asked for but loves
Indifferent: A choice of five chart colour themes
Reverse: Frequent 'what's new' pop-ups

What it leaves out. It needs a proper paired survey (a functional and a dysfunctional question per feature) to classify correctly; guessing the category from a meeting defeats the point of the model.

Use instead when. Weighted scoring, when there's no time to run the Kano survey and a rougher score will do.

Ranking options against several criteria at once, each weighted by how much it matters, so the final order reflects more than one factor.

Criteria: The factors that matter, e.g. revenue impact, effort, strategic fit
Weights: Each criterion's importance, summing to 100
Scores: Each option rated 1 to 5 against each criterion
Weighted total: Score × weight, summed per option

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Criteria: Revenue impact (50), effort (30), strategic fit (20)
Weights: Weights as listed, summing to 100
Scores: Feature X scores 4, 2, 5 on the three criteria
Weighted total: (4×50)+(2×30)+(5×20) = 460, compared against every other option's total

What it leaves out. The weights themselves are a judgement call, usually made by whoever runs the exercise; the model hides that argument inside a number that looks objective.

Use instead when. RICE, when the criteria are specifically reach, impact, confidence and effort rather than a custom set.

A fast, low-overhead scoring method for ranking experiment or feature ideas when RICE's extra rigour isn't worth the time it takes.

Impact: How much it could move the goal, 1 to 10
Confidence: How sure the team is, 1 to 10
Ease: How simple it is to do, 1 to 10

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Impact: 8 (could meaningfully lift activation)
Confidence: 6 (some evidence, not proven)
Ease: 7 (small change to onboarding copy)

What it leaves out. Three single-digit scores multiplied together give a false sense of precision to what are really three rough guesses.

Use instead when. RICE, when reach needs to be counted separately from impact rather than folded into one number.

A marketing funnel model for mapping activity to the customer journey stage it actually serves.

Reach: Get in front of people
Engage: Get attention and interaction
Activate: Convert interest into a first action
Nurture: Keep existing customers engaged

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Reach: Paid search campaigns targeting retail ops managers
Engage: A benchmark report gated behind an email address
Activate: A free trial signup
Nurture: A quarterly email showing the customer their own usage trends

What it leaves out. It doesn't separate acquisition from retention economics; a channel can look good on reach and engage while quietly losing money once nurture cost is counted.

Use instead when. AARRR, when the business needs to track revenue and referral explicitly, not just the top-of-funnel stages.

A digital marketing planning framework covering the full cycle from reach to loyalty, used to structure a marketing plan stage by stage.

Reach: Build awareness and traffic
Act: Encourage interaction and leads
Convert: Turn leads into customers
Engage: Build loyalty and advocacy after purchase

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Reach: SEO content targeting retail-analytics search terms
Act: A downloadable ROI calculator
Convert: A sales-assisted trial-to-paid conversion process
Engage: A customer community and quarterly product-council calls

What it leaves out. RACE is a planning structure, not a measurement system; it doesn't say which metric proves each stage is actually working.

Use instead when. REAN, for a lighter-weight version of the same idea when a full planning cycle isn't needed.

Tracking a product-led growth funnel across five stages, from first contact through to the revenue and referral it eventually produces.

Acquisition: Users find the product
Activation: Users have a good first experience
Retention: Users come back
Referral: Users tell others
Revenue: Users pay

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Acquisition: 1,000 sign-ups a month from organic and paid search
Activation: 38% reach the activation event within 7 days
Retention: Week-4 retention holds at 31%
Referral: 12% of active users refer at least one colleague
Revenue: 15% of trials convert to paid

What it leaves out. Treating the five stages as a strict funnel can hide that real usage loops back and forth between them rather than moving neatly in one direction.

Use instead when. A cohort retention curve, when the retention stage specifically needs more resolution than one summary number.

A fast qualification checklist for deciding whether a sales opportunity is worth pursuing now.

Budget: Is there money allocated or available
Authority: Is the buyer able to decide
Need: Is there a real, acknowledged problem
Timeline: Is there a decision date

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Budget: No dedicated budget line yet
Authority: Talking to a manager, not the economic buyer
Need: Strong: month-end close takes 9 days and they want it faster
Timeline: No firm date; still evaluating

What it leaves out. Leading with budget filters out early-stage deals where a real need exists but the budget conversation hasn't happened yet; it's built for a transactional sale, not a considered one.

Use instead when. MEDDIC or SPICED, for a longer, more complex sales cycle where budget alone doesn't capture the risk.

A rigorous qualification framework for complex, multi-stakeholder B2B deals, built around proving the deal is real rather than just hoped for.

Metrics: The quantified business outcome
Economic buyer: Who actually controls the budget
Decision criteria: How the choice will be made
Decision process: The steps and timeline to a decision
Identify pain: The specific, acknowledged problem
Champion: An internal advocate with real influence
Paper process: Legal, procurement and security steps (the two extra letters in MEDDPICC)
Competition: Who else is being considered

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Metrics: Cut month-end close from 9 days to 4
Economic buyer: The CFO, confirmed but not yet met
Decision criteria: Accuracy, integration effort and total cost, in that order per the buyer
Decision process: Committee review in March, board sign-off in April
Identify pain: Finance team spends two extra days a month firefighting bad numbers
Champion: The FP&A lead, who requested the trial and presents internally
Paper process: 12-week procurement cycle with a security review
Competition: Two competitors, one incumbent

What it leaves out. It's heavy for small or short-cycle deals; running full MEDDPICC on a €5k deal costs more sales time than the deal is worth.

Use instead when. BANT, for a faster read on a smaller or more transactional deal.

A qualification framework built around the situation and the business impact of a problem, used to keep a sales conversation focused on value rather than features.

Situation: The buyer's current state
Pain: The specific problem
Impact: What the pain actually costs
Critical Event: A deadline that forces a decision
Decision: How and by whom the choice gets made

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Situation: Finance runs month-end manually across four spreadsheets
Pain: Close takes 9 days, twice the industry norm
Impact: Two analysts' time, plus late board reporting
Critical Event: The new CFO wants a faster close by Q3
Decision: CFO decides, FP&A lead influences, procurement executes

What it leaves out. No explicit budget question; a deal can score well on every element and still stall because nobody has confirmed the money exists.

Use instead when. BANT, when budget needs to be qualified early and explicitly rather than inferred from impact.

Reframing what a customer wants in terms of the progress they're trying to make, so a product is designed around the job, not just the demographic who happens to buy it.

Job statement: When [situation], I want to [motivation], so I can [outcome]
Functional dimension: The practical task
Emotional dimension: How they want to feel doing it
Social dimension: How they want to be seen doing it

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Job statement: When month-end arrives, I want to close the books without a fire drill, so I can report accurate numbers on time
Functional dimension: Produce a management pack with correct figures
Emotional dimension: Feel confident presenting to the board, not anxious about errors
Social dimension: Be seen by the CFO as reliable and in control of the numbers

What it leaves out. A job statement describes the need well but says nothing about willingness to pay, market size, or whether the business can build a solution profitably.

Use instead when. The Opportunity Solution Tree, once the job is understood and the question becomes which solution to build.

Connecting a single measurable outcome to the customer opportunities (needs and pain points) that could move it, and the solutions and tests under each, so discovery work stays traceable to a real goal.

Outcome: A measurable change, not a feature
Opportunities: Customer needs found in research
Solutions: Ideas that could address an opportunity
Assumption tests: Small tests of a solution's riskiest assumption

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Outcome: Raise week-4 retention from 34% to 40%
Opportunities: Users lose track of reports they've already built
Solutions: A 'recent reports' shortcut on the home screen
Assumption tests: A 5-user prototype test of the shortcut before building it

What it leaves out. It doesn't account for delivery capacity or dependencies between teams; a well-formed tree can still describe more work than the team can deliver.

Use instead when. An Experiment Plan, once a specific solution and test are chosen and need a rigorous design.

Working backward from a problem by repeatedly asking why, until the answer points at a system or process rather than a person.

The problem: Stated plainly
Why (1 to 5): Each answer becomes the next question

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: The problem: A customer report showed the wrong revenue figure · Why (1 to 5): Why 1: the wrong exchange rate was used. Why 2: the rate table hadn't been updated. Why 3: no one owns updating it. Why 4: the process was informal from the start. Why 5: there was no documented owner when the report was built

What it leaves out. It stops at one causal chain when real incidents usually have several contributing factors running in parallel, not a single line of dominoes.

Use instead when. Fishbone, when there are multiple plausible categories of cause to explore rather than one clear thread to pull.

Mapping every plausible category of cause behind a problem at once, using six standard bones, so a team doesn't fixate on the first explanation offered.

People: Skills, training, staffing
Process: How the work is done
Equipment: Tools and systems
Materials: Inputs and data
Environment: Conditions work happens in
Measurement: How the problem was detected and measured

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: People: No one trained on the FX rate process
Process: No documented step to refresh rates
Equipment: The rate table is a manually maintained spreadsheet
Materials: The upstream FX feed itself was stale
Environment: Month-end time pressure discourages double-checking
Measurement: The error was only caught because a customer complained, not by any internal check

What it leaves out. It's a structure for generating causes, not for proving which one actually mattered; without data it can produce six plausible stories and no answer.

Use instead when. Pareto, once the causes are known and the question shifts to which few are worth fixing first.

Sorting causes or items by frequency or impact to find the small number that account for most of the problem, so effort goes where it pays off.

Causes: Listed and counted
Sorted, descending: Highest-frequency cause first
Cumulative %: Running total across the sorted list
The 80% line: Where cumulative impact crosses 80%

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Causes: Six causes of failed month-end closes, counted over a quarter
Sorted, descending: Stale FX rates (14), late supplier invoices (9), manual entry errors (6), system downtime (3), staff absence (2), other (1)
Cumulative %: 40% / 66% / 83% / 91% / 97% / 100%
The 80% line: The first three causes account for 83% of incidents: fix those before touching the rest

What it leaves out. It assumes the causes are independent and equally easy to fix; the biggest bucket isn't always the cheapest or most urgent one to address.

Use instead when. Fishbone, before Pareto, when the causes themselves aren't known well enough yet to count.

A five-phase structure for improving an existing process, used in Six Sigma to move from a vague complaint to a controlled, measured fix.

Define: The problem and goal
Measure: Current performance, with data
Analyse: Root causes
Improve: Test and implement a fix
Control: Sustain the improvement

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Define: Month-end close takes 9 days against an 5-day target
Measure: Baseline: 9.2 days average over the last two quarters
Analyse: Root cause: manual FX rate updates, found via Fishbone and Pareto
Improve: Automated daily rate feed, piloted for one quarter
Control: A dashboard alert if the feed goes stale, reviewed monthly

What it leaves out. It's built for improving a process that already exists; it isn't a design method for building something new from scratch.

Use instead when. PDCA, for a lighter-weight, faster improvement cycle that doesn't need Six Sigma's full statistical rigour.

A simple, repeatable improvement loop for testing a change on a small scale before committing to it fully.

Plan: Define the change and expected effect
Do: Try it on a small scale
Check: Measure what actually happened
Act: Roll out, adjust, or abandon

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Plan: automate FX rate updates for one legal entity
Do: run it for one month-end cycle
Check: close time for that entity fell from 9 to 6 days
Act: roll out to the remaining entities

What it leaves out. Each cycle is small and iterative by design, so it's a poor fit for a problem that genuinely needs one coordinated, large-scale change.

Use instead when. DMAIC, when the problem needs a full root-cause analysis before any fix is attempted.

Improving the throughput of a whole system by finding and managing its single biggest bottleneck, rather than optimising every step equally.

Identify the constraint: Find the slowest step
Exploit it: Get the most from it without new investment
Subordinate everything else: Align other steps to the constraint's pace
Elevate the constraint: Invest to increase its capacity
Repeat: Find the new constraint

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Identify the constraint: Loading, handling 310 orders a day against 400 of demand
Exploit it: Remove non-essential stops at the loading bay
Subordinate everything else: Slow picking and packing down to match loading's pace rather than overproducing
Elevate the constraint: Add a second loading bay
Repeat: Once loading clears 400, find whatever's now the next-slowest step

What it leaves out. Improving anything except the current constraint doesn't raise overall output, which makes the model easy to misapply if the constraint hasn't actually been identified correctly.

Use instead when. DMAIC, when the goal is quality and defect reduction rather than throughput specifically.

A checklist of eight waste categories used in Lean to spot activity that costs time or money without adding value the customer would pay for.

Transport: Unnecessary movement of materials or data
Inventory: Excess stock or unfinished work
Motion: Unnecessary movement of people
Waiting: Idle time between steps
Overproduction: Making more than is needed, before it's needed
Overprocessing: More effort than the customer needs
Defects: Errors requiring rework
Skills: Underused people or expertise

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Transport: A report exported, emailed, then re-imported into another tool
Inventory: A backlog of half-finished dashboards nobody's reviewing
Motion: Analysts switching between five disconnected tools to build one report
Waiting: Data sitting in a queue for two days before anyone processes it
Overproduction: Building a report nobody asked for yet, just in case
Overprocessing: A five-tab, fully formatted report for a question that needed one number
Defects: A dashboard rebuilt three times because requirements weren't confirmed first
Skills: A data engineer spending half their week on manual ticket triage instead of engineering

What it leaves out. It's a checklist for spotting waste, not a method for deciding which waste is worth the cost of removing first.

Use instead when. Theory of Constraints, when the priority is finding the one bottleneck rather than cataloguing every source of waste.

Structuring a written argument or presentation so the answer comes first, followed by the reasoning that supports it, rather than building up to a conclusion at the end.

Situation: The stable, agreed context
Complication: What's changed or gone wrong
Question: The question this naturally raises
Answer: The recommendation, stated up front

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Situation: Month-end close has taken about 9 days for two years
Complication: This quarter it slipped to 12, and the board pack was late
Question: What's causing the slippage, and what should change?
Answer: Automate FX rate updates: this alone should recover 3 of the 4 lost days

What it leaves out. It structures how an argument is presented, not whether the underlying analysis is actually correct; a badly reasoned conclusion can still be delivered in a well-structured SCQA.

Use instead when. A straightforward chronological narrative, when the audience needs to follow how a decision was reached rather than just what it is.

Choosing one metric that best captures the value a product delivers to customers, so every team can see how their work connects to it.

North Star Metric: The single measure of delivered value
Input metrics: The smaller, controllable metrics that drive it
Team ownership: Which team moves which input

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: North Star Metric: Weekly reports shared with a teammate (a proxy for real, collaborative value delivered)
Input metrics: Sign-ups, activation rate, report-creation rate, share rate
Team ownership: Growth owns sign-ups and activation; product owns report-creation and share rate

What it leaves out. A single number can be gamed or can rise for reasons unrelated to real value, and it says nothing about revenue or cost on its own.

Use instead when. A Balanced Scorecard, when the organisation needs to track financial and process health alongside product value, not product value alone.

Checking that what a product offers actually matches what a specific customer segment needs, before investing in building or selling it.

Customer jobs: What the customer is trying to get done
Pains: What frustrates them doing it
Gains: What a better outcome would look like
Products and services: What's on offer
Pain relievers: How it addresses the pains
Gain creators: How it delivers the gains

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Customer jobs: Close the books accurately every month
Pains: Manual FX updates and spreadsheet errors eat two days a month
Gains: A close that takes half the time with fewer errors
Products and services: An automated FX and reconciliation module
Pain relievers: Removes the manual update step entirely
Gain creators: Cuts close time and gives earlier, more reliable numbers to the board

What it leaves out. It maps fit on paper; it doesn't validate that customers will actually pay for the fit it describes, which still needs real testing.

Use instead when. Jobs to Be Done, when the focus should stay on the customer's need itself before any product is proposed against it.

Laying out the nine building blocks of how a business creates, delivers and captures value, on one page, so the whole model can be reviewed at once rather than piecemeal.

Customer segments: Who it serves
Value propositions: What it offers each segment
Channels: How it reaches customers
Customer relationships: How it interacts with them
Revenue streams: How it earns
Key resources: What it needs to operate
Key activities: What it must do well
Key partnerships: Who it relies on
Cost structure: What it costs to run

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Customer segments: Mid-size retail finance and operations teams
Value propositions: Faster, more accurate month-end close
Channels: Direct sales and a self-serve trial
Customer relationships: Named account management for larger customers
Revenue streams: Per-seat subscription, billed annually
Key resources: Engineering team, cloud infrastructure, the product itself
Key activities: Product development, customer support, sales
Key partnerships: Cloud hosting provider, data-integration partners
Cost structure: Engineering salaries, cloud hosting, sales and marketing

What it leaves out. It describes a model, it doesn't test whether the model actually works; nothing on the canvas proves customers will pay what the revenue-stream box assumes.

Use instead when. A Value Proposition Canvas, when the question narrows to fit between one segment and one offer rather than the whole business model.

Forcing a strategy into five sequential, mutually dependent choices, so 'strategy' means more than a list of goals or initiatives.

Winning aspiration: What winning looks like
Where to play: Which segments, geographies, channels
How to win: The basis for winning there
Capabilities required: What must be true internally
Management systems: What's needed to sustain it

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Winning aspiration: Become the default analytics layer for mid-size retail finance teams
Where to play: UK and Nordic retailers, 50 to 500 stores, via direct sales
How to win: Fastest time-to-first-value in the category, not lowest price
Capabilities required: A self-serve onboarding flow good enough to sell itself
Management systems: A weekly activation-metrics review the whole company sees

What it leaves out. It's a logical structure for the choices, not a method for making them; it doesn't tell a business which 'where to play' or 'how to win' is actually correct.

Use instead when. A Business Model Canvas, when the need is to describe the full operating model rather than force five strategic choices.

Sizing a market in three nested circles, from the total theoretical demand down to what a specific business can realistically capture, so a growth plan is grounded in a real ceiling.

TAM: Total addressable market: everyone who could ever want this
SAM: Serviceable available market: who the business could actually reach and serve
SOM: Serviceable obtainable market: what it could realistically win

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: TAM: All mid-size retailers globally needing finance analytics: roughly €2bn
SAM: UK and Nordic mid-size retailers it can sell and support today: roughly €180m
SOM: A realistic 3-year share of that, given sales capacity: roughly €9m

What it leaves out. It says nothing about the path or the years it takes to move from TAM to SOM, and each circle is only as reliable as the assumptions behind it.

Use instead when. The Market Sizing Guide's top-down/bottom-up reconciliation, when a single number needs to be checked against two independent methods.

Finding an acceptable price range by asking customers four questions about price, rather than asking them directly what they'd pay.

Too cheap: At what price would you doubt the quality?
Cheap / good value: At what price does it start to seem like a bargain?
Expensive: At what price does it start to seem expensive?
Too expensive: At what price would you not consider it at all?

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Too cheap: Below €15/seat/month
Cheap / good value: Around €25/seat/month
Expensive: Around €55/seat/month
Too expensive: Above €80/seat/month

What it leaves out. It reveals a range of acceptable prices, not the price that maximises revenue or profit; that still needs to be chosen within the range it produces.

Use instead when. Gabor-Granger, when the goal is a specific optimal price point rather than a range.

Estimating a demand curve by asking customers directly whether they'd buy at a series of specific prices, to find the price that maximises revenue.

Price points tested: A sequence of prices shown to respondents
Purchase intent per price: % who say they'd buy at each price
Implied demand curve: Purchase intent plotted against price
Revenue-maximising price: Price × implied purchase rate, at its peak

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Price points tested: €20, €30, €40, €50, €60 per seat
Purchase intent per price: 85%, 70%, 50%, 30%, 12%
Implied demand curve: A smooth downward curve from 85% to 12%
Revenue-maximising price: €40: 50% intent × €40 beats every other point tested

What it leaves out. Stated purchase intent in a survey reliably overstates real buying behaviour; it estimates a curve, not a guarantee of what people will actually pay.

Use instead when. Van Westendorp, when the goal is an acceptable range rather than a single optimised price point.

A reference map of the eleven areas that make up data management as a discipline, used to check whether a data function has a gap it hasn't noticed.

Data Governance: The centre: policy, ownership, decision rights
Data Architecture: How data structures are planned
Data Modelling and Design: How specific datasets are structured
Data Storage and Operations: Where data lives and how it's kept running
Data Security: Protecting data from misuse and breach
Data Integration and Interoperability: Moving and connecting data between systems
Document and Content Management: Managing unstructured data
Reference and Master Data: Managing shared, authoritative data
Data Warehousing and Business Intelligence: Enabling analysis and reporting
Metadata Management: Documenting what data means
Data Quality: Ensuring data is fit for purpose

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Data Governance: A data council owning definitions and access decisions
Data Architecture: A star schema plan for the analytics warehouse
Data Modelling and Design: The orders table's grain, keys and column definitions
Data Storage and Operations: A cloud data warehouse with defined refresh SLAs
Data Security: Row-level security on customer financial data
Data Integration and Interoperability: A pipeline syncing CRM and billing data nightly
Document and Content Management: A shared drive of signed customer contracts, not yet governed
Reference and Master Data: A single master customer list, deduplicated
Data Warehousing and Business Intelligence: The BI layer analysts and dashboards query
Metadata Management: A data catalogue documenting every table's owner and meaning
Data Quality: Automated checks for nulls, duplicates and out-of-range values

What it leaves out. It's a map of the discipline's scope, not a maturity model; it says what the areas are, not how good a team needs to be at each one or in what order to improve.

Use instead when. A Data Contract, when the immediate need is to formalise one specific dataset's obligations rather than assess the whole function.

Four metrics, backed by multi-year research, that together measure software delivery performance without trading speed against stability.

Deployment frequency: How often code ships to production
Lead time for changes: Time from commit to production
Change failure rate: % of deployments causing a failure
Time to restore service: How fast service recovers from a failure

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Deployment frequency: Several times a week
Lead time for changes: Under a day from commit to live
Change failure rate: Around 12%
Time to restore service: Under an hour, typically

What it leaves out. The four metrics measure delivery performance; they say nothing about whether the team is shipping the right things, only how well it ships whatever it decides to build.

Use instead when. A Balanced Scorecard, when engineering performance needs to sit alongside financial and customer measures rather than stand alone.

A voluntary US framework for managing the risks of AI systems across their lifecycle, organised into four functions.

Govern: Build a culture and structure for managing AI risk
Map: Understand the context and identify risks for a specific AI system
Measure: Assess, analyse and track identified risks
Manage: Prioritise and act on risk, and monitor over time

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Govern: An AI risk policy and a named owner for the forecasting feature
Map: Mapping who's affected if the forecast is wrong and how
Measure: Testing forecast accuracy and bias across customer segments
Manage: A rule to flag and review any forecast the model itself scores as low-confidence

What it leaves out. It's voluntary and deliberately non-prescriptive; it names the functions an organisation should cover without specifying exactly how to satisfy any of them, unlike a binding regulation.

Use instead when. The EU AI Act's risk tiers, when the AI system is sold or used in the EU and a binding legal classification is what's actually needed.

The EU's binding classification of AI systems into four risk tiers, each with different legal obligations, used to work out what compliance a given AI feature actually requires.

Unacceptable risk: Banned outright, e.g. social scoring or manipulative AI
High risk: Heavily regulated, e.g. AI used in recruitment or credit decisions
Limited risk: Transparency obligations only, e.g. users must be told they're talking to a chatbot
Minimal risk: No specific obligations under the Act

In this scenario: a 200-person B2B software company selling data-analytics tooling to mid-size retailers: Unacceptable risk: Not applicable: nothing in the product resembles this tier
High risk: A feature that used AI to auto-reject job applicants would likely sit here
Limited risk: An AI-generated report summary should disclose that it's AI-generated
Minimal risk: Most of the analytics and dashboard features fall here

What it leaves out. Classification isn't always obvious in practice; a borderline feature can sit close to a tier boundary, and the Act's guidance and enforcement are still maturing as of this check.

Use instead when. The NIST AI RMF, for a broader risk-management process alongside the EU Act's specific legal classification.

Ships this quarter, full stop.

Search fix

Important, scheduled if Must work leaves room.

Bulk export, Saved filters

Worth doing if there's spare capacity.

Faster export, Onboarding checklist

Explicitly not this quarter, says so out loud so it stops resurfacing in every planning meeting.

New dashboard

Confidence is a guess dressed up as a percentage. It's the input most often inflated.

No ordering inside “Must”, ten Musts is the same as zero Musts.

Needs an actual survey; you can't skip straight to labelling ideas in a meeting.

Hides the real argument, which is what the weights should be, inside a number that looks objective.