One funnel stage, one fix, one measurement
A sprint is a fixed number of days spent on the stage your data says is worst. Not a backlog, not a roadmap. One thing, shipped, then measured against what it was before.
- The stage is picked from your PostHog funnel, not from an opinion in a meeting
- Days agreed before the sprint starts, so it cannot quietly become a month
- Every sprint ends with a number next to the number it started from
- What we build stays in your repo, in your conventions, running without us
Sprints need a measured site. If yours is not instrumented yet, that is the build or retrofit first.
What a sprint week actually looks like
Five days is the usual shape. Some stages need eight. The days are agreed before we start, and they do not move once we have.
Day one
We read the funnel and pick the stage
Stage-by-stage conversion, session recordings on the worst step, search queries that already send traffic, the last sprint's result. You get a short write-up that says which stage leaks most and what we think is causing it.
From you: nothing yet. You get: the stage, the hypothesis, and the number we are trying to move.
Day two
You confirm the scope, we cut it down
Thirty minutes together. You tell us what you already know that the data cannot: a deal that died on pricing, a support thread that keeps repeating. Then we cut the sprint to one change, because two changes cannot both be measured.
From you: half an hour, and product facts we would otherwise guess. You get: a one-line scope you approved.
Days three and four
The change gets built in your repo
Pages, copy, forms, emails, whatever the stage needs, written in your components and your conventions. It arrives as a pull request with a preview link. If it is a test rather than a straight change, the PostHog flag and the split go in with it.
From you: a review on the preview link. You get: the change, plus the events that will judge it.
Day five
It ships, and the clock on the number starts
Someone on your team approves and it publishes. The dashboard for that stage gets the before number pinned to it, and we agree how long to wait before the after number means anything. Low-traffic pages need weeks, not days.
From you: one approval click. You get: the change live, and a read date in the calendar.
After the read date
We tell you what it did, including nothing
Before and after, on the one number we picked. Three outcomes: it moved, it did not move, or traffic was too thin to say. All three are written down, because the sprint that failed is what tells you where to look next.
From you: a decision on whether the next sprint stays on this stage. You get: the result, and the stage list reordered.
Five stages, real work
What a sprint on each stage buys you
One sprint is a slice of one of these, not the whole list. Which slice depends on where your funnel leaks.
Acquisition
Pages that pull in the right traffic
Comparison and alternative pages for the searches people already type. Integration pages, one per tool you connect to. Use-case pages per vertical. Free tools and templates that earn links. Programmatic clusters built from data you already have. Paid landing pages matched to each ad group instead of everything pointing at the homepage.
Underneath: internal linking that spreads authority, page speed, redirects that survive renames, structured data, and llms.txt so AI answers quote you instead of your competitor.
Experiments we run here: hero headline, ad-to-page message match, meta titles for click-through, whether pricing belongs on the landing page, short landing page versus long.
Activation
The path from signup to first value
Signup and trial page copy that survives the gap between the ad and the form. Shorter forms with the fields sales actually uses. Demo booking and lead routing that does not lose a lead over a weekend. An interactive demo for people who will not install anything yet. Quickstart and docs entry points aimed at the first successful action, not at feature tours.
Plus the welcome sequence: the emails between signup and the moment it clicks, written around the one action that predicts whether someone stays.
Experiments we run here: start free versus book a demo as the main CTA, interactive demo above the fold, form field count, welcome email timing, ROI calculator before or after signup.
Retention
Reasons to come back that do not need a developer
A changelog your team keeps without chasing engineers for the entry. Release-note email that goes out from the same content. Feature announcement pages that outlive the tweet. A help centre with a structure people can search. An in-app announcement surface your marketer updates herself.
Then the lifecycle work: usage reports, nudges for the feature that predicts renewal, and the emails that go out when someone stops showing up.
Experiments we run here: digest cadence, adoption nudges for a feature nobody found, search inside the docs, changelog in-app versus email.
Referral
Turning happy customers into a channel
Customer story pages a buyer would actually forward to a peer, not a logo with a quote under it. Review campaigns for G2, Capterra and TrustRadius, timed to the moment someone succeeds rather than the end of the quarter. A referral programme page with terms a customer can read in one pass. Partner and co-marketing pages.
Plus the capture side: testimonial requests wired into the product moment that earns them, and embeddable badges so customers do the linking.
Experiments we run here: when you ask for the review, how the incentive is framed, long story versus short quote, in-app ask versus email ask.
Revenue
The pages where money actually happens
Pricing page work: plan naming, the feature matrix nobody can parse, the annual toggle, usage calculators for consumption pricing. Trial-to-paid and expiry email. Checkout and upgrade copy. The enterprise and security pages procurement asks for before anyone signs anything.
Pricing sprints are the ones we scope most carefully, because a pricing change moves revenue whether or not the page was the reason.
Experiments we run here: three plans versus four, annual as default, price anchoring, the CTA on the pricing page, whether the matrix collapses by default.
Running underneath every sprint, not billed as one: event naming that stays clean as the site grows, funnel dashboards, PostHog flags for the tests, broken links and redirects, content refreshes on pages that have drifted: the killed plan still on pricing, the role you filled in March.
No promised numbers
Some sprints do not move the number
Anyone promising you a conversion lift before they have seen your funnel is guessing, and charging you for the guess. We do not do that. We pick the stage the data says is worst, change one thing, and read the result honestly. Sometimes the answer is that it did nothing.
That is not a wasted sprint. A pricing test that changes nothing tells you price was not the objection, which is worth knowing before you rewrite the pricing page for the third time. What would waste your money is changing five things at once and never learning which one mattered.
Cadence is yours to set. Most teams run one sprint a month, some run one a quarter, some run three back to back when a launch is coming and then stop for a while. There is no minimum, and nothing renews on its own. A few teams have taken the loop over entirely once they had the dashboards and the conventions, and that is a fine outcome. The site was built to run without us either way.
On the naming: acquisition, activation, retention, referral, revenue. Call the order AARRR, AAARRR or RARRA if it helps. We start where your number is worst, not where the letter comes first.
What if a sprint does not work?
That one and the rest of the questions people ask before the first sprint.
What happens when a sprint does not move anything?
You get told, in writing, with the before and after next to each other. Then we decide together whether the hypothesis was wrong or the change was too small, and whether the next sprint stays on that stage or moves. We do not quietly re-frame a flat result as a win. Nothing about the sprint is refunded, because the days were the deliverable and the finding is real work.
How long before we know if it worked?
Depends entirely on your traffic. A pricing page with thousands of weekly visitors reads in days. A comparison page with forty visitors a week will never produce a clean split test, so we judge it on rankings and traffic instead and say so up front. We agree the read date on day five, before anyone has an incentive to move it.
Who does the work, and how much of it lands on my team?
We do the building. From you: half an hour on day two, a review on the preview link, and an approval before it publishes. Product facts we cannot get from the data, like why a deal died, are the one thing we genuinely need from you. We do not write your product content, and we will not invent claims about your software.
Can we run sprints ourselves once we have the system?
Yes, and some teams do. The dashboards, the conventions and the publishing workflow are yours, so the loop is repeatable without us. What we bring is the pattern library and having run the same fixes on other funnels. Teams usually keep us for the sprints that need a page built and run the copy tweaks themselves.
Do we have to commit to a number of sprints?
No. Each sprint is scoped and priced on its own, and nothing renews automatically. Run one, see what you get, decide after. Most teams settle into one a month because that matches how long a result takes to read, but a quarter between sprints is fine and so is a pause.
Our site was not built by you. Can we still run sprints?
Only once the funnel is measured, otherwise we would be picking a stage on vibes. If your events are already clean in PostHog and your team can ship a page, we can start. If not, a retrofit comes first: naming components, writing the conventions, wiring the events. It is usually a matter of weeks, not a rebuild.
Why only one change per sprint?
Because two changes on the same stage cannot both be measured, and you end up with a number you cannot explain. Small work that carries no risk to the measurement, like a broken redirect or a stale page, still gets done alongside. The rule is about the thing being tested, not about doing the bare minimum.
Who picks the stage, us or you?
The funnel proposes, you decide. We bring the stage with the worst number and the reasoning behind it. If you know a launch is coming and acquisition matters more this month, we go there instead. What we will not do is pretend the stage you picked was the one the data pointed at.
One call, no deck
Show us your funnel, we will name the worst stage
Thirty minutes with the person who would run the sprint. You get a straight read on which stage is leaking, what the first sprint would change, and how many days it takes. If your funnel is not measured well enough to answer that, we will tell you on the call.