What I check when a product works but nobody adopts it.
06
✦ Enterprise SaaS & Workflow Automation · Personal Anecdote
What I check
a reliable builder, a governance bottleneck nobody put on the roadmap →
What I check
when a product works but nobody adopts it.
a reliable builder, a governance bottleneck nobody put on the roadmap →
The workflows we shipped ran cleanly, low error rate, real time saved for the people who built them. Months after purchase, most accounts still had zero live workflows. I kept assuming it was a builder-UX problem until the support data told me otherwise.
Blamed the UI firstIt was never a builder problemNow I check this before any adoption post-mortem
Personal Anecdote
This is a Personal Anecdote, not an employer engagement. Written to show how I diagnose and structure a product problem in Enterprise SaaS & Workflow Automation.
0
People on the team
0
Weeks, two quarters
0
Onboarding paths tested
0
x more active-workflow accounts
0
% cut in time-to-first-workflow
What I Check
A feature can be reliable and still be adopted by almost nobody
For months I kept reading the same support tickets and support-consultant notes as a builder-UX problem. The tool wasn't hard to use, exactly, so I kept looking for a friction point in the canvas itself. It took a pile of purchase-to-first-workflow timestamps to make me stop looking there.
A no-code tool bought at the org level but adopted only by the one or two most technical people in each account isn't a UX failure, it's a governance failure, because nobody without IT's blessing can safely turn a workflow on. So now, when a feature that works technically still doesn't spread past its first users, I check who has to approve it before it goes live, not how hard it is to build. That one check is the whole fix. The rest of this case is just the one time it took me a whole quarter to find it.
Here's the rollout that taught me to check, and the four things I built to act on it. 👀
The Case
Role & scope
Product lead for the automation platform's adoption motion. Accountable for the repositioning decision, not just the diagnosis, working across engineering, design, and a solutions consultant.
Stakeholders aligned
Engineering (built the template gallery and approval queue), design (the admin-facing governance flow), the solutions consultant (industry template content), and sales leadership (accepted the repositioning away from "build anything").
Business problem
The workflow builder ran reliably wherever it was used, low error rate, real time savings for the people who touched it. But purchase-to-first-workflow time averaged many weeks, and most accounts, bought at the org level, never got a single workflow live outside the one or two technical users who built it for everyone else.
Goals
Cut time-to-first-live-workflow at the account level, without redesigning the automation engine itself or slipping into a multi-quarter marketplace build that solved the wrong problem first.
The Tension
The product was purchased by an org and adopted by one person in it.
If the builder already worked, why did almost nobody past the first user ever touch it?
I spent the first few weeks of this looking in the wrong place. Every usability session with our power users went fine, they built workflows, they liked the tool, they had specific feature requests but no real complaints. I kept assuming the accounts with zero live workflows just hadn't found their power user yet, and that time would fix it. It didn't.
What actually broke the pattern was a scan of account exec notes I wasn't originally looking at. IT and security teams were sitting on new automation requests for weeks, not because the workflows were risky, but because there was no visibility into what a workflow did before it went live, and no audit trail after. The builder wasn't the bottleneck. The absence of a way for an IT approver to safely say yes was.
The forces around one adoption decision
Four forces pulling on the same adoption decision, the fix had to satisfy all of them at once.
From No Gate to a Named Gate · how my thinking actually moved
No gate identified · week 2
?simplify the canvas
?add onboarding tooltips
?more training docs
Named gate · week 7
✕ Ruled out: Builder complexity
Confirmed: No IT visibility or approval path
Root cause: Governance gap, not UX
Confirmed across 3 stalled accounts
A hunch isn't a case yet. Time to go find out if it holds up. 🔎
Research
What the account data actually showed
A hunch isn't a decision. Before I brought this to anyone, I pulled four separate cuts of account data to rule out the boring explanations first, bad onboarding, small accounts that didn't need automation, before treating it as a real governance problem worth a team's time.
[1] TIME TO FIRST WORKFLOW
"Purchase-to-first-live-workflow averaged many weeks across new accounts, most of that time spent waiting on an approval nobody formally owned."
[2] ACCOUNT EXEC NOTES
"IT and security teams were sitting on new automation requests for weeks at a time, with no visibility into what a workflow actually did before approving it."
[3] BUILDER CONCENTRATION
"In adopting accounts, nearly every live workflow traced back to one or two named builders. Everyone else in that account never opened the canvas."
[4] SUCCESSFUL STARTS
"Accounts that went on to sustain multiple active workflows almost always started from a duplicated existing workflow, not a blank canvas."
From No Gate to a Named Gate · ruling out the easy explanations first
Still no gate · week 3
?onboarding/training gap
?account too small to need it
?just needs more time
Gate cracked open · week 5
✕ Ruled out: Onboarding/training gap
✕ Ruled out: Account too small
Confirmed: IT approval bottleneck, no governance layer
Confirmed across every stalled account we sampled
Illustrative, indexed for shape not scale
Reliability climbing, adoption flat 👀
Workflow reliability (error-free runs)
% of accounts with an active workflow
One line climbing while the other stalls flat is the whole story, they lived in different reviews.
Builders vs. everyone else, per account
One builder, whole account depending on them
One or two builders per account carried the whole automation footprint. Everyone else never opened the canvas.
Problem statement
Adoption is blocked by governance and cold-start friction at the org level, not by builder usability.
North-star metric
Time-to-first-live-workflow per account (target: cut sharply from the multi-week baseline).
Guardrail metrics
Workflow error rate (must not regress from current baseline); IT approval turnaround time.
Non-goals
Redesigning the underlying automation engine, this was an adoption and governance problem, not an engine-quality problem.
This is the exact scorecard I brought into the room, so the trade-off would be a group decision, not a private judgment call.
- North star: time-to-first-live-workflow per account
- Ring 2 , primary guardrail: workflow error rate (must hold flat)
- Ring 3 , secondary guardrail: IT approval turnaround time
KPIs I actually tracked week to week
Time to first workflow
↓63%improving
Workflow error rate
→flatflat (target)
Active-workflow accounts
↑4ximproving
IT approval turnaround
↓days, not weeksimproving
Onboarding time (this project)
→+1wkslightly slower (accepted)
Non-builder participation
↑up sharplyimproving
Four ways to fix it. Only one of them didn't require building something new.
Ideation & Decision
Weighing the alternatives
Four ways to close the adoption gap, each with a different cost. I scored them on the same two axes so the trade-off would be legible to people who hadn't spent a quarter in the account data with me.
1
Further builder UX polish. Cheap and easy to greenlight, but doesn't touch the real bottleneck, premature given what the account data actually showed.
2
Full workflow marketplace with 3rd-party templates. Genuinely valuable long-term, but a multi-quarter build that solves the wrong problem first.
3
Curated template gallery plus a built-in IT approval flow.Chosen Directly targets both blockers the evidence surfaced, cold-start friction and governance, without touching the automation engine.
4
Mandatory professional-services onboarding for every account. Helps the accounts that get it, but doesn't scale economically, used only as a supplement for the largest accounts.
Accepted riskTemplates reduce flexibility versus a blank canvas. Mitigated by keeping the full builder available alongside the gallery, not replacing it.
Deliberately not builtA workflow marketplace with external developer contributions, the right long-term idea, wrong sequencing. Governance had to be solved first, or a marketplace just gives IT more unreviewed things to worry about.
From No Gate to a Named Gate · two paths, only one gets built now
Both paths undifferentiated · week 9
?templates: fast, but is it enough?
?marketplace: bigger, but 2 quarters?
One gate built, one deferred · week 10
Templates + approval (chosen): High impact, low effort
✕ Marketplace (deferred): High impact, high effort
Same four options, now impossible to misjudge
My Mental Model
Impact vs. Effort
Four options, one question: which moves the real adoption problem most for the least new machinery? The marketplace feels like the serious choice because it's the most ambitious, but ambition isn't evidence of sequencing.
The template gallery plus approval flow sits in the same high-impact territory as the marketplace, at a fraction of the build cost, and it's what the marketplace would need to succeed anyway.
Chosen
Considered
Rejected
Deciding was the easy part. Getting sales to actually want the repositioning was the real work. 🛠
Solution
What if starting a workflow meant duplicating one, not staring at a blank canvas?
Actors & Inputs
- Business admin
- IT / security approver
- Workflow engine
- Most-copied internal workflows
→
System Change
- Curated template gallery
- Lightweight IT approval queue
- Audit trail on every workflow
→
Outcome
- Non-builders launch from a template
- IT approves with visibility, not blind trust
- Adoption spreads past the first user
From No Gate to a Named Gate · the gate splits into three lanes
One undefined line · week 8
?where's the approval line
?who owns the override
Three lanes defined · week 9
Auto-approve: Low-risk template, no new scope
Route to IT: Touches customer data
Block: Requests write access outside approved scope
Owned jointly by product + IT, not a silent gate
Type the request. Then toggle to see what IT actually saw before and after.
Pending. No description, no data scope, no audit trail for IT to review.
Started from approved template
Data scope + audit trail visible
I underestimated one thing going in: sales' incentives were built entirely around demoing the builder's flexibility, "build anything," so when I proposed leading with templates, I watched it land as a claim that we were shrinking the product, not what I actually meant it as: a gap in how accounts actually got started.
Sales wanted
Keep pitching "build anything," worried templates read as a step down in capability
I wanted
Lead with org-wide time-to-value, worried the flexibility-first pitch was actively costing renewals
Resolved by: reframing around time-to-value, not individual power-user capability
I didn't bring a mandate to reposition the pitch; I brought account-level adoption data into the room, not the builder-usage data sales was used to seeing, and let the org-level bottleneck make the case for itself.How I led
How the two quarters actually went
WEEK 2
Signal noticed in account exec notes
IT approval delays flagged during a routine account review, unrelated to any builder complaint.
NoticedWEEK 7
Root cause traced to governance, not builder UX
Account data confirmed the builder wasn't the bottleneck, the absence of an approval path was.
DiagnosedWEEK 12
Template gallery + approval flow proposed
Repositioning pitch aligned with sales around time-to-value instead of builder flexibility.
ProposedWEEK 20
First template set too generic, recalibrated
Accounts wanted industry-specific templates, not generic ones, set expanded mid-flight.
AdjustedWEEK 26
Shipped, active-workflow accounts grew several times over
Template-first onboarding live for all new accounts; time-to-first-workflow cut sharply.
Shipped 🎉Proof
| Hypothesis | Accounts given a template gallery plus an IT approval flow will reach first live workflow faster and sustain more active workflows than blank-canvas-only accounts. |
|---|---|
| Design | New accounts randomized into template-first vs. builder-first onboarding. |
| Primary metric | Time-to-first-live-workflow; 90-day active workflow count. |
| Result | Time-to-first-workflow dropped sharply; active workflow count grew several times over versus the builder-first cohort; workflow error rate unchanged. |
| Follow-up | First template set was too generic, accounts wanted industry-specific templates, segmenting by industry became the next iteration instead of a day-one requirement. |
Governance-ready templates
→
Faster IT approval
→
More org members activate workflows
→
Higher renewal likelihood at contract time
Shipped isn't the same as done. Here's what I'd actually keep, and what I'd do differently. 🕑
Learnings
Key takeaways
What worked
Governance was the actual product gap, not builder usability. I didn't touch the automation engine, I made it possible for an IT approver to say yes.
What didn't
The first template set was too generic, accounts wanted industry-specific templates, and I found that out after launch instead of before.
Next time
I'd segment templates by industry from day one instead of retrofitting it in after the generic set underperformed.
The pattern outlived the project: enabling IT approvers, not just builders, is what actually scaled adoption, which is the part of this I'm proudest of, not the template gallery itself, the fact that the org, not just one power user, could finally use what it bought.
"The operating model is part of the product."
Principle carried forward"A platform succeeds when its ecosystem succeeds."
Principle in practiceFrameworks & skills applied
Adoption diagnosis
Governance & approval flow design
Cross-functional repositioning
Template/gallery UX
Cohort experimentation
Impact vs. effort prioritization
Adoption diagnosis
Governance & approval flow design
Cross-functional repositioning
Template/gallery UX
Cohort experimentation
Impact vs. effort prioritization
Quick Answers
FAQ
Is this a real project from a specific employer?
I wrote this as a Personal Anecdote to show how I think through a problem in Enterprise SaaS & Workflow Automation, not to claim a specific past engagement.
Why templates and governance instead of a full workflow marketplace?
The marketplace is the right long-term idea, but it's wrong sequencing, it just gives IT more unreviewed things to worry about until governance exists. I deferred it, I didn't reject it.
What would you do differently?
I'd segment templates by industry from day one, the generic first set undersold the idea before industry-specific templates proved it out.
How did you get sales to accept a pitch that sounded less powerful?
I didn't bring a mandate, I brought account-level adoption data, not the builder-usage data sales was used to seeing, and let the org-level bottleneck make the case for repositioning itself.