An engineer’s reflections on growth—a look back at the last year

Being on the growth team at Dovetail is like a never-ending hackathon without the presentations or prizes. We deliver projects that focus on one goal—moving the needle. To do this, we keep projects small to avoid unnecessary complexity and cut features down to the bare minimum in a way that still delivers the expected functionality.

In 2024, our team achieved significant milestones, such as doubling our paid conversion rate through our focused experimentation approach. As the technical lead of the team, I have been reflecting on the things that went well, the things that could be improved, and the lessons learned along the way to maximize success.

What went well

Team composition

The growth team at Dovetail, which spans product, engineering, web, marketing, and data, is, at this point in our journey, the most cross-functional we’ve ever been. This collaboration was critical for expanding the growth levers available to us, allowing us to approach challenges from multiple perspectives. Team members brought deep experience, tenure, and understanding of customer problems. This was complemented by having frequent conversations with our VP of Product and CEO to bounce ideas and get their strategic guidance. For a short time, we even benefited from our founder serving as the team designer.

What made this team particularly effective was its versatility. Nearly every member of the team is either a product manager, designer, engineer, or researcher. Everyone is eager to roll up their sleeves; some even have Dovetail running locally on their machines to continuously run experiments.

Also, having members from previous growth teams available for collaboration provided invaluable institutional knowledge. Their insights helped us avoid potential pitfalls and leverage past learnings.

Innovation and autonomy

One of the biggest unlocks for creativity across the team is the high level of autonomy we have—what we decide to work on and how we decide to do it. This freedom to choose our projects and methods has empowered team members to propose and pursue unconventional solutions. With high autonomy, we’ve tried some wild ideas.

For instance, we made the decision to significantly streamline our free tier, risking immediate customer satisfaction in service of evolving the product and delivering more value to our users in the long run. Perhaps our most daring initiative was to require users to upload data before they could finish onboarding. While it’s counterintuitive to introduce friction during onboarding, we wanted to give new users a simple way to very quickly see the power of Dovetail. And there’s no better way to do that than to let them upload their own unstructured qualitative data, immediately analyze it, see themes, and discover real customer insights they can apply to their work. The friction did cut our funnel completion by half, which might sound like a crazy thing to celebrate, but by doing so, we very quickly brought in the right customers, who will, in the end, get the most value from Dovetail. The result of this small change actually increased our paid conversion by more than double!

Extremely pragmatic

With many ideas and just one engineer for a long time, being extremely pragmatic was core to our strategies. For example, we ran a year’s worth of experiments on the onboarding flow that most users probably didn’t even notice. While some teams might insist on overhauling the whole onboarding flow, it was really important for us to focus on small functional changes to which we could accurately attribute impact.

Our pragmatic mindset influenced how we implemented new features. An initial idea to add a new slide on the onboarding page would eventually be changed to just a dropdown on an existing page. Rather than building new modals, we used existing tools such as Intercom to guide specific segments of users, delivering impact with far less engineering effort—in fact, none at all.

We build experiments with the mindset that they might not stick around. A lot of our experimental code ends up getting deleted, but this is actually by design. This lets us move really fast while keeping the codebase clean. If an experiment works, we’ll rebuild it properly; if it doesn’t, we just delete it. This way, we can ship way more experiments without drowning in technical debt.

Data and hypothesis informed

One of the first things we did was to reintroduce asking for information about our customers’ roles during onboarding. It was previously removed to reduce friction in our onboarding flow, but it left us without valuable information about how our customers will likely interact with our product. Adding this back allowed us to segment users better and also let us compare how the type of users coming in has changed. We thoughtfully iterated on adding more questions, letting us target only a subset of our users in some of our Intercom guidance modals.

Additionally, we’ve improved signup attribution and added more analytics tracking, which lets us slice data with more meaningful angles, such as roles and use cases, focusing on business emails and whether they are a returning user. We’ve improved how we do A/B tests, looking across multiple metrics and also their confidence levels. We’ve done a bunch of experiments, but we’ve also released quite a bit without requiring an A/B test.

Besides looking only at metrics, sometimes the value we get from experiments is learning something new about our customers and the opportunity to update our mental model.

For example, in one experiment, the losing variant had a lower conversion rate on certain key metrics but had a much higher invitation rate (i.e, the likelihood of inviting others to Dovetail for the purpose of collaboration or insight sharing). This is an interesting example of how a new idea failed by some measures, but led us to question what it was about the losing variant that caused it to have a consistently higher invitation rate.

Customer focus

Dovetail is obsessed with helping teams better understand their customers. And so you can imagine, everyone inside Dovetail—including engineers—talks to customers every chance we get. On the growth team, we jump on a high number of customer calls to understand our users’ workflows. As with everything, we’re pragmatic about this outreach and continuously adjust how we do it and who we talk to. Additionally, we’ve been using Fullstory, which enables us to see what our customers see when using the product (with all sensitive PII removed) and understand them on a deeper level. This gives us more visibility as well as another tool to use besides analytics data and interviews.

Lessons learned

Look, not everything was perfect, and that’s exactly what makes this worth sharing. Here’s what I’ve learned about making growth engineering actually work:

• Physical team layout matters more than you’d think. We started scattered across different areas, and it killed our ability to bounce ideas around quickly. Sure, we patched it with structured brainstorming sessions, but nothing beats being able to swivel your chair around and say, "hey, what if we tried this?"

• Growth teams touch everything, not just onboarding but different parts of the product all the time. That means a lot of stakeholders and a lot of coordination. Without a solid system for managing these touchpoints, you’ll spend more time in sync meetings than shipping experiments.

• Ship fast, learn faster, and don’t get too precious about your code. We noticed a real difference when we stopped trying to build perfect solutions and started optimizing for learning speed.

After a year of this, I’m convinced that growth engineering isn’t about having the perfect tech stack or the cleanest code. It’s about having the guts to try wild ideas, the discipline to measure everything, and the wisdom to know when to throw it all away and try something new.

The teams that win at this are the ones that can ship fast without drowning in technical debt, learn from every experiment (especially the failures), and turn those learnings into actual product improvements.

Jack Lian is a senior software engineer and technical lead of Dovetail's growth team.