Problem context

Early PLG teams feel pressure to automate onboarding, routing, and messaging before they fully understand user behavior.

Over-automation can lock in bad assumptions and hide important signals about what users really need.

Once flows are automated, it becomes harder to notice and correct subtle issues that humans would have caught.

What breaks if this is not solved

Users experience generic, misaligned flows that erode trust instead of feeling guided.
Teams stop hearing about important edge cases because automation shields them from direct contact with users.
Instrumented data reflects the automated path rather than the actual jobs-to-be-done, leading to misleading conclusions.

You are in the early stages of PLG and still learning which journeys, segments, and activation definitions are correct.
Headcount is limited and automation is tempting as a way to “scale” prematurely.
You have not yet run a sufficient number of manual or semi-manual experiments to understand the landscape.

Treat manual work as an investment in learning that should precede automation, not as a permanent operating model.

Prioritize automation where behavior and value are well understood, and keep high uncertainty areas manual or semi-manual.

Design automation so that it can be adjusted or rolled back without heroic effort.

List the core PLG flows you are considering automating, such as onboarding, lifecycle messaging, routing to sales, or upgrade prompts.
For each flow, assess your level of understanding: how confident are you in the underlying jobs-to-be-done, segments, and success criteria.
Start with manual or semi-manual experiments for high uncertainty flows, using humans to make decisions and gather qualitative feedback.
Automate only the stable parts of flows where you see consistent patterns, and keep exceptions or complex cases routed to humans.
Document assumptions you are baking into automation and set explicit review dates to revisit them with new data.
Instrument automated flows carefully so you can see when they behave differently than manual baselines.

Conversion and retention of users going through automated vs manual flows
Automated should match or beat manual before scaling further.
If automated flows underperform, pause rollout and revisit assumptions.
Volume and quality of qualitative feedback from early users
Remain sufficient to learn from even as automation increases.
A sudden drop in rich feedback can signal that you automated too much.
Incidents or regressions attributable to automated decisions
Trend down over time.
Track notable failures where automation did the wrong thing so you can improve safeguards.
Time spent on manual work in clearly stable flows
Trend down as you confidently automate those areas.
Manual work is a learning tool, but unnecessary manual repetition is a sign to consider automation.

Automating flows you have never run manually, so you do not know what “good” looks like.
Treating automation decisions as permanent, making it politically or technically hard to reverse them.
Using automation to avoid talking to users, rather than to scale what you already know works.
Leaving instrumentation as an afterthought, so you cannot tell whether automated flows are helping or hurting.

Pillar

Glossary

Adjacent playbooks