By role · 4 tools
The web stack for a VP of Growth
A VP of Growth picks the same tools as a Head of Growth and has to defend them to different people. The question stops being which testing tool works and becomes which one survives procurement, reports cleanly upward, and keeps producing results after the person who set it up moves on.
What is a VP of Growth actually accountable for?
You carry the number, plus the people and the budget behind it. A tool stops being a personal preference the moment three people share it, so the question shifts from which one is best to which one your team can run without you in the room, and which one you can still explain in a budget review.
Which testing tools should a VP of Growth put in front of a team?
Four picks, each with the trade it makes. None of them is the right answer for every company, and a shortlist where everything is excellent is an advert.
Cheap enough to put in three people's hands without writing a business case, which is usually how a testing habit starts inside a team rather than in a plan.
Watch outWhat is easy to buy is easy to run badly. Without one person owning hypothesis quality you end up with a lot of tests and no learnings anybody can point to.
Your marketers build the variants themselves, which removes the engineering dependency that stops a testing programme before it produces anything.
Watch outSelf-service across a team means uneven test quality unless the hypothesis format is standardised first. The tool will not do that part for you.
Covers marketing-page tests and in-product tests on one contract, so growth and product stop arguing about two sets of numbers.
Watch outTwo audiences on one contract makes the setup a joint decision with engineering, which means it moves at the speed of the slower side's roadmap rather than yours.
Built for the review your finance and security teams will run, with the permissions and audit trail that survive that conversation.
Watch outThe price is a commitment to a programme, not a trial. Sign it when there is already somebody whose job is running the tests, not to create that person.
What can a VP of Growth hand to an assistant?
Each of these is one file you paste once, and then the job runs the same way every time.
Test hypothesisWrite an A/B test up properly before it gets built: who you are helping, what they are trying to do, what you are changing, why you think it will work, and what you will learn either way.Test iterationA test finished. Get ten specific things to try next, each with what changes, why it might work, and what success would look like, grounded in what the last one showed.Learnings logWrite a finished test up in four fixed sections, then decide what earns a place in the file everyone searches before proposing the next one.Learnings checkBefore you build a test, find out whether your team already ran it. It searches the finished tests, weighs each one by how recent and how proven it is, and tells you to proceed, change it, or think again.Which tools should a VP of Growth connect to their assistant?
Connecting these means asking a question about the real site instead of copying screenshots into a chat window.
PlausibleCommunity MCP server by the Sentry team, Stats API key, self-hosted or remote
AmplitudeRemote MCP server, mcp.amplitude.com/mcp, OAuth, EU endpoint available
OptimizelyRemote MCP server, exp.mcp.opal.optimizely.com/mcp, OAuth
AB TastyLocal MCP server, npx @abtasty/mcp-server, environment ID and API keyQuestions people in this role ask
Taken from what people actually ask about this, not written to fill the page.
How do I justify a testing tool in a budget review?
Price the labour, not the licence. The real cost includes the person building tests, whoever reads them and the engineering time it borrows, which routinely lands well above the invoice. The counterweight is a written record of what was tried and what it changed, which is also the only part that survives a team change.
Should growth and product share one testing tool?
It helps when both sides touch the same funnel, because two tools means two definitions of a conversion and a quarterly argument about whose number is right. The cost is that the choice stops being yours alone. Kameleoon and Optimizely both cover marketing pages and in-product tests, and both need engineering in the room.
How many people do I need before a testing programme is real?
One whose job it actually is. Bought as a capability, with testing added to four people's existing workload, a tool produces a handful of tests and no learnings anybody can point to. If nobody has the time, buy the cheapest thing that works, prove the habit, and upgrade when there is a person to hand it to.
Client-side or server-side for a team?
Client-side for marketing pages, because your marketers build the variants themselves and that independence is what keeps a programme alive. Server-side when the test touches pricing, onboarding or anything behind a login. Running both usually argues for one tool that does both rather than two contracts to defend at renewal.
What happens to our tests when the site gets redesigned?
Client-side tests break, because a visual editor targets the markup underneath and a redesign replaces it. Plan the redesign as a stop and restart for the programme, and get the learnings written down before it begins. What you learned survives a redesign. The tests themselves do not.
Not your job?
Every tool named here has a full entry in the stack, with the verdict and what it costs you.