Building Genie Changed Me
This is the story of building Genie — from personal experiment to organizational platform — and the three mental model problems we had to solve to design for agentic AI.
What is Genie?
I built Genie, an agentic orchestration layer for delivery operations that redefined how we approach projects and client work. It connects to the systems and operational data a team already works in, continuously synthesizing context, surfacing insights, and automating routine workflows without manual intervention.
Genie is what happens when you give an agent access to your operational data, and the ability to take action.
But Genie didn't start as a platform. It started as a way for me to protect the part of my work I cared about most.
Reclaiming Creative Focus
My work was evolving, and so was the industry around me. I found myself moving constantly between design systems, audits, requirements, and component mapping. Across projects, the pattern was always the same: gather information from a dozen places, shape it into user stories, rebuild requirements I'd written versions of before, run familiar audits, and assemble design backlogs that would inevitably shift once the project got moving.
None of that work was wasted, but it consumed energy I wanted to spend elsewhere. Every hour spent on routine, mechanical tasks was an hour not spent on judgment, insight, or problem-solving — the creative core of design. The challenge was protecting creative focus so I could do better work.
A Personal Experiment That Got Out of Hand
I started experimenting in small pockets of time. Thirty minutes between design reviews, an hour on a Friday evening, playing with automations, custom GPTs, and scripts that could run audits, generate user stories, and map components.
I was learning things I'd never touched before, workflow orchestration and agentic patterns, to solve problems I'd never encountered before. I had to learn AI development properly and truly understand how agents work, because I was building one to solve real design problems. Curiosity turned into a passion project, and an education I hadn't planned on.
I showed some of the experiments to the team and the questions came quickly. Could Genie run this audit for us? Could it generate user stories for our scope? Could it help with component mapping?
It turned out my problems weren't unique. Every designer was spending creative energy on routine tasks when they could be solving novel challenges. What started as personal reclamation could become organizational reclamation.
From Personal Tool to Product
Building Genie as an experiment for myself was one thing. Scaling it for an entire team was something else entirely — and it meant not only that Genie had to become something new, but that I did, too.
I didn't stop being a designer. I was still in the trenches, shipping features, gathering feedback, making tradeoffs. But I had to learn product thinking by building for other designers, not just myself. I had to learn how to lead without formal authority, champion a vision while remaining an individual contributor, and make decisions that affected people with very different workflows and concerns.
When I brought Genie to leadership, they saw what I was beginning to understand: this wasn't just a productivity tool, it could change what kind of work we focus on. Instead of spending time on routine and mechanical tasks, we could invest energy in the novel, strategic work our clients actually value.
So I pitched the vision. A supervisor agent with access to design and project data. An orchestration layer capable of running audits, generating requirements, recognizing design patterns, surfacing insights in real time. A system that freed designers to focus on user problems that actually require human judgment.
Building toward that vision meant going deep into things I didn't fully understand. Complex integrations, hard decisions about what should be automated and what should remain human-centered. It was all new technical territory that designers aren't usually expected to navigate.
I had to learn when to admit I didn't know enough and ask for help, and when to accept that some problems were bigger than my current expertise.
Building a Product, Rebuilding Yourself
Building Genie from a personal tool into an organizational platform reinforced something I believe deeply now: the fastest way to grow is to solve real problems at scale.
You don't become an AI developer by taking courses — you become one by building something that forces you to understand how agents actually work. You don't become a product manager by reading frameworks — you become one by making hard tradeoffs and listening to real feedback.
I became an AI developer, a workflow orchestration practitioner, a product thinker, a designer who builds agent systems and understands the intersection of design, development, and AI. But most importantly, I stayed a designer. Genie didn't pull me away from what I love. It gave me back the time and creative energy to focus on it.
What surprised me was that leading from the IC level isn't a compromise — being close to the work made me a better advocate for it. The harder adjustment was scale: knowing when to go deep on a problem versus when to step back and let others carry it. That tension doesn't go away. You just get better at reading it.
The Hardest Part: Building for Others
Having a good idea is the easy part. Convincing exhausted teams to adopt something new is what's hard.
Teams are already stretched, and when we ask them to learn new tools, change workflows, and trust an agent with requirements they used to own, some people are curious — but as many or more are skeptical or simply too tired. Worries about losing human connection to the work, or trusting an agent understands what's needed, or fears of what automation implies hold people back. Those are legitimate concerns, coming directly from the people doing the hard work.
When I built Genie for myself, I could move fast. Building for others meant listening, slowing down, and accepting that usefulness isn't universal by default. It has to be earned.
Some days are hard: adoption is slow, it feels like nobody gets it. Other days a team tells me Genie saved them hours, helped them catch something they would have missed, or gave them space to focus on what they care about. Both kinds of days, and all the ones in between, are the reality of building something real.
Building for others meant understanding why people resist, what they're afraid of, and creating something that actually addresses those fears.
Becoming a Junior Product Manager
I get a lot of feedback now about product management. Do you have a vision document? A roadmap? Success metrics?
When you're deep in the work, unblocking issues and shipping features, those questions can feel jarring. But they're not criticism — they're what happens when something outgrows its original scope.
The irony isn't lost on me. I might be a strong designer and a capable developer, but I'm a junior product manager. It means Genie outgrew me as a personal tool and became something that requires product thinking.
Building Genie changed what I'm capable of building next.
Read the case study: Designing Genie →
