Shipping growth experiments in a team of 1

There were no established processes, no product manager for the first month, no dedicated engineer ever, and no existing experiment backlog to work from.

Three months in, the Growth PM left for a new role. By that point I had already taken on full ownership of identifying what the team should be working on. I continued running the Growth work while simultaneously transitioning onto another squad, managing both in parallel before the Growth team was formally wound down in September and my efforts moved fully onto designing the next iteration of our AI product.

GWI was historically a sales-led growth company. That meant there were a million ways I could improve the platform and systems to support product-led growth, and no clear filter for which ones to attempt first.

The risk was spending months designing solutions for problems that were either low-impact or impossible to ship without significant technical lift. I needed to build a way of finding the highest-value, lowest-effort opportunities the team could actually execute on — and do it without a PM to delegate the strategic work to.

I interviewed designers across other squads to surface friction points across the full GWI customer journey — acquisition, adoption, expansion, and advocacy — then synthesised everything into a prioritised backlog based on impact and effort that I could action immediately.

The framework was built to answer one question above everything else: what can we ship that will have real impact without needing an engineer to build it from scratch? That constraint was the filter that made the whole process useful.

Book a Demo conversion and API trial friction were both well-evidenced, immediately actionable, and had no engineering dependency. This is where the two experiments came from, with plenty more in the backlog.

Only 10% of users who clicked the in-platform Book a Demo CTA were completing the form — a negative indicator on a crucial inbound sales pipeline. The reason was simple: clicking the CTA took users out of the platform entirely and dropped them onto the public marketing website to fill out a generic form with information we already had stored from their account details. The context break and extra effort was enough to lose 9 out of 10 people who had just expressed intent to speak to sales.

I redesigned the flow to keep users inside the platform as a native booking experience — removing the redirect and replacing the generic form with one that met the sales team's requirements and improved the UX and accessibility issues. The key was balancing a quick flow that wouldn't overburden users while still passing along enough information for a sales rep to have an effective first conversation.

Getting API trial access to a prospective customer was taking 10–23 days. The blocker was structural: every trial required a contract signature in order to accept the special terms and conditions, which triggered a full legal review cycle. By the time access was granted, sales momentum had often died.

I worked with Legal to pre-approve a standard set of trial terms, then built a no-code entry point in Figma Sites and configured a Zapier automation to route submissions directly to the revenue team and reduce manual steps. I ran every test flow myself with internal users, iterating until the handoff points were reliable, then documented the full process for the team.

Through a series of low-lift, high-impact product interventions, I bridged the gap between the platform, internal systems, and the sales cycle — leading to a sustained lift in demo completions and a 90% reduction in trial processing time.

Without a dedicated engineer or PM, I relied heavily on testing my ideas with AI first. It was a safe sandbox for weighing the pros and cons of different approaches and for speeding up execution through automation.

The most time-consuming part of both experiments was the cross-functional alignment needed for even the simplest aspects. In future, I'd define all stakeholders clearly upfront and treat any additional input as nice-to-have rather than blocking.