Do Product Managers Need to Know SQL?

Or how I was forced to learn SQL and what it has changed in my career.

After a few years of flirting with product management, after working as a designer and project manager, the day finally came when I started working with product management. It was mid-2013 when I joined Movile with the mission of scaling an internal app store.

During the onboarding, I got to know all the data we had on the product: rows and rows in the database, and a good track record in Mixpanel. Those were good months, Mixpanel data was well organized and complete. All I needed was just a click or two away. Funnels, conversion, churn. Paradise.

“Do you know Mixpanel? This month, it costs $ 30,000 to the company. 80% comes from your product. You need to turn it off ASAP” - my boss told me. We even discussed some options to keep using Mixpanel as the data source, but recording daily events for more than 5 million users while trying to scale the engagement just made things harder. Each alternative was followed by the need to waste precious development time, which we didn't have to spare.

Here we come to an interesting dilemma, is investing time on developing to gain visibility a waste? Never. But what about doing this when there is an even richer source of information available, with no development needed?

We can develop a sampling logic, sending only 10% of the events to Mixpanel. It will take time to develop. Or you can consume the data directly from the DB.

At this point, the problem was not the amount of information available or the insights waiting to be found. The real problem was that all of this was not in a language that I could read — the fateful moment when the PM became the bottleneck. There were options to get the data, but between scaling the product to reach our goals or leaving everything chewed, the PM wouldn’t have to get it from the source. The answer was quite easy. I had to learn SQL.

Movile’s structure worked with a centralized BI team back then, which received demands from all other teams. A prioritization hierarchy met a certain rule: management, finance, sales, and product. It was not uncommon for the product team’s order to take a few weeks to be done.

At that time, I was flying blind. From then on, the modus operandi became dripping people into Slack with the mantra “this is what I need to know” followed by a “thanks, saved my life, please share the query.” Whoever fell into this litany received several questions about how you got a certain result, why this join was combined with that parameter, etc. To not bother someone too much, I ended up diversifying the victims, attacking weekly BI, engineering, and PMs. Always with the weapons I had, modesty and friendship — sometimes I paid some beer, but it is implied on the friendship!

Over time, this mantra got a new line, “I tortured this query and got this new data. Can you please review to see if I’m not messing things?”. I’m saying this daily since then.

In the end, the result I achieved with months of pain and suffering changed the way I work. I still think that all the necessary time should be invested to have visibility of the data democratically, especially to bring stakeholders closer to the results and bring data to the decision-making process. But the freedom to get data straight from the source, manipulate and validate ideas with speed changed the game. And it is not just the time, but fluency in a new language gave me more confidence to make decisions and question directions (which is the PM’s day-to-day life).

Consuming data directly from the database is no longer just a source of information but a source of action. Today, working at Loadsmart and serving an internal customer, having access to data is no longer just a way to consume information but also to enable MVPs. I still ask for help to validate heavier queries, still armed with modesty and friendship.

OK. But where is the answer about PM and the need to know SQL?

In my humble opinion, getting data directly from the DB is similar to speaking a new language. The real outcome of knowing a new language is about the new knowledge you have access to.

Knowing how to speak this language gives you more speed and clarity and puts you closer to the problem. The very process of learning this new language brings you closer to engineering and BI. Asking around for help to understand the query brings everyone closer to the problem. More people knowing about the problem, more chances of finding a solution. More … you got it.

Knowing SQL is not vital to Product Management success, but it is a tool that helps you discover problems faster and indicates where to find possible solutions. What, in the end, is our job.

If you are new to Product Management and have some questions regarding SQL or how to analyze the data you got, let me know in the comments. I am no expert, but I will be glad to help the way I can.