Improving activation within the capacity we had.
Most new customers weren’t reaching automation. Engineering was committed to a backend migration, so we had to find improvements within available capacity.
Senior Product Designer
Lead product designer
PM, engineering, Success & Support
Problem: New sellers were learning PPC and Adtomic simultaneously.
Constraint: Limited engineering, marketing, and analyst capacity.
Approach: Iterate onboarding, reuse resources, and make automation discoverable.
Learning: A stronger welcome did not rescue checklist completion.
Reported outcome: The 25% target for activation within 14 days was exceeded over six months.
The activation problem
Adtomic had an activation problem: most new customers weren’t reaching automation. Research pointed to guidance, discoverability, and usability. Newer sellers were learning pay-per-click advertising and the tool at the same time.
The goal was to improve the share of new customers activating automation within 14 days. But engineering was busy with a backend migration, with limited marketing and analyst support available.
I led product design with the PM and lead engineer, working with Customer Success and Support. We needed a sequence of improvements the team could deliver, rather than a single large redesign dependent on capacity we did not have.
Start with what the team could change
Appcues was within the team’s control. That gave us a way to iterate onboarding while engineering focused elsewhere.
Across 17 onboarding iterations, we explored how to help sellers find a useful starting point. A goal-oriented approach was strongest, but checklist completion dropped. That was a reason to change direction, not label the checklist a win.
Keep a simpler welcome and resource direction. Don’t make checklist completion the story when the behavior doesn’t support it.
The lesson was specific: a welcome could become clearer without the checklist becoming more effective. We kept those observations separate.
Reuse resources instead of waiting
Engineering-built templates were not available. The resource center reused webinars and written automation recipes that already existed.
This was a practical scope choice. We could connect sellers to useful guidance while preserving engineering capacity, rather than wait for a more ambitious solution before helping anyone.
Success and Support were part of that work, connecting the product experience to the questions sellers brought to the team.
Make automation easier to find and set up
As the work progressed, navigation was reordered, automation was surfaced in tables, and a Rules & Automation page made the capability more visible.
Usability testing also informed the builder. We grouped setup into clearer steps and added contextual help where sellers needed it, so the interface carried more of the explanation.
The outcome, with its limits
Over six months, the product exceeded its 25% target for automation activation within 14 days. That is the result reported in the project material.
Onboarding, resources, navigation, and the builder all changed. The work involved product, engineering, design, Success, and Support. It would overstate the evidence to attribute the outcome to one screen or to my contribution alone.
What I took forward
Good prioritization included deciding what not to depend on. Existing tools and resources let us make progress while a backend migration occupied engineering.
It also included letting go of a promising experiment when the relevant behavior worsened. Delivering within the constraint, inspecting what happens, and revising the choice is the product judgment behind this work.