How I Overcame the Technical Gap as a PM at Holistics

When I joined Holistics during the 2.0 era I felt like someone had tossed me into the deep end of a data warehouse without floaties.

For context, Holistics had already shipped its first version in 1.0, we were polishing the big 2.0 rebuild I walked into, 3.0 was on the horizon, and the company is now on 4.0.

Holistics is a full business intelligence platform with ETL, modeling, SQL, dashboards, and exports sitting in one neat row. Our customers were mostly analysts, the product felt powerful and unapologetically technical, and even the public docs read like they assumed you spoke fluent warehouse. Fun first job, right?

I was also PM number two. The first PM was our product lead, everyone else was running at full speed, and onboarding was basically "here is the product, ping us if you get stuck." Spoiler: I pinged a lot.

The scramble to get up to speed

My only plan was "inhale everything." So I did.

I read every public doc at docs-v2.holistics.io, even the tricky bits I barely understood.
I clicked through the product like a nosy customer, broke more than a few flows, and then chased down whichever engineer owned the code path to explain what I had done.
I sat with support tickets, FullStory sessions, and any internal meeting that would let me lurk.
Nights turned into a mashup of analytics blogs, ETL explainers, and competitor teardowns. Hi Metabase.

Progress was slow. The docs were dense, internal notes were scattered, and my SQL skills were more aspirational than real. I had never touched ETL. Even experienced engineers needed time to grok Holistics, so you can imagine me secretly Googling acronyms during standups.

Where the gaps showed up

Knowledge gaps

Holistics covered the entire data value chain, but most public docs were written for seasoned analysts. Lots of jargon, very few stories.
Internal documentation lived in random bullets. There was no single place that showed how the building blocks connected.
With only two PMs, onboarding meant collecting clues from meetings and Slack threads. Every answer required three follow ups.

Skill gaps

Even if the docs had been perfect, I still lacked the technical muscle to absorb them quickly.
My SQL vocabulary and ETL experience were shaky. I had read about ETL, never practiced it.
I did not have a demo dataset or scripted use cases, so learning the feature surface meant poking at the real product like a kid pressing buttons in an elevator.

The turning point

Right when I was drowning in context we picked up a customer project: help them stand up Holistics end to end and deliver the dashboards they needed. Our CTO asked who could take it. Everyone was swamped. I said yes before I could back out. The job was basically "write the queries until the dashboards sing" and I still relied on cheat sheets for basic SQL.

That project changed everything. Shipping the reports forced me to learn SQL the honest way. Cleaning their Google Analytics plus spreadsheet combo taught me ETL more effectively than any course. Building their charts sharpened my sense for what good storytelling looks like. Sitting with the client gave me the analyst mindset I had been pretending to understand. None of it felt like neat PM work, but I finally understood why the product behaved the way it did.

It was messy. Long nights, plenty of rewrites, moments where I wondered what I had signed up for. But it was the good kind of struggle because the customer was waiting and the outcome was tangible.

Fast forward

The payoff kept compounding.

I learned the product inside out by solving a real use case instead of reading about one.
My product judgment sharpened because I now felt the same pains our customers described.
Holistics grew up too: better docs, repeatable discovery templates, more PMs, smoother onboarding. None of that happened overnight, but we earned the maturity.

What I took away

Memorizing PM frameworks is cute until you need to make a call without real context. Product fluency beats theory every time.
Learning by doing wins. Use the product, shadow the jobs to be done, notice the gaps, and you will know what matters tomorrow morning.
When you are new, say yes to the scary projects and ask the awkward questions. That is how you catch the train before it leaves.

That is the story of how I bridged the technical gap. I said yes to one messy project and let the hard work teach me what the slides never could. If you are the new PM on a technical team, grab the hairy problem. You will leave with stories, a few scars, and confidence that no onboarding checklist can give you.

And if you ever want someone to debug SQL while sharing snacks, I am around.