When a less technical persona can't use your product independently, the problem is almost never the interface — it's that the things they need to control live in a layer they can't access (often frontend code). Solving persona expansion requires infrastructure work to move those capabilities into a product-managed layer, plus a governance architecture of structured flexibility. Skipping the structural fix and shipping a "simpler" UI leaves the dependency completely intact.
One of the most common growth strategies in B2B SaaS is expanding to a new persona alongside your existing one. Your product works for developers. Now you want it to work for marketers. Your product serves IT. Now you want operations to use it too.
The strategy is sound. The execution is where most teams get it wrong.
The mistake is treating persona expansion as a UX problem: simplify the interface, reduce jargon, add more guidance. In my experience, that approach addresses about 20% of the real problem. The other 80% is structural — and you won't find it by running user research on the interface.
The dependency problem isn't about complexity
When a less technical user can't work independently in your product, the instinct is to assume the interface is too complicated. Sometimes that's true. But more often, the problem is that the things the new persona needs to control are not in the product at all. They're somewhere else, owned by someone else.
In developer-first products, this is almost universal. Layout decisions, design configurations, content-presentation relationships — these typically live in frontend code. Not because developers were being territorial, but because that's where those decisions belong architecturally in a system built for developers.
The result: a marketer who wants to change the layout of a page, or build a new landing experience, or test a different composition — has to wait for a developer to do it. Not because the interface is confusing. Because the capability literally doesn't exist in the interface at all.
You can spend an entire year making the existing product easier to use, and that dependency remains completely intact.
What real independence requires
Giving a non-technical persona genuine independence means moving the things they need to control into a layer they can access. That's an infrastructure decision, not a design decision.
In the case above, it means shifting the association between content and layout out of frontend code and into a product-managed layer with appropriate tools for non-technical users to work with directly. That requires significant architectural work — new data models, new integrations, new infrastructure — before you write a single line of marketer-facing UX.
This is where product leaders get caught. The engineering team estimates the work. Leadership sees the scope. The pressure begins: "Can we just do a lighter version? Can we expose some settings?" And the product team ships something that gives the new persona slightly more access to a system still fundamentally built for the original persona. Adoption is low. The team concludes that the new persona doesn't want the product. What actually happened: the structural problem wasn't solved.
The governance challenge you can't skip
Here's the second failure mode, often right behind the first: when you do give non-technical users more control, you immediately create a governance problem. How do you prevent them from breaking things?
The wrong answer is to limit their control enough that they can't break anything important. That also means they can't do anything meaningful, so you've built a safe but useless feature.
The right answer is structured flexibility. Technical users define the guardrails — the design components, the layout blocks, the templates, the brand constraints. Within those guardrails, non-technical users have genuine creative latitude. They can compose, experiment, and publish without waiting for a developer. But they can only compose from building blocks that technical users have approved and configured.
This model requires explicit product decisions about who controls what at each layer. It also requires explicit conversations with the technical stakeholders in your customer organizations — the developers and architects who currently own that layer — about what they're willing to hand off and what constraints they need in place. If you don't address their concerns directly, they'll find ways to work around your new feature or simply block adoption internally.
Three questions to answer before you start building
If you're planning a persona expansion, these three questions will save you a year of building the wrong thing:
What decisions does the new persona actually need to make independently? Don't start with "what do they do today?" Start with "what are they trying to achieve that they currently can't do without help?" There's a big difference between a marketer who wants to edit copy (mostly a UX problem) and a marketer who wants to build new page layouts (a structural problem).
Where does that information currently live, and who controls it? Map the dependency. If the answer is "in frontend code, controlled by the engineering team," you know the scope of the infrastructure work before you've written a single spec.
What will the existing persona (and their technical stakeholders) accept giving up? This is the political question most product teams avoid, but it determines what's actually buildable. If the engineering team at your customers will reject any solution that doesn't give them audit logs, version control, and rollback — build those first. They're not nice-to-haves; they're the cost of entry for the expansion to work.
How AI changes the equation
One of the most significant things AI does in this context is change the economics of what non-technical users can accomplish independently.
Previously, tasks that required real skill — creating content variants for different audiences, adapting designs to different contexts, maintaining brand consistency across hundreds of pages — required developers or designers even when you'd solved the structural access problem. The cognitive complexity was genuinely high.
AI can now automate many of those tasks. When technical users have structured the building blocks correctly — semantically meaningful components, actionable brand guidelines, organized content — AI can generate variants, adapt compositions, and personalize at a scale no human team could match. Non-technical users can prompt for what they need rather than constructing it manually.
This changes the ambition level that's realistic for persona expansion. Things that previously required too much technical skill to delegate are becoming automatable. The structural work still has to happen — you still need the building blocks layer, the governance architecture, the right access model. But once that infrastructure exists, AI dramatically expands what non-technical users can actually do with it.
The thing most product teams learn the hard way
Persona expansion is one of the highest-leverage growth strategies in B2B SaaS. When it works, you're selling deeper into accounts you already have, adding revenue without a new sales motion. But the path from "we want marketers to use this too" to "marketers can genuinely work independently" requires solving the structural problem that created the dependency in the first place.
Don't skip that step. Don't try to paper over it with a simpler interface. Identify the dependency, understand its root cause, and build the infrastructure that removes it. Everything else follows from that.