I’m not a developer. I built a working analytics dashboard for my team anyway. Here’s what it taught me about the real bottleneck holding most operators back.
(First in a series called Built, Not Coded: a field guide for GTM operators who have real problems, imperfect systems, and no interest in learning to code just to get unstuck.)
I have always led with data.
But for too long, getting to the data I actually needed meant rebuilding the same picture manually over and over again.
A few tabs. A few formulas. A few filters. A few judgment calls. Enough effort to get to an answer, but not enough structure to make that answer easy to revisit, share, or operationalize.
That was the real problem.
I led a team of implementation managers onboarding enterprise customers onto a SaaS platform. My team logged hours in a Google Sheet. Customer context lived in another tab. ARR, project status, delivery effort, and team capacity all existed somewhere. But none of it came together in a way that matched the questions I actually needed to answer as a leader.
Which accounts were underserved relative to their ARR? Who on my team was running too hot? Were the customers getting the most effort actually launching on time? Where were we spending time that was not turning into customer value?
I could answer those questions, but only if I stopped and rebuilt the picture by hand.
And that is the difference between having data and having leverage.
If a question takes 45 minutes to answer, it does not become part of your operating rhythm. It becomes something you check when there is a fire, a renewal risk, or a leadership ask. The data might be technically available, but it is not truly usable.
The data was right there. The path to using it was too manual to scale.
Why I sat with the problem for so long
I had the budget conversation. More than once. The answer was always some version of “not right now.”
And honestly, that was fair. A custom analytics tool for one team’s time-tracking data is not where a scaling SaaS company spends limited resources. I understood that. I probably would have made the same call.
What I hadn't really questioned was the assumption underneath my frustration: that solving this required budget I didn't have or technical skills I had never developed.
I had been a GTM leader long enough that I'd fooled myself into turning a belief into a fact (insert my favorite Captain Picard facepalm emoji). Some problems belonged to engineering. Some belonged to ops. My job was to name them clearly, justify the business impact, and push for whatever support I could get.
That assumption turned out to be incomplete and questioning it changed everything.
What actually changed
I had been using AI for a few months by then. The usual operator stuff: drafting messages, sharpening frameworks, cleaning up my own thinking. Useful, but by no means transformational.
The shift happened the day I stopped treating it like a writing assistant/sparring partner and started treating it like a build partner.
I opened a conversation and laid out the dashboard problem directly. Not “help me write something about this.” The actual problem: here is the data I have, here is what I need to see, here is the decision I am trying to make.
In my case, the tool was Claude. But the lesson is not about Claude. It is about the shift in how I was using AI.
What came back was not a vague suggestion. It was a set of sharp, practical questions. What fields are in your time-entry tab? What does the customer data look like? What is the first thing you would want to see when you open this? Then it handed me a starting structure and asked what to change.
That was the moment it clicked.
And what clicked was not “wow, AI is so smart.”
It was something way more useful: The bottleneck I had always assumed was technical skill was now actually problem clarity.
I knew this problem better than anyone. I had been living inside it for years. What I had been missing was not the ability to code. It was a way to translate what I already knew into something that worked.
That reframe is the whole reason I am writing this series.
What I built
I started with a dashboard that pulled from the systems we were already using. The data did not all live in one place. Time tracking was in Google Sheets. Customer and revenue data lived in Salesforce. Project execution data lived in Trello.
I wasn't a Salesforce admin. I didn't have deep system access. What I did have was enough access to build the reports I needed, sync those outputs into Google Sheets, and do the same with Trello data. Once everything landed in one place, I could connect the dots.
That distinction really matters.
A lot of operators assume they need admin rights, engineering support, or API access to every system before they can build anything useful. In my experience, you often don't. You need enough access to get the right data out, a place to combine it, and a clear understanding of the questions you are trying to answer.
The first version was basic: filters, a few charts, and a date picker. But each version taught me something I had not known to ask for, and that helped shaped the next one.
A few pieces ended up mattering most.
Utilization tracking. I already knew the ranges that signaled healthy capacity, overload, or a delivery problem on my team. The dashboard surfaced them in seconds instead of making me reconstruct them by hand.
Account-level drill-down. By combining time-tracking data with Salesforce account information and project data, I could see not just that time was being spent, but who it was being spent on, how that effort aligned to customer value, and what impact it was having on time-to-launch. The visibility that used to require multiple reports and a highly caffeinated working session became something I could see instantly.
Automated reporting. This is where it stopped being a side project. Once I unified the underlying data, I built automated emails for three audiences. CSMs got customer-level paid-services consumption. First-line managers got rollups across their teams. My leader got a portfolio summary with utilization and risk signals. Three tiers, three formats, one system, zero manual assembly.
The commercial impact was direct.
CSMs who used to discover unused professional-services hours at renewal time were now catching them mid-year, while there was still time to turn them into value.
That is not an efficiency win.
That is a revenue story.
What was harder than I expected
It took weeks. Not because any single piece was hard, but because I was doing it around a full-time job and mostly after my two kids were asleep.
There were nights I made real progress and had to stop mid-thought.There were nights whereI had nothing in the tank for such deep thought work. And honestly, I had elements that broke and forced me to walk away and come back fresh.
But the hardest part was never the building, that was fun!
It was the deciding.
Every meaningful feature made me commit to what I actually believed. What utilization range reflected my team’s reality. What level of detail did a CSM need versus what was just noise? What should a VP see versus what belonged one level down?
AI will build almost anything you can describe clearly. The clarity is your job, and clarity takes more thinking than most people expect.
I also underestimated the data. Names that didn't match across systems. Inconsistent formats. Records updated in one place but not another. “Vandelay Industries” in one tab and “Vandelay Industries Inc.” in another is not a technical problem. It is a data governance problem, and the dashboard only handled it because I noticed it and forced a decision.
The gap between a working prototype and something you can actually rely on is real.
Do not underestimate it.
What this means if you are a GTM operator
I’m not sharing this to impress anyone. I'm sharing it because I spent years treating a whole category of problem as out of reach. That assumption quietly cost me and my team real visibility, real efficiency, and real influence.
The issue wasn’t that I lacked data.
The issue was that the data was trapped behind too much manual assembly.
That is the gap a lot of operators are living with right now. Better reporting. Automated communications. Cross-functional dashboards. Cleaner handoffs. More useful leadership views. Most of us carry a running list of things we would build if we had the resources.
My list is getting shorter.
Not because I got a bigger budget or a developer. Because I stopped assuming someone else had to close the gap between knowing what I needed and having it.
A lot of operators are still working as if the old dependency model is the only one.
It's not anymore.
Try this yourself this week
Pick one real operational problem.
Not a tool you want to try. A problem you have been carrying.
Start with something where the data already exists, but the path to using it is too manual. A report you rebuild every week. A spreadsheet you keep filtering. A leadership question you can answer, but only after too much assembly.
Open a conversation with an AI assistant and describe it in plain language.
What information do you have? What do you wish you had? What decisions are you trying to make? What systems are already capturing the data, even imperfectly?
Then ask:
Given everything I have described, what is the simplest version of a solution I could test this week?
You don’t need a perfect vision. You need a clear problem, a useful first version, and a willingness to make decisions as they come up.
That is where the leverage starts.
Next in the series: the operating principles behind everything I have built with AI, and why “start with the problem, not the tool” is harder to actually do than it sounds.
I’m Andrew Pabon. I write about onboarding, professional services, and building leverage as a GTM operator. If this resonated, follow along for the rest of the series.