🎧 Why Learning SQL is a Waste of Time (and What to Do Instead)
There's no "perfect" set of skills for a Product Manager. By definition, product management is a generalist role and the most important skills you need at any given time will vary based on your product, your team, and your tech stack.
Instead of trying to become an expert in every skill (which, c'mon, is cray cray!), I'll talk you through what I recommend instead.
Spoiler - it's NOT to learn SQL.
Curious about how product management career coaching can help you grow in your product career?
🚀 SPRINT: A coaching program for product managers trying to land their first (or next!) PM job and need explicit direction and communal direction, which includes but isn’t limited to resume guidance, interview prep, and job search strategy.
📈 SCALE: A private 1:1 mentorship program for newly-hired product managers who want to make an impact fast and who need a safe space and tangible guidance to thrive.
✨ SHINE: A personalized 1:1 coaching program for experienced product managers who want to position themselves for a promotion or more leadership, who need a roadmap to level up and get unstuck.
-
Jess Sherlock (00:00)
Product management by definition is a generalist field. And leaning into that as a strength can be not only something that helps you feel better the field
But I think it can also change the way that you think about development and growth as a product manager in a way that is actually more productive and more sustainable, especially given the role that AI is playing in our careers.
Jess Sherlock (00:25)
Welcome to another episode of AFTER THE CERT the career podcast for product managers who've collected all the certifications and taken all the courses and still feel stuck in their product career. I'm your host, Jess Sherlock, product management career coach. I know firsthand what it feels like to be overwhelmed, lonely, and stuck in your product career. And I'm on a mission to help you feel confident and empowered to take the lead your product career and achieve your unique career goals.
on me for practical and actionable advice, plus relatable stories from PMs navigating the messy middle of their career.
And remember, if you're feeling stuck with your product management job search, worried about making a great impression during your first 90 days in a new product job, or you want to position yourself for a promotion at work, I'm here to help. You can check out my coaching programs at jesssherlock.com/apply.
and book time on my calendar so we can chat.
Let's get into it.
Jess Sherlock (01:22)
Today I wanna talk about one of the most common questions that I get asked and that I see being asked on sites like LinkedIn. And that is, should product managers know fill in the blank skill? So sometimes it is, should a PM know SQL? Should a PM know HTML and CSS? Should a PM know Python? And...
What I've noticed is that typically this question is coming from PMs who are job searching and maybe they're seeing this skill as a requirement in job descriptions. Other times it's coming from product managers that feel stuck. And I think it's coming from a place of fear. So here's my hot take. I think that collecting certifications and skills and courses
is actually a form of procrastination in our community. Like I said, I think it's a little bit fear-based. It comes from a good place of saying, well, you know, if I just take this course or if I just learn this skill, then I'll be better. I'll be more hireable. I'll be more likely to get that promotion. But it's not likely.
At the end of the day, PMs are here to solve problems for customers that create value for the business. And skills that you are going to need will be different at every company that you work on because your skills and your day-to-day is sort of this reflection of the people on the team around you.
the product and the tech stack that you're working inside of. I often say that the PM sort of functions as like the glue and fills in the gap in between the other members of the team. And so if you, for example, don't have a data team, I would expect that you'll need to have a little bit more skills in the way of data. If you don't have enough designers, which is a really common situation,
you may need to really build your skills in research or even wireframing and prototyping a little bit more so than if you had designers on your team. But remember, product is a generalist role. So by definition, this means that we are not specialists in any one thing. And that can be unsettling. Trust me, I know. I have felt that before in my own career. And
It makes sense to me logically that it feels tempting to want to specialize. It feels like something we can control, right? But I'll ask you, when you think about the best PMs that you know, what makes them great? I'm guessing it's not just one thing. It's not a particular skill.
I here, when I think about the great PMs in my network or PMs I've worked with in my career, here are the things that come to mind for me. These folks exude leadership. They are the people who are calm under pressure. They are able to state a clear and compelling vision. They're inspiring to follow. These people have a just deep
an endless understanding of their customer, their problems, their customers desires. They're constantly learning. These are the people who are open to new ideas. They're endlessly creative and definitely have a growth mindset. And, you know, they're the people who get shit done no matter how difficult the problem, no matter how complex or ambiguous the situation, no matter how frustrating the people or the politics might be.
These are the PMs that I think of who I know will figure it out and they will navigate any obstacle that gets in their way. When I reflect on the people I've worked with or I've crossed paths with in my career, I struggle to imagine a specific skill that really made or broke that person's career. And there's a book that I read,
a few years ago that really changed the way that I think about being a generalist. It's a book called Range and the subtitle is Why Generalists Triumph in a Specialized World. It was written by a guy named David Epstein and it really helped me appreciate the value that there is in being a generalist. So essentially he looked at a lot of different people across different fields
to see whether generalists or specialists tended to succeed more. And what he found is that in fields that are more complex and unpredictable, it was actually generalists that would excel. So when you think about specialists, for example, there's this example from the book where they found that cardiologists, for example, I think interventional cardiologists, ⁓
primary tool is to place stents. So if someone has a heart blockage, they will place a stent. But there was some research done where it was a bit counterintuitive that they found that when these cardiologists were gone during a conference and the placement of stents went down, they actually found like higher patient ⁓ success and outcomes, which is very counterintuitive. But that part of the book really stuck with me because
It reminds me of that saying of like when all you have is a hammer, everything looks like a nail. And that's really the blind spot for specialists. Because as you get better and better and better at what you do, as you develop deeper and deeper and deeper knowledge, he calls it a double-edged sword. That basically, it does allow you to do some things very, very well, but it can make you totally blind.
to things that you could do. And so all of this to say that if I could encourage you to walk away from this episode with anyone take away, it's that Product management by definition is a generalist field. And leaning into that as a strength can be not only something that helps you feel better about the field and really
come to terms with what makes you good in product management. But I think it can also change the way that you think about development and growth as a product manager in a way that is actually more productive ⁓ and more sustainable, especially given the role that AI is playing in our careers.
.. I read this book probably two or three years ago at this point.
And this was before AI and ChatGPT and Gemini and all these tools were kind of second nature for us to be using on a day-to-day basis. AI was like kind of out there as a thing that we knew would be coming. But even when I read the book at that point, it changed the relationship that I had with AI because it really made me realize that the...
best use case for AI is going to be the things that are essentially specialist tasks. So for things that are repeatable and predictable, AI is very well suited to take on those things. And quite frankly, I want AI to do those things. don't, for example, as a PM, like if AI can help me
you know, summarize and analyze customer discovery or trends and patterns and support tickets or, you know, look for patterns and trends in product analytics data, then great, right? I would love to have a second brain that can do the tedious work for me so that I can spend my time looking at the information and working to identify new and innovative insights.
So in the book range, there was also this like metaphor that also stuck with me that is like ⁓ something to the effect of like specialists are basically just digging deeper in their own trench. So they're digging and digging and digging ⁓ in their own world and their own trench. And rarely do these specialists literally stand up and look at the trench next to them to see if they can learn anything from it.
And this was just so interesting to me because I think PMs often overlook the inspiration, innovation and creativity that can come from doing things that are not tech, things that are not
So at this point, you're following me. You're like, okay, Jess, I'll buy in, I'll buy it, right? That product managers are generalists and that our goal should not be to become a specialist. But what should I do about these skills that are required for product managers or that I see in job descriptions or that seem to be important to learn? Here's my advice to you.
Rather than focusing on learning a specific tool or programming language, I would strongly recommend first focusing on rounding out your skills across the entire range of skills required to be a product manager. So first and foremost, are you able to identify customer problems through customer discovery?
or market research or competitive research to identify insights on problems that we could solve that would not only help our customers, but that would also create value for the business. Are you able to creatively with your team come up with a solution that can solve that problem with technology? Are you able to work with a development team to scope out
small units of value, get those enhancements or features launched, and then iterate on those things. If you have that foundation with whatever current skills you have, then that's a great start. As you develop as a product manager and you start to understand what parts of the product development process you enjoy the most, what sorts of teams you're on,
or what's most interesting to you personally, then you can look into developing those skills to be a bit deeper in certain areas. So there's a concept called being a T-shaped product manager or being an I-shaped product manager.
So an I shaped product manager, really an I shaped professional, someone who has kind of one skill. So literally you can think of it as like an I, a capital I, where it's just, you know, one deep skill versus a capital T where someone has a broad set of skills that are like an inch deep, but they do go deep in one area.
So the way I suggest developing your skills in product is to focus on the top part of your capital T first, right? Get that sort of inch deep worth of skill across all the areas of product development first. And then make a decision on where you wanna go deep. So there are some common areas where folks go deep. Sometimes it's the result of whatever our career was before product.
In my situation, for example, I started my career in ⁓ UX research and UX design. So I very naturally and comfortably can go deep on things like, you know, customer discovery and interviews and analyzing ⁓ engagement data and product analytics, or even developing prototypes and wireframes. Like those are all things I'm very, comfortable with. I've spent a hot minute in Figma.
⁓ I've had clients, for example, who have a background in engineering, and so it's very comfortable for them to go a bit deep on the technical side. So as you're thinking about developing skills, I would encourage you to be strategic and make that decision based on what is going to benefit you most, not only in your current company in this current season of your career, but also what are you most interested in and jazzed by in your own personal career? So ⁓
If data is something that you're really excited about, then by all means make an investment there. But I don't think it's a one size fits all in terms of which skill you have to develop to grow as a product manager.
So on this question of SQL specifically, here's my hot take. I don't think every PM should be an expert in SQL, but I do think that every PM needs to have at least a basic understanding of data, what I might call data literacy. Now, data literacy can mean a few things, but essentially data literacy is the ability to
understand data. So if you get a data set, can you understand what you're looking at? Can you work with data? So even if you got, let's say, a download of engagement data from your product, maybe some sort of report that showed you how many people visited a certain page and how many people took a certain action on that page, could you understand that data?
look at it, understand it, and at least initially analyze what you're looking at. That's the most basic expectation I would have of any PM. Beyond that, I would love for you to focus on developing your ability to ask good questions of the data. So you might call this data reasoning, but your ability to use that data, generate insights,
ask good questions and maybe develop a plan based on the answers you get out of the questions that you ask of the data. Now, more advanced skills, of course, would be your ability to ⁓ make structural decisions about how our data is stored or even be able to write lengthy complex SQL queries to generate data reports on your own. That would all be great, but
I'd love to share a story that's a little bit more specific of like what it really means to work with data that is a story of something I experienced personally. And I think it's just a great example of how far you can get with relatively limited skills so that you can see that, you you might be able to do more than you're giving yourself credit for. So.
A number of years ago, I was working at a company called GoSpotCheck. And inside of our product, had a mobile app and a web app. And ⁓ the way to maybe think about it is kind of like a survey platform, essentially. So you might think of a tool like Typeform where you could go in and create, or even Google Forms. You could go in and create a survey with various questions. And maybe some of them are
text questions, some of them might be multiple choice ⁓ or check boxes, various things like that. Now our clients decided ⁓ quite often to make adjustments to their surveys. So maybe they had forgotten a question or maybe they just had a typo. And as a company, the way we were handling allowing people to make those edits was creating some challenges downstream with how we were storing the data. So
A simple example might be that if someone wanted to change, let's say an open-ended question to a multiple choice question, so meaning like a text box versus like structured answer where you'd have multiple choices, data reports were a bit challenging because it's like, do you show them the reports based on two questions that have entirely different structures? So that might be a relatively big deal.
Whereas allowing someone to edit a typo in a question wasn't going to generate any issues, right? We could just show the correct version of the question. So all this to say, when we had first introduced a feature called versioning, where we would allow someone to go into their survey and essentially create a new version and make adjustments, we wanted to understand what it was that people were using this for and what types of changes they were making to their surveys.
So you're following me so far and you can understand the product functionality and the reason why that question is important, then you're already doing great. So the hypothesis that I had was I was actually convinced that people were using our versioning feature as a way to preview the survey on their mobile app. So the way that our product worked,
we didn't have great preview functionality. So essentially when you created your survey, it was either live or it was not live. So if you had yet to make your survey live and you wanted to actually see how it looked on your phone, so maybe just literally see how it laid out and see if it was easy to read, that was a really difficult thing to do. And so I had this suspicion that our clients didn't really want to edit their surveys as much as they wanted to preview.
their surveys. And so knowing what I knew about how our system was set up and having worked on this mission versioning feature, I knew that we had tracked, for example, timestamps and various information about a mission, but then also its associated versions. So I had a sense for what I could learn based on the data structures that we had in place. But if you're not familiar with SQL, trust me when I say,
that is an extraordinarily complex SQL query to write. And it's largely due to not just the quantity of information, basically the having to like be aware of the time passage and whatnot. So some of the questions that I had were, hey, I want to understand if people are using this to preview. I was...
well-informed enough on our data structure to have a sense of what might tell me that. So, I had a suspicion that if we took a look at the timestamps on the mission versions, I would see very quick sort of like publishing and unpublishing behavior where...
the timestamp we were storing for whether that version was published or not would be very quick, right? So was imagining, all right, if someone's in there making an edit and then they wanna publish it, take a quick look, and then they unpublish it so they can make another change. If I'm right, I should see sort of these like rapid fire edits in a short period of time.
Whereas if it truly was a version and like a net change to the survey where someone was going in and changing a question I would not necessarily expect to see like a series of adjustments to the mission I would expect to maybe see one change here one change there with a lot of time in between so Obviously if I had known SQL
When I, in fairness, I know I would say I have a one-on-one level knowledge of SQL. I can conduct basic queries, I can do basic joins, but if we get to the point of having to combine and join across a lot of different tables, or if I have to start generating queries that have a sense for state and timestamps, just even translating that data into a way I can query it. And if I'm losing you, this is the point.
I knew enough to know that I wasn't going to be able to do this query on my own. So instead of stumbling my way through writing a query that was probably going to be wrong, I recognized that I knew enough to ask good questions, but I wasn't the right person to make this query. So what I did instead is I actually tapped, we had a team called our BizOps team. And so I put together a request for that team. And actually, I think I had a quick conversation with my contact on that team.
just to gut check that what I was looking to do was feasible. But then I put together some of the specific questions that I had. I literally, almost like ⁓ a project kickoff document, I put together the situation, the problem I was trying to solve, and essentially the hypothesis that I had, ⁓ and some of the why behind it. So you can probably imagine if our clients were using this versioning feature as a glorified preview feature,
I would like to explore building out a proper preview feature for a lot of reasons, not the least of which is that the usability of the product would be better. So I shared all of that context and then I basically laid out a series of questions that I had that I knew I wasn't going to be able to write queries for myself. So I said things like, you know, how many on average, how many versions are there of missions? What are the kind of min, max and average
edit numbers and what are the time periods between these edits? we and essentially do we notice a correlation between number of edits and like the ⁓ time between meaning like if we see a lot of edits a lot of edits happening at once are we noticing that those are happening in fairly short order? what I you know to to run it back the skill here
is really not SQL. The skill here was my data fluency and data literacy, my ability to reason through data, to understand enough about how our data was stored and structured, and to be able to propose clear, actionable questions that if answered would allow me to move forward with a product enhancement of some kind. Now, it turned out I was wrong.
After all of this, I guess the data ended up being ⁓ a really important component of this decision, but it turned out that people were not using this to preview. That was actually a behavior that was being done by our internal teams, funny enough. So some of the ⁓ customer success team members who would help customers set up their surveys, for whatever reason, they had a tendency to interact with the product in this way.
rarely, if ever, did we see customer user accounts using the product in that way. More often than not, what we were seeing was an adjustment to the structure of the question, which ended up being a much more challenging problem to solve. I'll talk to that in a future podcast episode, maybe, if you all find that interesting. But the point is, in this particular situation, I was not the one to write the SQL queries.
but I was the person who was able to ask really important questions of the data and then make a decision on what to do based on the information that those data queries revealed.
So I'd love to know if you find examples like this helpful, because I think that my hunch here is that when I see these conversations happening on LinkedIn or in-person networking groups, or people are debating whether or not someone should learn a skill, we want an easier answer. just, think we're, we want this like hard yes, right? Because it's coming from this discomfort of,
product management being a more generalist field and just wanting, I guess, to have a clearer answer. When in my experience, the answer is that it depends. even if we take this specific situation, right, if I had not had folks on my team who were experts in SQL, I would not, I would have had to take a different path. I...
may have needed to ask for outside contractors, for example, or data analysts that could have worked on a short-term project. But ⁓ I will tell you right now, I would not have been able to learn those SQL skills in the timeframe that I wanted to make those answers clear. So ⁓ that's really what I guess I want to get across to anyone who's listening is that I'm not opposed to you learning skills, but...
what I am opposed to is going out and trying to collect every possible skill in an effort to become an expert in everything, because that's just going to end up frustrating you and ultimately probably burning you out. I think it's much more appropriate to focus on building out those foundational skills first of all, and then as you are growing and evolving in your career and you understand the skills that your team does or does not have,
make smart strategic decisions about which skills you really do want to invest in. And in that particular situation, I had the right skill. That skill was data literacy and the ability to reason with data. It was not to go learn additional SQL skills.
All right, so as always, learning is great, but it's only as good as us putting things into action. So how could you take something that we talked about in today's episode and put it into action right away? And if you're not sure, I want to offer a few options and suggestions.
so if you're on the job hunt right now, maybe you take a basic SQL course if you notice that SQL is commonly being requested as a skill in the jobs you're applying to, but recognize that it's highly unlikely that you're gonna become an expert in SQL without actually using it every day and getting the opportunity to really deeply build those skills. So instead, focus on...
The higher level skill, focus on developing your data literacy. Get access to some data sets. Work with data sets that you already have access to. Maybe you have a personal website that has Google Analytics installed and you can play around with the engagement data on that. Maybe you work at a company that has analytics or data of some kind from the actual product. Maybe you could play around with that.
really just focus on your ability to understand not just SQL, which is a specific querying language, but more importantly, how is data structured? What sorts of questions could you ask of it? And how could you, generate thoughtful insights about the data that you do have access to? And if you get into an interview and they say, do you know SQL?
That's something that really trips a lot of folks up in my SPRINT program. got this question again just this week. ⁓ Rarely is knowing that specific skill going to be a hard pass for a job. And in fact, I haven't messed around in a lot of the SQL tools to see if you're getting the ability to get AI support to write queries. But as a total side note, in ⁓ Google Sheets,
I've been messing around a little bit with Gemini and it's actually really good at writing formulas. So for someone who's been in and around tech for a long time, I am definitely not an Excel ninja by any stretch. But I definitely feel like one recently with the ability to lean on Gemini for writing those actual formulas. So if you know, or if you have a tool that you've been using where this functionality is in there, please let me know. But...
You know, I also suspect that as AI tools and AI support tools like Gemini helping you with Sheets formulas, as those things become more more common, I think the need to develop a specific skill in SQL is going to continue to go down and the need to be able to ask good questions of the data is going to increase. So anyways, all to say, if you get that question in an interview, focus on the higher level skill. So,
Obviously what you don't want to do is say no, I don't know SQL. But maybe what you could say is I do have a little understanding of SQL or I've played around with SQL a bit. But what I'm really good at is understanding data structures and asking really good questions and working with data analysts who can write the specific queries. So answer in the affirmative, but answer about that higher level skill that's actually more important. Okay.
If you're not on the job hunt, but maybe you're in a job right now and you're thinking, gosh, I wish I could develop my skills around data and I'm not sure where to start. Here are some ideas. This is
I give to PMs all the time, especially when they're starting new jobs, but this is something that you can absolutely do if you have a job right focus on understanding your product's specific data structures, because here's what I found is learning SQL is actually totally different than learning your company's data structure. And even if I were an expert, let's say I was an expert in SQL.
Let's say you dropped me in a team at Meta. I don't know how they structure their data. I could make some assumptions. Like probably there's a user object. Probably there's tables where we store people's activity or people's profile information. But like I would have to get in there and understand exactly how we store structure and relate all of that data. I can't possibly know that without actually looking at the database.
So even if I were an expert in SQL, I will have a ramp up time in learning the structures of that particular company's data set. So all of that to say, if you're at a company right now, one of the greatest opportunities that you probably have that you may not be tapping into is getting your hands into data on a product that you actually understand. So ask maybe an engineer, maybe someone on a data team, data analyst team, or...
Maybe you have BizOps or something like I did, but ask for someone on the team to give you a demo or a tour of the data structures. Ask for read-only access to those databases. Have someone walk you through our major and primary tables. Like what are the main tables? How do they relate to each other? And what's really interesting about that is you can start to, what usually happens is you start to see the connections.
to the features that you've built out and maybe decisions that had to be made that you didn't realize were as important at the time. ⁓ Even something as simple as where do we have one-to-one relationships versus where do we have one-to-many relationships? Those are things that you may take for granted, but once you see it laid out in a data set, you start to understand why we've made those choices and more importantly, what questions you can now ask of the data because of how it's structured.
If you can get access to the data, poke around at it and just start, you know, practice asking questions, even silly things like maybe you get access to the user table and you say, okay, let me see if I can figure out how many of our users are in California or how many of our users have logged in in the last 24 hours, right? I'm talking like super, super basic queries and just start to build from there. And what's really
cool is as you start to understand the data structures of your own product, it will also allow you to make better decisions on future features. I tend to really enjoy getting involved in those decisions about what should we store, where should we store it. But I've noticed that a lot of PMs don't really engage with their engineers in those conversations. So maybe you do now. And that's not to say that you make the decisions, but maybe you ask more questions.
right? ⁓ where are going to store this? Why are we going to store it that way? Or why not store that? ⁓ All of these things will start to happen naturally as you start to explore the data and get more comfortable with it. So I'll recap. If you, like I said, if you're on the job hunt, maybe this conversation has illuminated for you some higher level skill that you can focus on, or maybe it's helped you to realize that that's actually not the most important thing right now.
If you have a day job, maybe this has helped you realize that you could take some initiative here to understand your current products, data structures, and ways that you just never really thought about before. Maybe there's something else, but what could you do from this conversation to kind of take some action on a takeaway from the conversation today?
And with all of that, it was great to see you on another episode of AFTER THE CERT. As always, please subscribe so that you can always be notified of the newest episodes as they come out. And if you have questions or topics you'd like me to cover on a future episode, please connect with me on LinkedIn. I would love to see you show up in my DMs or if you want to send me a connection request.
And you can check out my coaching programs for folks who are job searching, folks who are looking to make a great impression in their first 90 days at a new product job, or product folks who are looking to grow and get to their next promotion. So if you want to learn more about my coaching programs, check that out at jesssherlock.com/apply And I'll see you on the next episode of AFTER THE CERT.
