Our operations manager at Aerones had been asking for a rostering tool for two years. Two years on the product backlog. Never prioritized. Always pushed to next quarter.

With the Citizen Builder program, he built it himself in two weeks.

He mapped the workflow, identified the jobs-to-be-done, prototyped with Claude, tested with his colleagues, iterated three times, and shipped using in-house AI toolkit. A working tool his team uses daily.

He’s not an engineer. He’s someone who understood his problem better than anyone and finally had the tools to solve it.

This is the part of the AI transformation that almost nobody talks about. Everyone’s focused on software teams or Product Builders, the people who own core products. But there’s a whole second layer.

And here’s what makes it urgent: most companies gave people AI tools without giving them structure. McKinsey found that only 5% of organizations see meaningful results from AI. The rest got tool adoption without transformation. The Citizen Builder program is the structure that turns adoption into impact.

The problem nobody solves

In every company I’ve worked with, Mailigen, Pipedrive, Aerones, the pattern is the same. There are hundreds of internal problems that never make it to the product backlog. Ops teams working around broken workflows. Finance teams copy-pasting between spreadsheets. Customer success teams manually tracking things that should be automated.

These problems don’t get solved because they’re not “product” problems. They affect 5 people, not 5,000. The ROI doesn’t justify pulling an engineer off the roadmap.

So people build spreadsheet workarounds. They duck-tape processes together. They hire another person to handle volume that a tool could manage.

AI tools changed the economics. The question isn’t whether people can build, they can. The question is how you structure it so you get innovation without chaos.

Three tiers of building

Without governance, giving everyone AI tools creates a mess, tool sprawl, data fragmentation, security gaps. With too much governance, nobody builds.

The answer is a tiered system:

1. Tier 1: Core Products. Product Builder’s domain. Full quality gates, Gate 1, Gate 2, mandatory prototype, the whole operating loop. Production-grade standards. No shortcuts.
2. Tier 2: Internal Functional Tools. Primary Citizen Builder territory. Internal dashboards, workflow automations, team tools. Lighter review. Technical Expert consults early. Access limited to team or function. This is where the biggest untapped value lives.
3. Tier 3: Power Tools. Personal productivity scripts and utilities. Minimal gates. Individual or small team use. If it breaks, nobody outside your desk is affected.

Each tier has different guardrails. Without tiers, you get anarchy. With too many tiers, you get paralysis.

Product thinking before AI tools

Here’s where most “AI adoption” programs go wrong: they start with the tools.

“Here’s Claude. Here’s Cursor. Go build something.”

And people do. They build things fast. The wrong things.

Lovable, the AI development platform that hit $40M ARR in 2 years with 100 people, proves that AI makes building trivially easy. Their founder Anton Osika’s insight cuts to the core: the bottleneck has shifted from “who can build it?” to “who knows what to build?”

At Aerones, every Citizen Builder, before they touched any AI tool, learned the same fundamentals:

1. Problem discovery. Who has the problem? How often does it happen? If you can’t say it in one sentence, “[User] struggles with [X] when [Y], causing [Z]”, you don’t understand it yet.
2. Workflow mapping. Draw the end-to-end flow. Every trigger, step, handoff, outcome. Mark where the pain occurs. Most people skip this and jump to solutions.
3. Jobs-to-be-done. At each step, what is the user actually trying to accomplish? “I need to gather data from 5 sources into one view so I can finish in 30 minutes instead of 2 hours” is a JTBD. “Add a dropdown” is not.
4. Prototyping and iterating. Build the smallest thing that could work. Show it to the person who has the problem. Get feedback. Iterate 2-3 times minimum.

The Citizen Builders who did this discovery work first built things that people actually used. The ones who skipped it built impressive-looking solutions to problems nobody actually had.

The graduation path

Some of the best product ideas at Aerones didn’t come from Product Builders. They came from Citizen Builders prototyping Tier 2 solutions that turned out to solve a problem the core product should address.

The path: Citizen Builder prototypes an internal tool. Team starts using it daily. Other teams notice. The Product Builder who owns that domain evaluates it. If it fits, the solution graduates into the core product through proper quality gates.

Edge experimentation feeding the center. The people closest to the problems discover the solutions. The Product Builders bring the engineering rigor and system coherence.

Several of our AI champions at Aerones started as Citizen Builders, non-engineers who built internal tools, proved their capability, and eventually became Product Builders themselves. The program became a talent pipeline, not just a productivity tool.

How to launch the program

The playbook we used at Aerones, in five steps:

1. Nominate 15-20 domain experts across functions. Not engineers. People close to real problems and motivated to solve them.
2. Run a 30-minute workshop. Problem discovery, workflow mapping, JTBD. Not optional. Show them the loop: Know Your User → Name the Problem → Size Impact → Map Workflow → Layer JTBD → Prototype → Iterate.
3. Give them one week. Deliverables: user persona, problem statement, impact estimate, workflow map, at least one JTBD, working prototype. Deadline creates focus.
4. Pair each builder with a Technical Expert consultant. Not to build for them, to guide. Catch data issues, security gaps, system conflicts early.
5. Evaluate on thinking, not polish. Problem clarity 25%. Workflow quality 20%. Solution fit 25%. Working prototype 20%. Presentation 10%.

Strong performers get continued investment, active development, dedicated time, mentoring. Others keep the tools and learn independently. Not everyone becomes a builder. The ones who do will have outsized impact.

The company expectation

One thing I want to be direct about: this is not optional exploration.

When leadership invests in a Citizen Builder program, the expectation is that nominated people will learn this craft. This is a skill the company needs them to develop.

Ambiguity about expectations kills programs. Clarity builds capability.

---

I built the Citizen Builder program at Aerones, the workshop, the evaluation framework, the three-tier governance system, and the graduation path. If you want to unlock your non-engineering talent, I can help you design and launch it. DM me on LinkedIn or reach out at operatingleader.com.

---

Next in this series: Your Job Isn’t to Build Anymore, what does an architect, strategist, orchestrator, and coach actually do day to day?