AI Made This Delivery Head a Founder
Michael Gold spent 15 years in project management before AI gave him the leverage to finally build the software product he'd always wanted. His story isn't about AI turning PMs into founders — it's about removing the last excuse for the ones who already were.
Michael Gold
AI Access: AI gave nontechnical founder a practical way to prototype software, reducing barriers without replacing technical expertise.
User Insight: Michael's firsthand project management experience shaped Aria around practical frustrations, approachable design, and cautious AI assistance.
Weekend Prototype: A weekend prototype proved the concept, but engineers remained essential for security, architecture, billing, and reliability.
PM Advantage: Project managers already define work, manage competing priorities, and handle uncertainty—skills that can support entrepreneurship.
Market Shift: AI now lets practitioners turn accumulated software frustrations into tested products instead of waiting for vendor roadmaps.
When Michael Gold was 15, he ran his own events company, putting on gatherings for 500 people. His dad ran his own business his whole life. Entrepreneurship wasn't an aspiration in his family so much as an assumption.
And then, somewhere along the way, he gave it up.
"As I grew up, I kind of got scared out of being an entrepreneur," he told me. He built a career in project management instead: nearly 15 years of it, starting in creative fields before moving into tech. About two years ago he went fractional, founding his own project management agency and working as a fractional head of delivery across startups and enterprise clients. By any measure, a successful path. But the entrepreneurial itch never fully went away. It just went dormant.
Create a Free Account to Read More
Unlock this piece and join a community of forward-thinking leaders discovering tools, playbooks, and insights for thriving in the age of AI.
Have an account? Log In
I grew up, and got scared out of being an entrepreneur.
This month, more than two decades after those first events, Michael launched the software product Aria, a professional services automation (PSA) tool. He's building it with a small founding team that includes his wife Rachael, an illustrator.
I've interviewed Michael twice over the past few months, and across both conversations the same question kept surfacing: what changed? Because he's not a developer. He never became one. What changed is that AI made not being one a smaller problem than it used to be.
It started with irritation, not ambition
Michael's route into building software didn't begin with a business plan. It began with small, familiar frustrations.
Rachael had built his agency's site on Wix, and every change had to go through her. "I really hated relying on her to do everything," he said. So he plugged the site into an AI coding tool. "Within an hour I had the same website, but one I could now control." Next he vibecoded his own CRM to replace a $100-a-month subscription that felt absurd for a one-person operation. It wasn't better than the real thing, and he'll tell you so, but it did what he needed and, crucially: "it was really fun to build it."
That experience surfaced a question he'd never had the leverage to ask before:
"Something like HubSpot has to have every possible feature to service every possible client. And so it costs how much it costs because it is an incredible tool. But if you only need 0.5% of that tool, there becomes a question of, why am I paying for the other 99.5% of it?"
It [Hubspot] costs how much it costs because it is an incredible tool. But if you only need 0.5% of that tool, there becomes a question of, why am I paying for the other 99.5% of it?
Each small build made the next one thinkable. This wasn't someone deciding to become a software founder. This was a project manager solving his own problems and, in the process, quietly rebuilding the confidence he'd lost.
He'd already lived the problem he's now solving
Here's the thing about software, historically: the people who built it and the people who suffered from it were rarely the same people. Building a product required developers, UX designers, and product managers. The end user’s role was to file a feature request and hope for the best. The distance between the person feeling the pain and the person shipping the fix was a support ticket, a feature request portal, an account manager, and someone else's product roadmap.
Michael has spent years on the wrong side of that distance.
Eight or nine years ago, he joined an agency that had rolled out a new PSA platform the week before he started. His reaction was not mild. "I almost quit during my probation because I thought it was the worst thing in the world. I hated it so much."
He raised it with the owner. He wanted the tool gone. Then something unusual happened; he ended up on the vendor's product beta roadmap. "I helped them shape the tool," he said, and as the product improved with practitioner input, so did his relationship with it. "I went from being this guy that almost quit during probation to eventually adopting it and then becoming the internal champion."
That was the old model of practitioner influence: get lucky enough to land on a beta program, and shape someone else's product from the outside. Add the years his agency has spent implementing PSA tools for clients, and Michael has seen this category from every seat except the builder's chair. He knows exactly where these tools grind: the clunky onboarding, the cold, joyless interfaces. "I don't think any PSA tools are particularly pretty. I don't think they're enjoyable spaces to be in," he said, which is why Rachael is on the founding team and why he "really wanted Aria to feel like a warm and welcoming place."
I don’t think any PSA tools are particularly pretty. I don’t think they’re particularly enjoyable spaces to be in. Which is why I wanted Aria to feel like a warm and welcoming place.
He also knows, from watching real delivery teams rather than LinkedIn, that most PMs still aren't touching AI, which is why Aria's assistant flags issues and asks before acting rather than running autonomously. "Agents to me, whether or not they should be, sound scary," he said. "I think it's just a lower barrier to have a friendly assistant that is just in your corner."
None of these are insights a product team could get from user interviews. They're scar tissue. Michael isn't guessing what frustrates a PM at 4pm on a Thursday. He's been that PM. What's new isn't that practitioners have this knowledge. It's that they can finally act on it directly.
From prototype to product
The proof came in a single weekend. When his co-founder James floated the idea of building a PSA tool themselves, Michael initially said no. This is genuinely complex software, the kind that holds a company's most sensitive operational and financial data. "There's no way I'm vibecoding a PSA tool," he remembers thinking.
Then, without telling anyone, he sat down at the keyboard. "I spent 24 hours vibecoding. It's so addictive. And so, literally in the space of a weekend, I had a prototype that was a PSA tool that did everything a PSA tool should do. Or at least it looked like that on the surface."
In the space of a weekend, I had a prototype that was a PSA tool that did everything a PSA tool should do. Or, at least that's what it looked like on the surface.
That last sentence matters, and Michael is emphatic about it. The prototype was the beginning of the work, not the end. The months since have involved a full-stack developer handling security, billing, and the deeper architecture. Experienced CTOs have reviewed the code and sit in advisory roles. The product recently passed CASA Tier 2, a third-party security verification.
"There's still bugs, of course. So the idea of you're just going to just vibecode a PSA tool is just nonsense."
The idea that you’re just going to vibecode a PSA tool is just nonsense.
So, if AI didn't build his product, what did it do? "I could have never designed this with a pen and paper."
This is the translation layer dissolving. Michael couldn't have written a spec or wireframed a UX. A decade ago, that would have been the end of it: the idea stays trapped in the practitioner's head, the way founder ideas have died quietly inside project managers forever. Instead, AI let him think visually and iteratively, smashing at a prototype until fifteen years of accumulated end-user scar tissue took shape in front of him. Something he could react to, refine, and hand to actual engineers.
He calls his current workflow "a very structured version of vibecoding," where he handles smaller fixes and feature amends "under the remit and governance of technical people."
"The idea that a non-technical founder in a startup is able to really continue to move the product along has been amazing. But the caveat is I needed to partner with people who were more technically literate than myself."
Was it the PM skills all along?
I wrote recently about project management as an entrepreneurial skill set, so I put the thesis to Michael directly: are PMs better positioned to become founders than people from other backgrounds?
He agreed with parts of it. PMs have "a higher propensity of dealing with stress," he said. They context-switch constantly and juggle concurrent priorities, where other disciplines get to focus on one thing. And critically, they define their own work: "A PM will give a graphic designer a job to do for the day, whereas a PM has to work out what that job is. And that is entrepreneurship."
But then he flipped my premise on its head.
"I think, because I was an entrepreneur early on, that's why I was good at project management. Rather than project management has honed my entrepreneurship skills. I think I was always an entrepreneur and that's why project management was a natural fit."
I think I was always an entrepreneur and that’s why project management was a natural fit.
In other words, the causation runs backwards. Project management didn't make him a founder. Being a founder-type made him a good project manager, and the profession became a comfortable place for that energy to live while the actual barrier, building the thing, remained too high.
I'd bet Michael isn't an edge case. How many practitioners are sitting on a decade of scar tissue about the tools they use every day, with no way to turn it into anything but feature requests? People who like owning outcomes, defining the work, holding the whole system in their head. People who know exactly what's wrong with their software and, until recently, had no way to show anyone what right would look like.
For that group, the past two years changed the equation. Not because AI turned project managers into entrepreneurs, but because it removed the last excuse for the ones who already were.
If you’d like to learn more about what Michael and his team have been up to, you can check it out here.
—--------
Want more insights like these? Sign up for a free DPM account to hear from more experts like these.
