Lead Data Analyst, Growth & Experimentation

LawnStarter, Rio de Janeiro, Brazil

What our tracking knows about this posting

Published on 25 September 2026 · first appeared in our records on 26 September 2026.

Stable posting: first seen on 26 September 2026, with no abnormal reposting.

This posting shows no salary, while 3% of open postings in the same sector in this country (Brazil) do.

View the posting at the employer Have my resume reviewed for this job
About LawnStarter LawnStarter is the nation's leading on-demand marketplace for lawn care and outdoor services, with over $150M in annual bookings. We're expanding beyond lawn care into the one-stop shop for all home services. Getting there depends on how fast we can test, learn, and scale what works. About the Data Team We're a high-leverage team of Product Data Analysts embedded across the business, owning the semantic layer and the metrics everyone trusts. The experimentation program runs on real rigor, not vibes: pre-registered analysis plans gate every test launch, anytime-valid statistics keep mid-run dashboards honest under continuous viewing, automated daily SRM and attribution health sweeps catch broken tests early, and seasonal power forecasting accounts for a business that swings hard by time of year. The test lifecycle, design through readout, is already AI-driven. Our analysts are stretched across product, so Growth support has stayed part-time and reactive, until now. The Role You're the first data analyst dedicated entirely to Growth and Experimentation. Your primary charter is the  experimentation program : test design, statistical rigor, and readouts across web funnels, SMS/drip, sales-driven tests, and SEO tests built on our own page-clustering tooling. It's a wider surface than most companies run. You also own the  acquisition-to-conversion funnel  those tests move, across paid, organic, and partner channels. What to test and which direction to bet on is the CRO's and Growth PMs' call; you shape it, they decide it. You're not starting from scratch. Dashboards, tooling, and rigor scaffolding are already shipped and running. Expect the early months to be hands-on and manual: scoping tests, crunching readouts, while you build toward a self-serve layer. If a test readout and a funnel refresh ever compete for your week, the test wins. What makes this role different: • The CEO personally engages with test design here: real organizational weight, no fight for buy-in. • You partner directly with the Director of CRO, performance marketing, and Growth PMs, who come to you when a test needs a call. What You'll Own • Experimentation rigor:  test design, power and sample-size calls, significance and readout standards. Core of the role: you catch underpowered tests and false positives before they become bad decisions, and you get Growth's tests onto the anytime-valid monitoring the program already runs, so early calls come from a crossed boundary instead of a hopeful trend read. • The self-serve experimentation layer:  automated Growth metrics in Lightdash, Python-backed stat-sig tooling, and the AI skills (Claude routines) already handling pre-test power calcs and live-test health checks. You extend these and keep the layer correct as product and tracking evolve. • The Growth funnel model:  a trusted, instrumented view of visitor → lead → customer across every brand and channel, with the CAC, LTV, and conversion-rate cuts Growth needs to prioritize investment. • The Growth analytics function model:  by end of Year 1, the standards and playbook that scale this function beyond one person, plus a buy-vs-build recommendation for the experimentation stack (an off-the-shelf stats engine, or extending our own skills and Python). You bring the recommendation; the final call isn't yours alone. Problems to Solve Tests that can't answer the question they were run for  Growth wants more experiments, but volume without rigor produces confident, wrong conclusions. Raising the bar without becoming the bottleneck is the job. Getting off the manual treadmill  Real tooling already exists: test-design helpers, dashboards, AI skills. Most tests are still hands-on and bespoke. How do you extend that automation so routine cases genuinely self-serve? Making the funnel decision-grade  The semantic layer defines the funnel, but instrumentation is uneven across brands and channels, and no one owns the single trusted view. You build it, and you keep it trusted. Turning analysis into decisions  The hard part isn't the SQL. It's getting a PM or marketer to change course. Can you deliver insight sharp enough that the room acts, and push back when the data favors the popular but wrong idea? What Success Looks Like (Year 1) • Rigor is the default.  Power calculations are standard practice, early stops on Growth tests come from the anytime-valid boundary rather than a trend read, and the re-run rate (redone for tracking or attribution problems) is down. • Routine tests self-serve.  Metrics and stat-sig are automated in Lightdash, so the team reads standard results without filing a ticket, and your time goes to the tests that need an analyst. • A funnel Growth trusts.  The acquisition→conversion funnel is instrumented across every brand and channel; Growth prioritizes off your model, not side spreadsheets. • Measurable conversion wins.  Your analysis directly drove specific, quantified lifts in the funnel, and you can name them. Who You Are AI-native.  You use AI daily for SQL, dbt, and pressure-testing your analysis, extending the skills already running our experimentation process rather than merely using them. This is unlikely to be a good fit if you're skeptical of AI or treat your workflow as fixed. A partner, not a report-writer.  You don't wait for a ticket. You sit close to Growth and bring the question before anyone asks it. Skip this one if you want a clear queue with no expectation to push back. Statistically sharp.  Wrong fit if "we hit significance" ends your analysis instead of starting it. Right fit if you have a point of view on test design (power, significance, novelty and interaction effects, when not to test) and can explain a broken experiment in plain terms. Fluent in experiment instrumentation.  You know how Segment events and Flagsmith randomization interact, and catch a tracking problem before a test ships, keeping our re-run rate down. This isn't for you if instrumentation is someone

Other recent postings in the same sector