- JJ Rorie
What Level of Tech Skills Does a Product Manager Need?
Episode 036
While product managers should first and foremost be experts on the market and the customer problem, it’s no secret that some level of understanding of the solution is important.
But what is that level? On this episode, we explore that question. Jan Lukas Haslbeck, founder of NATE, joins to discuss:
The difference between skills and literacy
Why a product manager needs tech skills and/or literacy.
What level of skills a product manager needs
How to break down technical literacy for product managers
Episode Transcript
SUMMARY KEYWORDS
literacy, product, twilio, tech, building, product manager, customer, setting, skills, api, problem, team, sms, technical background, realized, developers, catered, cloud services, pms, engineer
Intro 00:03
Welcome to Product voices, a podcast where we share valuable insights and useful resources. To help us all be great in product management. Visit the show's website to access the resources discussed on the show, find more information on our fabulous guests or to submit your product management question to be answered in our special q&a episodes. That's all at product voices.com. And be sure to subscribe to the podcast on your favorite platform. Now, here's our host, JJ Rorie, CEO of great product management.
JJ 00:36
Hello, Welcome to Product voices. Today's topic is one that I've struggled with over the years, does a product manager need to be technical or what level of technical expertise or acumen does a product manager need? I may come from a bit of a biased position here because I personally do not have a technical background. I'm not an engineer. I'm not a computer scientist by education or by experience. I've always approached the pm role from the quote unquote business side of things. And so while product managers should first and foremost be experts on the market and the customer problem, it's no secret that some level of understanding of the solution is very important. But what is that level? I personally believe that many organizations still require too heavy a focus on technical acumen for PMS. Some of the best PMS I've worked with had no technical background. But again, in the spirit of leveraging the right knowledge in the right areas. I think there's a balance there. I think PMS need to have some level of technical acumen without necessarily needing to be trained engineers or computer scientists. But that's what we're going to explore on this episode. So I'm really excited about this conversation. My guest is Yan, Lukas Hasselbeck, founder of Nate native tech education. In the past, John Lucas was head of consumer IoT at Vodafone, and Director of Product Development at Metro ag Yan. Lucas, thank you so much for joining me.
Jan Lukas 02:06
Thanks for having me.
JJ 02:07
So let's start the conversationwith a little bit of foundation, what is the difference in your opinion between skills and literacy? Yeah, well, it was not me inventing these these terms of Islam. We kind of would need we needed to differentiate here because we talk a lot of to deciders and decision makers. And a skill in our definition is something that you get hired for data scientists, they developers to someone who has a skill. Now, who does something skillfully, by definition, that's a skill, and you get you get hired for that. Literacy. On the other hand side is something that I have to admit we stole it from from McKinsey. So McKinsey released a future skill report recently, I guess it was one and a half years ago, we can put it in the in the show notes. And McKenzie defines future skills in a guess it's 12 or 13 different areas, and they define 56 skills. And a lot of the skills in the digital are in the digital side of things. And a lot of these digital skills are on literacy for computers, literacy for it, literacy for computational thinking, now, so literacy is is can be transferred into he or she can take decisions, act on information,
Jan Lukas 03:33
you know, be a little bit more more informed about what he or she is doing on a daily basis. So that's how we differentiate between the skill and literacy. This, it's necessary because it's we know, we talked about upskilling so much, but upskilling is something where I say, Well, you leave the training or you leave the event with something you can do better than before. And I say well, that's not exactly what we should be aiming for. It's more literacy because it improves your decision making it improves your ability to excel in your job. I think that's a really important distinction. And and this in my, in my mind really solidifies you know the difference or maybe even that balance. I called it a balance. I don't know if that's the correct term. But you know, the difference between having the skills which may not be needed, at least to you know, the furthest extent but literacy a pm having a literacy around certain areas is really important. So, I think that's a amazing,
JJ 04:36
amazing distinction there. And I think that's going to help a lot of people kind of in their minds think about this a little differently.
JJ 04:44
So I want to I want to move on and still kind of foundational question or setting the stage here.
JJ 04:50
Before we even talk about what level of skills or literacy a product manager may need. Tell me your your your thinking around
JJ 05:00
Why a product manager needs some level of tech skills and literacy in the first place? Like what? Why is that something that a product manager should probably have? Yeah,
Jan Lukas 05:11
I think it's helpful or necessary for this interaction to detach yourself from, let's say, the perfect surroundings of a Silicon Valley Tech company. Because they have the most amazing engineers, they have the most amazing CTOs and tech personas in there. So these personas actually make sure that the environment you are in just you know, works know, they make sure that processes, cloud services, everything is aligned to work and to deliver basically your product in the end of the day. Well, that's not the same for a lot of people around the globe, working in mid sized, even large size companies delivering maybe the first web app, the first ecosystem for a specific shop, they are building for specific for any kind of company. And that's reality, for a lot of people, they work on something of digital product or service. But the company they are in is not digital. First. It's not been there. They've been around for ages, but not in the digital world maybe. And for these people, for this project managers or product managers,
Jan Lukas 06:15
more often than not, they work with maybe external companies, agencies, you know, delivery, development agencies responsible for 234 developers, small team, maybe a little bit of cloud instance. And
Jan Lukas 06:31
well, who's responsible for quality in that ecosystem? Is it the product manager? Probably not. But also it's the agencies here, but only to defer it to a certain extent. And it doesn't matter if you work with an external agency or small product team or small engineering team internally, being cutting edge being aware of, of what quality means in software? Is nothing I would say, I would say that is state of the art everywhere. Yeah. So when I say why is it necessary to have at least a specific level of tech knowledge to literacy? And one reason for that is definitely being able to challenge the people you're working with being able to deliver the best quality and software, you can you know, if you have an amazing engineer, lead engineer to own that role, perfect. But more often than not from experience, I can tell that that's that's not always the case.
JJ 07:26
Yeah, I love that perspective. And so, you know, I mentioned earlier, that I am not an engineer, and computer scientists don't have that technical background. And I remember the first time that I worked on a somewhat technical product, a data type product, and I felt very inadequate. I felt, you know, quite under educated, if you will, and realize that, you know, I didn't necessarily need the skills, the level of skills that my engineering partners had, but I did need to communicate with him well, and so that that stands out to me in my past about, you know, kind of the first time I realized that, you know, I may not need to be an engineer, but I need to have some sort of literacy to to use that term. I'm curious, you know, going through your career, was there a time when you realized that, hey, you know, you might not have the technical skills or again, felt under educated
Jan Lukas 08:27
multiple times, I think, I think we've all been there. Question is what you do with it. Now, if you are very well connected, you usually have someone in your broader team or in your, your network where you can reach out to to get, let's say, certain direction, or answers to certain very pressing questions. But if it comes to the day to day things, like, you know, what is technical depth, my team just told me we have technical debt, what do you do with it? And it's frightening if you heard the for the first time. Yeah.
Jan Lukas 08:57
You know, build versus buy decisions. We had that with Vodafone. We're building first consumer IoT platform back then.
Jan Lukas 09:05
Well, how do you take those decisions? How do you evaluate if that Service Provider A performs better than service provider? B? What do you challenge them on? Yeah.
Jan Lukas 09:15
I remember when when I went into the venture builder, Hospitality Digital that Metro funded, we've been no scaling, like how setting up more and more products, you know, going into clouds heavily using a lot of engineers from different from different external service providers. And I realized, well, you know, how do I manage that complexity as a as a Pio or PM? Do they really be? Are they really completely honest with me?
Jan Lukas 09:48
And it came to the point where were some it was kind of an aha moment to me. I do remember that we changed 111 provided for the other and then I got asked so
Jan Lukas 10:00
What's the test coverage on your on your product? I was like, Well, I don't know. 100% which was obviously not it wasn't like around 25%, which is a disaster. It's a joke. Yeah.
Jan Lukas 10:13
And test coverage, by by definition, there is no right or wrong, you know, it should definitely be above 80%. But you know, there is no 79 is not really worse than 81%. But 25 is definitely definitely wrong. So I realized, well, I'm not in the position to challenge these providers, I'm, I'm, I maybe should not be in the position. But if you don't have the right CTO, or tech lead, you know, to step in for you, well, then it definitely helps to ask the right questions, then it definitely, you know, helps to have an understanding for your, you know, your tech team saying, you know, Lucas, we have technical depth, can we push for, you know, solving some of that the next couple of Sprint's, and not saying, Well, you can't, because we need to deliver feature after feature now, no, you know, have an understanding technical depth is gonna kill you in 12 months time. If you don't, you know, really make sure to cater for it, sprint by sprint. So, you know, I realized that multiple times was different different situations, different issues I had, but
Jan Lukas 11:11
I would say underneath it all, very clearly, I wasn't prepared for the jobs that I was in.
JJ 11:18
Wow, interesting. But you've succeeded, and you've gotten through those times. So were there specific things that you did to bridge that gap? You did mention kind of, you know, finding some folks in your network. But you know, were there some things, were there some other things that you did to kind of bridge that gap of education or knowledge? Yeah. Important to understand. When I was, in my late 20s, I realized something I thought, I'd like to get into digital into software more, but I don't get it. What do you do? There's not much you can do a best case you have a maybe a bachelor's degree and business and then you go into maybe computer science. This is what you know, you do at Harvard, you have CS 50, if you've never seen it, look at it, participate in, it's amazing what they offer for free on YouTube, and the way that that they are delivering CEUs 50s is just just amazing. If you have time and capacity, definitely I would go for that. Back then I didn't know if 650. So I went into computer science courses at my local university.
Jan Lukas 12:27
Problem is that doesn't do the trick. If you've ever been to computer science courses, but you start early on with, like, how does computer system work? How does the Internet work all of these things? It's good to know, but it doesn't solve your problem at hand. You know, how do I work with developers, it's more like religious, what they tell you at university, the absolute bits and pieces of how software or the internet works. So that was my first let's say, contact point that I had. I followed up with, you know, stuff you can get your hands on on the internet. But then again, that's all cater to skills. That's all catered to developers, you know, building a skill on a certain framework or certain language they learn. It's not catered to the business person who like just like to understand the environment, ment of computer science better.
Jan Lukas 13:18
I tried executive education with the MIT later on. I don't want to say that it's the wrong the wrong direction to take. But it clearly is more catered to visionary, more entertainment. It doesn't again, it doesn't solve the question of how do I do my job any better. So I would say in the world we are in if you have a lot of time, you're very young, I would say going to computer science boot camps, you know, coding boot camps in your, your local community, or your city you are in, there are amazing offerings here. But that requires time these boot camps usually take three months, it's full time or a lot of time at least. And but they will teach you how to use get up what developers are doing in their free time. Basically, the moment they don't talk to you and actually work.
Jan Lukas 14:07
They explain to you what a framework is, you know what it means to deploy something to production, what testing is so these things, you know, if you have time do that, but that's definitely not the solution for everyone I put myself can say, for me, the what helped me the most is getting a building close relationships to to tech leaders. So there's a couple of them in my network that I interact with on a regular basis. I tend to get down to really problems that I've seen or complex and elements of my day to day that I'm discussing with them that I've tried to understand, Okay, what's the best solution for this that you know, a tech team could build just conceptually basically, and if you do this over time, you know, you become better with that and after a while, you will realize that problems are repeating themselves that there is you know, every system has been built in this world you know, toward them.
Jan Lukas 15:00
What ecommerce systems are repeating these days why that's why companies like like Shopify are so, so important and so successful. So, you know, problems are repeating, if you've understood the problem once or twice, if it's pretty clear that these problems are repeating and coming back to you, and next time, you'll be able to at least, you know, direct your team to the next best solution. I would say, That's great advice. And I have to think that, you know, you founding Nate was probably, you know, a product of these gaps, right, trying to fill these gaps. Yeah, yeah, it was. I mean, eventually, when we when I started off with Nate, it was exactly that. I felt undereducated still, even though I was running multiple teams and love couple of POS working in my team and different tech teams.
Jan Lukas 15:49
From the outside, people probably think, okay, yeah, Lucas really gets it. But you know, I still felt well, I'm not there yet. And there's a couple of things that I'd like to, you know, understand better. Um, so I said to my team, well, let's get techie and let's get a tech lead in someone who's who's was comes with a lot of empathy. I've reached out to a couple of them, and said, well, with my team, we'd like to understand these five topics any better. Yeah, testing, cloud services, a couple of these things where I said, we can be better in we did a lot of failures, we had technical debt, you know, we were not performing well. Or I could see that there was the same problems for the four different teams popping up. So I said, let's, let's sit down and let's get educated on how do you do that right from the beginning from the get go kind of Yep. And we got someone like that into room said, everyone in the room. And it was very hands on workshop. That was, I think two years back and kind of the two to three years back, kind of the first time where I felt this is what it should be like. It's kind of a more masterclass approach, a techie, who is a master in something, sharing his wisdom, so to say, with an audience who's not tech and helps them the next time they stand in front of a problem, you know, to solve their problem more efficiently. Now. So it's, this is very much you know, what it comes down to when we say literacy.
Jan Lukas 17:10
Being able to solve a problem, being able to communicate, communicate clearly with a tech team. And this is exactly what what that workshop enabled us as a team back then. And that can was the foundation for Nate.
JJ 17:24
That's great. I love it, I can definitely see it filling a need in the market. So I want to get specific here. When you think about what areas of tech literacy a product manager needs, where are those areas? So we've got people out there listening, who are now excited, they're thinking, okay, yeah, look, this is absolutely right. I've got to improve myself in certain areas. How do they get started? Like, what are some of the, you know, levels? Or areas? Where a product manager should focus? Where do they need to have knowledge in today's product management world?
Jan Lukas 18:01
Yep. It depends a little bit. If you're taking over product, which is already super mature, I think then it's, then there are different topics are relevant than you know, setting up a product from scratch, I would say in general, you should have an understanding of the tech stack your your product is using what's front end, what's back end stack, have an understanding of the current state of the architecture, where or maybe legacy pieces within the architecture that always will create issues. And maybe these issues are not not transparent to you in in the day to day delivery mode, because they don't create books, but they might create issues for the call centers, because they get called it Yeah, so it's super relevant to understand the bigger picture. Yeah. Now. So tech stack, definitely, architecture is something you should get an understanding of API's your product is using, because there's usually a lot of room for improvement there. So what kind of partner API's third party service you are you're using that usually relates or translates into cost a lot. Now, it's usually a business case question, can you improve the current setting?
Jan Lukas 19:11
And then on the other hand side, also the way you are delivering so what's your delivery model? Are you working in a DevOps setup? What does that mean? What kind of roles you currently have in your team? Is that already already a perfect setup? And there's usually room for improvement in that as well. On top of that, the team usually uses a certain testing frameworks or software testing is something you should have a base understanding of. And I would say last but not least, cloud cloud services is something no one can neglect today, because time over time, I've seen teams building features. Authentication is a good example. You know, Pub Sub service, there's a lot of services a cloud provider offers out of the box that you can easily implement and use
Jan Lukas 20:00
within, you know, just a couple of days maybe, and don't build yourself. So this by was Bucha decision. So cloud services definitely make sure. And then something, which is not really a tech related element but helps a lot when setting up a product for success is non functional requirements. Yeah. So scalability and availability, these kind of things are more often than not, I've seen teams defining that on the tech side, but you know, something like availability should be done from the customer's perspective perspective. So pm should have a clear ambition towards what does that mean, to have a product available 24/7, it usually means a lot of costs, been online all day all time, is a lot of, you know, definitely includes a lot of costs, a lot of effort by the team. But does is that really necessary. If you're building an application for a local newspaper, it might be completely acceptable to be offline, every Monday morning at two o'clock, for an hour to do a deployment definitely might not lead to users leaving because you know, your users are, you know, not up at one o'clock in the morning. That just just an example. Yeah. So it's a mixture of requirements, tech understanding. And it's usually means setting things up for success, where PMS more often than not, do not have a clear ambition towards I love how you've tied that back to the customer, and how it impacts the customer. And you know, the problems that that a customer can have from various technical issues or technical decisions. Because I think for product managers who don't have a technical background, they tend to get intimidated by the the fact that they don't have this knowledge. But if we tie it back, and we understand that we're learning it
Jan Lukas 21:54
from the perspective of how it can help our customers, because that's our job, right is to solve customer problems and make their experiences as great as possible. So I think that's a really important way to, to identify that there are certain elements that you're responsible for. And we'll get to that in a second, I'm pretty sure. But you know, customers want to understanding of your customer and make sure that your customer receives the highest value from your from your product. How do you get to that is, you know, building better features or building features faster. That's that's one thing for sure.
Jan Lukas 22:28
But you know, you can translate that into finding better solutions as well. Give you one simple example. And that example taps into multiple perspectives, the developers perspective, the cost perspective and the customer perspective.
Jan Lukas 22:42
Take the example of Twilio, Twilio, everyone knows it mazing company for four communication services. Back in the days, very early on, Twilio just replaced your message your your SMS server you integrated with simple setting up confirmation SMS to not miss, you know, let's say your doctor's appointment. Well, today Twilio does more than that they offer automation services. So as a PIO, Mia, I, my idea is maybe to interact with a customer for his doctor's appointment more actively, you know, let's say the user should be able to cancel the appointment with an SMS to reschedule the appointment, things like that. Back in the day, you could basically set up an epic, saying, you know, customer interaction on SMS, that epic would take maybe a month to evaluate, you know, creating multiple stories out of that and then implemented in the backend. Well, if you are an informed PM, you go into Twilio. You log in, you create a test account and you start playing around with their with their API. You realize after why it worked? Well you just launched a service called Twilio studio. And I'm not an Twilio employee, I don't receive any, any any kickbacks from Twilio. But it's just an amazing service. Yeah, we just recently launched a product called Twilio studio, which is a graphical interface. It's a canvas to build communication or
Jan Lukas 24:01
process or process communication and interaction. So you basically everything that I just explained step by step can be built in Twilio. Yeah, first first trigger is coming from the backend, then it's a confirmation SMS customer can answer to that SMS, you can pick it up again saying I want to schedule or reschedule, I want to cancel. And that
Jan Lukas 24:21
two years back, you would have need to build that in the backend. Now you can build that all into your studio and just connect the one endpoint to your back end saying that's the trigger to start that communication for everything else works into not What did you just do? You save development time, which equals cost. You saved your your lead developer time to look into the documentation come up with that solution himself or herself sorry. And you just build an amazing in SMS interaction for your customer, which makes the rescheduling with a doctor way easier. No need to call in just you know, send a simple one or two whatever the logic is to the Twilio backend.
Jan Lukas 25:00
and set things up for success. So you just solved a massive, let's say problem or just solve that epic all by yourself with simply some exploration of an API, and some trial and error on the on the Twilio studio Canvas. So when I say technical literacy, it all comes down to, you know, setting up for success, but also ongoingly, being able to make sure that you get the highest level of quality for delivery, for customer satisfaction, but also for your team's satisfaction, because that's just another epic that didn't need to implement. I love that example. Such a good one in terms of, again, how it, how it impacts the business, how it impacts the customer. I love that, that's great. I think you should get a kickback from that. That was
Jan Lukas 25:49
I'm gonna I'm gonna I'm gonna ask next time we talk or speak to them? Definitely. But it's you see, you see, it's so it seems so, so shallow, the first time you think and talk about tech literacy, or what's the ambition of a pm in that regard. And then you start looking into that. And I'm not saying you need to understand every API that's out there. But twill you and there are others that you work in your product with on a daily basis. I'm pretty sure everyone does. These API's become more powerful on a on a on a yearly basis. And the more the deeper your understanding of the capabilities are, you know, the more straightforward you can basically say, my epic doesn't is not called SMS interaction. My Epic is super simple one because I already halfway understood what we need to build saves time to everyone. And I think that's pretty much really nailing what tech literacy is all about. Yeah, absolutely. So how do we how do we break it down? How do we break down technical literacy for product managers and really kind of, you know, attempt to to tackle this this issue, if you will? Yep. I think the Twilio example, just already made a good case. But But let me maybe bridge the gap of the cognitive gap here for for everyone who's listening. Because I was asking myself the very same questions. What's the like, when I started into product, I kind of, you know, asked myself, What are the determining skills or abilities that I should have? Because still, companies don't know what they're looking for when they're scouting for PMS. If you look in different profiles that are out there for senior POS, or head of product, whatever, the expectation level of different companies is super different. Yeah. So you know, as a as a employee, or someone who's was trying to get the next to the next level, the next job, it's super unclear what you should be building yourself out for him, what you should be preparing yourself for. So what helped me a lot is something that I learned in reforge. So Robbie, mentor, former CTO of Tinder, and I think, senior senior manager at TripAdvisor, he invented something called the product manager competency matrix. It has four major dimensions and 12 second level dimensions or categories to look out for as a product manager. And one of the four major dimensions is product quality. And product quality, again, can be broken down into into product execution. It's more like product execution and product execution can be broken down into quality assurance, product delivery, and feature specification. Now, if you I'm pretty sure if you ask 10:10pm Today, the only thing that they would come up with is its future specification, yeah, because that's their day to day job. But product delivery and quality assurance are equally relevant. And that can kind of be converted into tech literacy helps a lot in to improve on product delivery and quality assurance. You can leave that to your engineering team, you can leave that with your developers pretty sure you can, but you know, I think I gave good arguments of why not to because as a product owner, you have to own the customer, the strategy, the people management, but also the product execution and product execution does not just mean features now and I think everyone is pretty clear that you know delivering features gets less and less relevant after certain while because the product might be more or less where it should be. But then execution means more than that, it definitely means you know, your product gets delivered fast, with no errors and in a good quality because that again is experienced by your customers and you know increases their satisfaction again. So if if we break down if we break down what it means to become a good PM, that matrix will help you a lot. It will also help you a lot in understanding your responsibilities along these lines. And
Jan Lukas 29:52
it helped me at least to focus on certain upskilling programs that I wanted to do and yeah, Tech was technology was one of those
JJ 30:00
That's great. And we will link to that competency matrix that you mentioned, as well as some other great resources that you've provided. So those will be in the show notes and also on product voices.com. Yan Lucas Hasselbeck, thank you so much for this conversation. It's been very enlightening. And I certainly have connected some dots in my own mind. And I think that's one of the wonderful things about these conversations is, is learning something new and connecting some dots along the way, and I think that the audience has, has gained a lot of insights from you. So thank you so much for joining us on product voices. Thank you. And thank you all for joining us on product voices. Hope to see you on the next episode.
Outro 30:44
Thank you for listening to product voices hosted by JJ Rorie. To find more information on our guests resources discussed during the episode or to submit a question for our q&a episodes, visit the show's website product voices.com And be sure to subscribe to the podcast on your favorite platform.
Resources
Connect with Jan Lukas
Ask a Question