Back 
Before I was a product manager, I was a lawyer. I never coded. Still, last month, I planned, built, tested, and deployed a feature solving a real customer need in our finance operations platform.
I’m writing this down because how I ended up building it changed how I think about what’s actually possible for non-technical team members, and I suspect I’m not the only one on a product team wondering the same thing. It’s also a perfect example of how this profession is changing in an exciting way. Traditionally, product development has relied on a segregated ownership approach—a PM defines the problem, a designer structures the experience, an engineer builds the solution—each handing off to the other. AI is changing that, letting one person move further along that full arc than they could before: from spotting the gap to planning the solution to writing and testing the code itself. We’ve been leading and embracing this change at Tipalti, and I was in a good position to see how far that could stretch.
How It Started
The request landed in my inbox on a Thursday, late in the day. A customer wrote in about their approvers asking a question—could we give them a clearer picture of the available budget when reviewing requests by accounting for additional parameters?
I love this kind of request. Approvers’ decisions run on the numbers we show them, and here was a customer telling us what we could do to make that better—a real need that will drive better decision-making for customer approvers, and of course, other customers as well. This wasn’t a complaint; it was an invitation—the kind you hear and then want to act on. Even walking my dog after work, I kept turning it over: how could we build it for them?
The Prioritization Challenge
Like every company, my engineering team was fully committed to a healthy list of initiatives we’d already planned. Pulling in something new, which was one possibility, wasn’t something I wanted to do. It wouldn’t have just cost us context-switching time. It would have meant pushing something else from our agreed plan, and those items were what we considered most impactful for our customers. Still, from where I sat, this was a legitimate feature improvement, competing for the same limited planning cycle as everything else we’d already committed to. But for our customers, this was about addressing a real need and making their finance process better.
A Chance to Think Differently
The more I thought about it, the more I wanted to do something about it. This seemed like a good time to think outside the box. I figured I was in a good position to try something different. First, I knew this particular area of the product well. I’d already planned several enhancements for this very budget widget. I had the context. Second, I had the tools. I was already comfortable working with AI for research, planning, ideation, and even personal projects. I’d already set up our codebase locally, using it to answer detailed product questions from customers and our operations team. The pieces were already there. Our management strongly encouraged us to push boundaries and try new things.
And so, I decided: I wanted to deliver this myself, start to finish.
Building It Like a Product Problem, Not an Engineering One
I treated the build the way I would treat any feature—write the plan first, in enough detail that someone else can challenge it. The difference was that this plan had two layers: the product requirements I’d always write, plus a detailed technical plan of the actual code changes, which I had the AI draft alongside it.
I read that technical plan closely enough to understand exactly what it would do, then pressure-tested it in a second AI conversation before anything else happened. But the check that mattered most was the simplest one: my engineering Team Lead reviewed the plan before a single line of code was written. This wasn’t me roaming around playing at engineering—it was me bringing them a fully-formed plan before touching anything.
Once the plan was confirmed, the part I expected to be hardest (actually writing the code) took minutes. The main challenges were actually around the areas I imagined AI would be great at: identifying where to add the changes. My first two attempts failed. The first one landed the improvement in an entirely incorrect place. The second relied on the assumption that the data we needed was stored somewhere it wasn’t. Still, I wasn’t discouraged, because the very process that got me this far proved reliable. I found both mistakes myself, during local testing, with zero external impact. The product planning approach proved itself.
Once I was finally in the right place, everything worked. The feature went through all the regular testing and review cadences with the engineering team, and eventually launched to production.
It Shipped. Here’s What Changed.
Since it went live, I can see we’ve already had dozens of requests relying on this enhancement. There have been no exceptions, no follow-up corrections needed—everything works well. This shows me that the effort was worth it and that our customers are seeing the value.
It’s an amazing feeling and brings about a true sense of accomplishment. Being able to go back to the customer and say “it’s done” instead of “it’s on the roadmap” is a different kind of conversation, and it’s one I don’t think I’ll ever get tired of having. I imagine our customers won’t get tired of it, either.
Since launch, there hasn’t been a single customer-reported issue tied to this change. The same process that let me build it (the planning, the review, the local testing) held up in production exactly as it did before. As a PM, this part of the outcome also really excited me. I delivered a sustainable and impactful feature that did not cause any disruption.
What We Can Learn
It’s important to put some context about what this project is and isn’t. It wasn’t magic, and it wasn’t “instant” in the way people might assume when they hear “building with AI.” I still needed real domain knowledge to get the plan right, real testing for quality control, and real days, not minutes, to get from idea to production. None of the parts of this job that actually require judgment got skipped.
Writing the tech plan the way a traditional PM would—leading with intent and context instead of pure implementation detail—made a real difference. It gave AI a much clearer picture of what I actually wanted, while also serving as a source of truth that allowed me to ensure that no context was lost. It also made the review with engineering faster, since everything I was trying to accomplish was laid out up front.
End-to-end ownership speeds up the whole process, but it doesn’t skip the important parts. Our approach, which was already more efficient than the traditional way of working, evolves from handovers, mandatory approvals, and segregated responsibilities into a more flexible model of end-to-end ownership and engaging the people with the right expertise at the right time. I built this myself, but I verified the technical quality with my engineering manager and design quality with my designer as I moved ahead. It’s what allowed it to happen fast, but without compromise.
Tipalti has already built the process and guardrails to make this modern approach possible—the only thing standing in the way now is mindset: recognizing that you’re capable of taking on more.
And what do you know, my next initiative is already being built!
