Building High-Performing Product Cultures | Follow for advice on how to build product operations strategy
Expecting your PMs to know SQL is a product operations anti-pattern. They're wasting their time trying to debug code. They should be spending time learning more about your users. Instead, invest in making your data accessible to them. Let them focus on searching for customer insights. And you know who else might benefit from accessible data? Marketing. Customer support. Sales. And there aren't any debates about people in those departments learning SQL. So empower everyone to be able to find and interpret the data they need, instead of keeping it walled off in a database that only the most technical at your company can access. You know who spends all day thinking about systemic challenges like this that are blocking your company’s growth? (besides me) Product ops. Drop me a line if you’re trying to find all the ways to empower your teams and speed up development.
Matt Long
4w
I fully agree. I've even seen PMs create SQL queries they thought were right only to draw incorrect conclusions because a given field was deprecated. Much like engineers abstract complexity through APIs, data teams should abstract that complexity away for decision-makers. Duolingo really does this right with its segmentation tool. It allows many calculations in a GUI, expects metadata to be annotated with what they do, and warns (in a few ways) if a field is out of date. This lets our data scientists focus on high-leverage work and our PMs focus on shipping products.
Tami Reiss 🚀
4w
I had to learn SQL when I joined Justworks in 2018 because product operations wasn’t a thing yet… I invested a lot of time debugging code (and unearthing that some math had been done wrong by my predecessor), but the highest impact things I did came from learning more about our customers… the sql only helped produce the reports to display that impact… I wish there had been product operations to help me and love that the function caught on steam during my time there.
With the advent of easy-to-use BI tools, the need for a PdM to "know SQL" has reduced to only very specific circumstances; it's barely even a "nice to have" in most contexts nowadays.
Suwaid K.
4w
select * from TableName 🤓😎✌️ I think a PM must be able to if they want to, especially now with gen ai tools to help write the query. It's a way for interviewers to select candidates who can do adhoc analysis if they want to. Do it once, and automate if there's a trend to monitor
Cody Herring
3w
even better, make sure your PMs have good relationships with your devs/data people, and that assisting the PM with these questions is *actively rewarded* so you don't get into the pattern of "ugh, PM is wasting my time with more questions, I just want to work on my sprint items"
Jeffrey V.
4w
Jenny Wanger the two most common times I see this is when it is a data product, or more commonly, they want a data analyst disguised as a product manager. The former makes some real sense as you want to understand user problems more deeply. The latter is obviously in-line with your sentiment.
I couldn't agree more!
Director of Product Management
3wI couldn’t disagree more about how useful SQL can be to PMs, especially Product Ops. The type of work PMs are doing requires exploration that generally goes beyond what a dashboard or data cube can provide—that should be the starting point to anchor the analysis upon, but competence with SQL makes PMs that much more efficient. The gap is governance—PMs shouldn’t be writing SQL from scratch, but using well-known metrics governed by the organization. Tying your product’s operations to a business KPI to demonstrate the effectiveness of that product is rarely straightforward or easy and requires the kind of thoughtfulness and partnership well within a PM’s skill set. At minimum, a PM should be able to use the data within their own product to do analysis that drives a product strategy.