The Snippet is a Weekly Product Management Newsletter for aspiring Product Leaders.
How technical should a PM be?
This question elicits passionate responses from across both sides of the table. I get lots of DMs on twitter around this question alone.
Well, there are two schools of thought around this👇
Being too technical actually distracts a PM from what they should really be working on - strategy, Roadmap, competitive Analysis, defining what to build.
Technical skills are superpowers for a PM that helps them do the job better.
But as with most other things around us, the answer to this question is not binary.
There is some truth to the fact that if a Product Manager spends all their time talking and solving technical issues, they'll have little time left to understand the market, talk to customers and figure out what to build.
But that has got nothing to do with whether or not a PM should have technical skills.
Based on my experience building and managing products for over a decade, I strongly believe that Product Managers should in fact prioritize building certain technical skills.
More specifically, PMs should build technical skills
That helps them build products that customers love
Helps them be a solid bridge between Engineers and "Management"
that helps 10x their productivity
that creates professional and personal leverage and builds optionality for their careers
So what are these technical skills?
I've found that picking up some very specific technical skills can give you tremendous leverage both professionally and personally.
Here are the top tech skills that have helped me build better products, improved my productivity as well as helped my career growth tremendously.
#1. Learning to Extract Data
Data is a Product Manager's best friend. You need data to make decisions, analyze competition, understand the market, figure out what to build, run experiments—you name it. I often found myself spending lots of time trying to manually find and build datasets from the internet. But then I learned about automating data extraction techniques such as web scraping.
Scrapers or crawlers are basically snippets of code that can extract any data that you need from any website —and present the data into a CSV or an Excel file.
It's actually pretty simple and you can do this yourself with very little code. And once you have the code- you can reuse it over and over again to get data from many different websites and publicly available sources.
If you don't want to write any code though, you can use a chrome extension like webscraper and let it do the job for you. There may be a small $ to using 3rd party scrapers like web scraper —but it's worth the time you save and several times over.
#2. Learning to A/B Test
Say your product has a landing page with a Marketing copy that reads
“There’s a better way to grow”
Its pretty neat and is driving visitors & engagement on your page —but you’re NOT seeing enough conversions. Visitors to your landing page aren’t signing up for that free trial.
You think —well maybe the value proposition message isn’t clear enough. how about we change header text to deliver the value proposition more clearly? Good thought.
So you change the marketing copy to — “Every marketing tool you need. 2x faster integration”.
Your hypothesis is that if with this clear message - people will quickly get the value proposition - that will drive more signups for your free trial.
Great, but How do you validate this hypothesis?
You got it. A/B testing. A/B testing is the gold standard when it comes to validating assumptions in the Product Manager world.
But here's the problem - its also the most misused validation techniques out there.
There is often lots of confusion and incorrectness when it comes to setting up an A/B test the right way. Worse still, there is even more ignorance around interpreting results — and as a result people often arrive at wrong (or biased) conclusions.
I’ve met PMs who intentionally stay away from A/B tests as it seems to involve complexity and statistical analysis. In other cases when A/B tests are actually conducted here's what I've seen happen
Tests being set up wrong - you change too many variables, or the variations are not randomized, or too many unnecessary variations
Unclear primary metrics/ whats being measured, or too many things are being measured
The sample size is too small and while you may be seeing results that confirm your biases —they are actually due to random chance.
For the landing page example above—you might indeed see more signups with changing the header text — but if your sample size of the A/B test wasn't big enough, it may be just a matter of chance or a single outlier distorting your results.
While it does seem like A/B tests are complicated — let me assure you that you don't have to be a statistician to set up A/ B tests. All you need is a basic understanding of the first principles AND a few readily available tools such as Optimizely.
A/B testing is a technical skill that is pivotal to the Product Manager role and will directly help you make better decisions and build better products
#3. Understand Technology Stacks
I started my journey as Product Manager for hardware control boards that went inside Air Conditioners—loved it - but I always wanted to get into building and managing SaaS products.
I decided to start learning more about how SaaS products are built and the technologies that powered these products (also sometimes known as "Tech Stack"). Over the next few months, I built up a decent understanding of the tech stacks of some of the most ubiquitous SaaS products at the time and this really helped me get my first break into a Software Product Management job.
If you are somebody really interested in breaking into Product Management for Technology Products, apart from the usual PM interview advice, I recommend that you take time to look at what tech stacks your favorite products are built upon and why? It will very quickly set you apart from the crowd when you are interviewing.
If you already a PM, I highly recommend learning about popular Tech stacks as well (again, high level, nothing too deep ). Once you gain an understanding of the same, depending upon your specific use case, customer requirements, scaling needs, and service level expectations you choose the right tech stack for your product or service as well.
You might ask — isn't choosing a tech stack an engineering decision?
Sure it is. But we aren't talking about whose decision it is.
We are talking about whether or not as the PM, you understand the reasons behind an engineering decision —and when something doesn't make sense - whether or not you understand enough to question a decision about your product.
#4. Building Prototypes
I am a huge fan of prototypes. Nothing helps you tell the story better than letting people touch, feel and even use your vision. Prototypes > Powerpoints.
The great thing about being able to prototype ideas yourself is that you don't have to rely on engineers to build them for you. Engineering time is sacred —it's a scarce and expensive resource that's best spent on production code.
Of course, if you know basic coding you can easily spin up prototypes (even live prototypes) but again you don't have to know how to code.
There are several tools such Figma that let non-coders, PMs, designers build quick prototypes. More recently the proliferation of no-code tools has made it much easier to build hi-fidelity prototypes and even full products without writing any code! Check out the Makerpad community if you are interested in No-Code.
#5. Learn How APIs work
Of All the technical things that a Product person can learn — APIs are perhaps the most useful. Odds are that even if you are totally non-technical, you have certainly heard the term "API" being thrown around. This is because the vast majority of the apps that we use today employ the power of APIs to deliver key functionality.
Here's an example.
Say you are creating a SaaS marketplace that lets people find handymen for repairs online. You've built everything, and now all you need is a way to charge people 💰 for your services.
So should you now go ahead build a billing system?
In case you didn't already know, building a billing system from scratch is super complicated. You have to be able to accept different credit cards, take care of taxes, issue refunds, detect and avoid fraudulent transactions, regulatory compliances, etc —again, very complicated.
Thankfully, there are other companies that have invested a lot of time and effort building a Billing system —and they let you use their billing systems!
You can simply integrate your SaaS marketplace with their billing systems via Application Programming Interfaces or APIs.
Similarly, Want to integrate Maps in your product?, use the Google Maps API. Want to embed videos on your page?—use the Youtube API! No matter what you want to build, chances are there is an API for that functionality that somebody has already built. Check if they have an API and save yourself time and resources.
For a Product Manager, learning how APIs work is super useful. It helps speed up your product development time significantly and saves lots of time & dev resources. It helps you have an informed conversation with your software team and engineering stakeholders. If you are validating a feature with a group of test users —you can also use available APIs to create "live prototypes" instead of just mockups to make the validation testing more realistic.
#5. Learn to code (a basic web app)
Finally, What about coding? Should a PM know how to code? This is a question that is much debated.
If you're asking whether or not a PM should be able to sit alongside engineers and pair program with them —the answer is NO. That's not what Product Managers are expected to do. That’s not the job.
A Product Manager's job is NOT to BUILD the product they are managing. Instead, it is to figure out amongst the many things that a company can build — what is it that is really worth building? What is it that will solve customers' burning problems? What is it that customers will pay for?
Now, let us ask a different question.
Should PMs understand the basics of how code works on a high level? Absolutely.
Learning to code —even the basics —has a lot of upsides. If you are interviewing for a PM job, you immediately set yourself apart from the majority of the candidate pool. On the job, the ability to understand & write basic code can be transformational to your productivity, validating and pitching your ideas, and moving work forward when resources are limited.
It helps you understand the painful and laborious process of building something. It helps you become a better decision-maker because you can now fathom roughly what it would take to build what customers are asking for — and whether or not it makes both strategic AND financial sense. Learning to code can create tremendous career optionality and I highly recommend it.
Many people think they need a computer science degree to learn to code. The reality is you don't need to have any degree to learn basic coding. And just the basics will take you a long way. I really think that if I can do it, anybody can do it!
If you want to get started, connect with me on Twitter and I will help you.
Alright, this has been another long post, but it’s such an important topic! Whether you are somebody that wants to break into product management or a seasoned PM that wants to become more productive and make better decisions, or somebody that just wants to be able to test ideas before throwing expensive resources to build them— acquiring technical skills can be super helpful.
These skills will give you superpowers, imparting a deeper understanding of the products that you manage. They’ll enable informed and involved conversations with your engineering counterparts. They’ll impart you with skills needed to help sell your vision & ideas to raise money. These are hard tangible skills that’ll propel your product career to even greater heights.
I hope you enjoyed this post. You can Follow me on twitter where I share learnings on product management, coding & skills for Product Managers.
👋 Thanks for reading!
-Abhi
The Snippet is a Weekly Product Management Newsletter for aspiring Product Leaders.
This post has been published on www.productschool.com communities.