Marketing strategy: Strategy with purpose

Start with a business problem

Marketing strategy starts with a business problem that somebody can explain without naming a channel. Who is the audience, what is the offer and what useful action should follow? Those three questions expose gaps that another package of activity will not fix. Write the problem in a way that a colleague can challenge. If success depends on an assumption about demand, price or trust, make that assumption visible before selecting the work.

Read about FuckAllAgencies’s approach to see why the proposed working relationship starts with a business problem and evidence. That context helps distinguish a useful strategy brief from a request for activity without an agreed purpose.

A marketing strategy note should explain the business problem before listing activities. Ask whether another person can name the audience, offer and intended action after reading it, without requiring a separate presentation to interpret the objective.

An offer people can understand

A clear proposition connects a customer need with a credible offer and an understandable next step. Remove claims that the business cannot substantiate. Distinguish an advantage from a slogan and explain why the intended audience should care. A page, campaign or message should support that explanation consistently. Stronger wording cannot rescue an offer whose terms remain unclear. Establish the substance first, then choose a presentation that makes it easier to understand.

Test a marketing strategy proposition by separating approved facts from persuasive language. Identify the evidence behind each substantive claim, the terms affecting the offer and the action that the visitor can genuinely take next.

Continue with A clearer brief.

Choose priorities deliberately

Priorities should reflect the problem rather than a standard monthly checklist. Some work improves understanding, some removes friction and some tests an assumption. Decide which of those jobs matters first. Identify what would make a task unnecessary, and avoid measuring progress only by the amount produced. A smaller set of coherent actions can be easier to assess than a crowded collection of disconnected outputs. The brief should show why each deliverable exists.

Order the work by the decision it supports. A task that clarifies the offer may come before a channel experiment; a task that removes a broken enquiry path may deserve attention before producing additional material.

AI where it helps

AI can support a marketing workflow when the input, expected output and human review are defined. Drafting alternatives, organising information and summarising an approved report are possible tasks to discuss; they are not a claim that an automated product is installed here. Human judgement remains responsible for facts, brand decisions and release. Follow the AI workflows page to examine the limits of one proposed task before adding more automation.

Describe an AI-assisted task using an input, expected output and review decision. If those elements are unclear, resolve the workflow question before treating a tool’s convenience as evidence that automation belongs in the project.

Measurement before claims

Define the evidence before describing an activity as successful. A channel metric, an enquiry and a completed sale answer different questions. Identify the source, baseline period and relevant exclusions. Changes outside the project can affect the result, so attribution needs a stated method. The measurement page explains that distinction. A report should make a decision easier, not turn a convenient number into an unsupported claim about business impact.

A measurement discussion should identify what would change your decision. Ask whether the proposed evidence can distinguish useful progress from activity, and whether another business change could explain the same observation.

Continue with A clearer brief.

A practical brief

A practical brief names the scope, responsibilities, deliverables and decisions that will be reviewed. Include the dependencies that could delay or change the work. Decide who supplies approved facts and who can accept a proposed release. Use the process page to connect those details. A brief is most useful when it can expose disagreement early, before a vague objective becomes a large list of tasks nobody can evaluate consistently.

The brief should identify what needs agreement now and what can be decided later. Separating those decisions helps avoid treating an unresolved dependency as a fixed commitment or asking production work to solve a strategic disagreement.

Bring the problem, not a package

Bring the business question to the conversation rather than choosing a generic package first. Describe the offer, audience and action that matters, then explain what has already been tried at a high level. Do not send account passwords or customer records in an initial email. Specific services, access and commercial terms are discussed for the proposed scope. The point is a clearer decision about useful work, without fabricated case studies or a universal performance promise.