How to improve your technical skills as a product manager or startup founder

Introduction

I often get asked by product managers how to improve their technical knowledge. I have a strong technical background, and they see me use those skills in my day to day work. Having a good technical background makes life easier when collaborating with Engineers being able to empathise with their challenges, and sense check their ideas. It enables you to better understand the complexity of different projects without going to engineers, so speeding up feedback and decision making processes. It allows you to have more constructive conversations about trade offs between tech debt and feature development. The benefits are many, and if you’re working in tech, building your understanding of how software is built will greatly improve your skills managing technical teams and projects.

My route to understanding software engineering came through teaching myself to code as a teenager, and then after university working as a software engineer. Since then I’ve kept topping up my skills. The good news is though that as with many things, you can get 90% of the benefit without spending years deep in the detail. Here I share my insights about how to do that.

The idea of this article is not to give you very specific recommendations of exactly what to look at, but to take you through the thought process of what you should invest your limited time learning and give you some good ideas of how to get started. Read this, decide how to prioritise your time and then the rest should be easy to find with Google.

You’ll learn that it might not be the best use of your time to actually learn to code, and maybe you should focus on more high level architectural topics. If you do learn to code, then you might want to focus on areas like data analysis that will be useful in your day to day work.

Why technical skills are valuable and how to approach learning

How technical skills can improve you as a product manager, and which skills to focus on

There’s an endless amount we could learn, way too much even for engineers to learn, hence you get a high level of specialisation in software engineers. So to better prioritise your learning, think about what you want to get out of it, and be realistic. Programming is far from as scary as some might make it out to be, but it can take weeks to learn if you’re not 100% focused on it, and be a bit frustrating along the way.

So think about what you want to get out of it, and so what kind of programming (if any) you actually want to learn.

If you’re focused on web development and you want to understand the conversations by your team, then maybe it would make sense to learn how to build a website, but equally you might be able to just google a lot of things and gain a broad understanding without having to go through all the learning steps.

The most useful day-to-day skill to improve is data analysis

To me, the most useful day-to-day skills for a Product Manager is to improve your data analysis toolkit. This helps you develop more sophisticated business models, get deeper insights from product usage data and get you access to data on your business or competition that others don’t have.

Even if you don’t use some of the more sophisticated techniques long term, the process of learning them will help you be better at more basic analysis.

First step is SQL for querying databases, which is probably a bit closer to excel formulas than most programming, and you can pick up the basics fairly quickly. Many companies will have BI dashboarding tools where you can easily turn SQL queries into dashboards with tables and charts.

If you want to get more advanced, you can learn some python and use Jupyter to mix code and results.

Programming teaches humility

Sometimes it can be hard to understand why an engineer gets stuck on a problem for ages, or why timelines can be a bit unpredictable.

There is nothing more humbling than learning to code. You will very quickly learn that all humans are very poor at doing this reliably and accurately, it just tends to be that the rest of our lives are set up to be accommodating to our failures, but when writing code, even the small things matter a lot. It matters if words is capitalised or not, or what type of brackets you use (programmers love brackets).

This hard lesson in your imperfection can make programming frustrating. Expect sometime to spend hours trying to work out why something is erroring seemingly for no reason at all, only to find out it was a small slip up. The benefit of this is you will have a lot greater appreciation of the challenges engineers face.

On the more positive side, coding can be extremely satisfying. You get to create things, and the process of creation is a fun academic exercise.

Learning software engineering is different to learning some basic coding

One hesitation I have in recommending spending too much time doing actual coding is that you can spend quite a long time working out how to develop the basic code. This will teach you a lot, and give you a platform to develop your skills from, but it’s actually not what engineers spend most of their time thinking about, or even where you are likely best placed to collaborate with the engineers.

If you write a few hundred lines of code for a quick project, or even a few thousand, you’ll miss a lot of what actually makes software engineering hard and what more experienced software engineers spend their time really thinking about. Software engineers are more interested in how you can structure code and work with different libraries and services. They’re concerned not just about how to implement a feature that looks right, but how to architect the code such that it can be worked on by multiple people, maintained over time, runs efficiently and can scale to large numbers of users.

The good points of collaboration between Product Managers and Engineers tends to be more on the level of architectural decisions where there are tough trade offs to be made. If you take a certain direction, maybe it will be quicker to implement, but then harder to add features to later if you change direction. Another option might be easier to implement, but become very costly to run if you scale to 10x the traffic. Those areas are where a Product Manager can bring their wider business context into the discussion.

Does a product manager ever do coding?

Mostly the answer is no, however, increasingly I see Product Managers, especially in startups, who find it a good use of their time to write some actual code. We’re not talking production ready code deployed through a CI/CD pipeline and then used by millions of users, it’s often more hacky than that.

For instance:

Using some basic coding to set up a chatbot for an MVP.
Doing data analysis that you can’t do easily with spreadsheets.
Doing high level test automation (integration testing), simulating a real user.
Configuring low code tools.
Making a crude mock-up of changes to a website by editing its front end code.

Even if a Product Manager has the skills to do development work, and even if there’s a really good reason why they should do it to help out, it’s a very different style of working that can be hard to switch in and out of. As a Product Manager, you spend a lot of time context switching, jumping between meetings and slack messages, responding to what comes up not just what you planned to focus on. Software engineering requires a lot of deep focus to do well. What that means is that the type of coding that a Product Manager can do necessarily needs to be more like shallow automation or data analysis rather than getting involved in a more complex project.

My personal experiences

How I got started

I got started programming as a teenager at school. I didn’t have any formal education, I just had a project that I wanted to build (around sharing music), and decided to do it. I bought a book, and the book told me all I needed. Having a project kept me motivated and it was a great way to pass boring moments during lessons.

The main takeaway is that there’s nothing that complex.

How I have used my technical skills as a Product Manager

Some real world examples of how I have used these skills while in a Product role:

Involved myself in technical architecture discussions, identifying mis-matches between what the engineers are planning on building, and what the long term business requirements are likely to be, hence saving multi-month changes further down the line. No detailed coding knowledge needed.
Better understood the technical constraints behind projects to propose alternative / better solutions that are actually practical to build.
Used front end web skills to spot more issues, and to suggest improvements to designs by mocking them up as modifications of existing webpages - often just simple things like changing colours or spacing between elements.
Used SQL to build dashboards of product performance without having to go through analysts or engineers.
Use python to perform complex data analysis, especially using large or poorly structured data sets (and without being blocked waiting for BI / Data Science person’s help).
Coded automated integration tests to find common or high consequence issues automatically, and to show to engineers that they should really build these tools themselves and I shouldn’t be finding them.
Looked at key algorithms (often short pieces of maths / logic) in the code to check them or suggest modifications. I normally get an engineer to find the relevant code for me.
When blocked by engineering for a feature I really care about, I have found solutions.
Worked as an engineering manager / tech lead, when we’ve been short of really strong staff. This has been guiding engineers, and discussing at the architecture level, but not actually coding.
Used my knowledge of the logs and architecture to identify reasons for downtime, and so help engineers get the system back up more quickly.

I find these skills useful, and try to top them up every now and then. However, the vast majority of the time they’re giving me extra context to what’s going on, and for sure I’m not trying to take work away from engineers. If you’re doing PRs, or committing to Github in your day job, you’ve probably gone too far.

Like with all Product Management, you’re short on time with a hundred things you could be doing, and you want to use these skills at the most critical moments. Like when progress is blocked, you’re having big issues with reliability, or wanting to understand if you should work on tech debt or new features for the next quarter.

How I have refreshed my technical skills

I have a lot of experience with software development both as an engineer and working in product. Software development changes over time, and I try to occasionally take some steps to refresh my knowledge to keep up with what the engineers are talking about.

Most of the time it’s just about staying curious and looking up things that I don’t understand.

Some specific steps I have taken include:

Learning some web development using NextJS.
Kept reasonably up to date with tools on AWS.
Done a work hackathon in GoLang building (part of) a blockchain.
Every now and then over-engineer some analysis using python, pandas and jupyter.

How to learn programming

How to learn programming - books, articles, videos etc

Writing software isn’t trivial, but there are some really great resources out there to get you started, and generally these are totally free. If a project doesn’t come with great documentation then it tends not to get adopted widely by software engineers.

You should be able to find:

Videos on youtube
More in-depth courses on platforms like Udemy
Tutorial articles on the project’s website, and through googling
Books
In depth documentation (e.g. API documentation) on the project’s site.

What’s best? Well, largely up to you. A full book’s probably a bit too many pages to commit to just yet, so as first steps, I’d find a short tutorial or youtube videos.

You can also look for communities of people. Some projects have their own Discord servers, or forums. More commonly there’s a lot of content on StackOverflow and other forums for problem solving.

Even the greatest programmers spend their lives on Google searching for solutions to problems.

Find a project to stay motivated

The best way to learn to code is to have a project. Something that you want to build. It can be silly, or it can be practical and work related. After learning some of the very basics, you can start to focus on solving your actual problem, and by trying to do that (with a lot of googling), you will learn more and more skills. As you work on it, you will see your progress and the value of the work you’re doing and keep motivated.

Different areas you could learn about

Learn databases and SQL

Generally when working at any kind of scale we store data in databases. Whether that’s the list of articles on your site, or details about what customers have been doing.

SQL / relational databases are the classic databases. Essentially you store data in multiple tables (think spreadsheets) and you can filter that data and combine it using SQL. Learning this is what I would focus on over NoSQL databases. SQL as a means of querying data is decades old and has really stood the test of time, and can be used (with fairly minor adjustments) across a wide range of databases.

You can even use SQL to query data within Google Sheet.

If your company uses a dashboarding tool like PowerBI, Tableau, Sisense, Looker or Quicksight, then you can quickly turn queries into dashboards with charts that everyone in the business can look at.

At least 90% of the queries that you are likely to perform are actually fairly simple ones. Once you understand the basics of how data is stored, joined, filtered and aggregated you’ll basically have all you need, and anything else you can search for as those special cases come up.

Of all the skills, I mention here, SQL is probably the easiest and the one that will keep paying back over the longest time horizon.

Here’s some terms that you should try to learn:

Select
Like
Join
Distinct
Group by
Sum, average etc
Subqueries
Index
Primary key

More advanced you can get into things like Window functions for things like rolling averages.

There’s lots of databases you can use to get started with, but SQLite is nice in that you can just have it as a file on your computer, rather than having to set up a server like PostgreSQL or MySQL.

A small word of caution is that you probably don’t want to learn on your company’s critical database as there’s a risk of making very slow queries that then has unintended consequences. At least quickly chat to your data person before using any company databases.

Learn some python and data analysis

Python is my favourite language, and it’s also the favourite language of most data scientists. Why? Because it’s pretty easy to read and understand and it’s got some amazing high level libraries that allow you to do really powerful things with ease. You really can do anything with python.

It falls down a bit as a language when you have large code bases or you want high performance, but that’s not a risk here, and there’s ways around some of these challenges if you do ever face them.

The kind of thing that it really excels at is doing some hacky data analysis that doesn’t really work with a spreadsheet. If you have a million rows of data, it won’t break a sweat. You can load data directly from spreadsheets (CSVs), databases, APIs etc. You can really easily plot the results too, and with a bit of work even publish interactive dashboards for the rest of the team to play with.

So it’s also great when you have some data in a database, and some in a csv and you want to mix them together. It’s also great when you want to do more complex processing of data in a database and SQL starts becoming messy.

As someone with a software engineering background, I’m actually amazed so many people use spreadsheets for anything more than a basic plot because they become so difficult to understand, maintain and know are working correctly and yet are often used for business critical tasks. Having said that, for small tasks, often spreadsheets are a lot faster to work with.

So learning python will teach you some long term programming skills, and some great data analysis skills.

To get started, I would look up Jupyter notebooks. This is a different way of programming to most applications, but it’s great for learning and working with data. In short you mix the code with the output in a document, and execute the code in small steps. While most programming you output very crude text to the console, with jupyter you can actually output charts and tables as well with tools like plotly and pandas.

You can run jupyter (or Jupyter Lab is better) on your computer, and if so I’d recommend installing through Anaconda.

An alternative to using Jupyter on your laptop is to use a hosted service. Google Colab (which has a free tier) or Amazon Sagemaker for instance.

Google for introductory python tutorials, but as you get more into the data analysis parts, look up:

Numpy - for handling numbers in arrays or matrices (which you can then plot)
Plotly graphing library - for plotting
Pandas - for richer data analysis, advanced level.

Pandas I wouldn’t recommend too early on as while it simplifies a lot of tasks, in particular treating tables of data like you would in a database, it essentially is it’s own language and has lots of weird quirks.

Build a basic website in javascript

Websites make great starter projects as you can make something fairly quickly that’s very visual. It’s great core skills to learn the basics of how websites work. You can also learn here very incrementally, and even a small appreciation of how they work will help you out long term.

The slight challenge with web development is that there’s now so many different frameworks and languages that while each one of them might not be too complicated, working out which one to learn can be a bit complicated.

Broadly we have:

HTML for the main parts of the pages
CSS for styling pages
Javascript, and Typescript for making the front end interactive
Backend server - which can use a number of languages like javascript / node, python, ruby etc.

… and then actually there can be frameworks layered on top of these underlying technologies like React, Vue etc on the frontend or Express, NextJS etc on the backend, and most developers will actually use these frameworks most of the time.

Ok, so how to navigate this mess?

Firstly, learn some basics of HTML and CSS. Ignore the frameworks and the servers. Just learn the basics of creating a static webpage. During this you should also learn about browser dev tools, and you can play with the designs of existing web pages. These skills can be very useful if you want to communicate how you want to improve an existing site, without having to actually do the proper coding effort.

If you then want to add on the backend (server), then I would suggest using Node (javascript / typescript). The most basic would be to use Node + Express.js. In short, go to the Express site for their tutorials.

You might be wondering what Typescript is vs Javascript. They’re pretty similar, but Typescript has static typing which basically means it can help catch careless coding errors more easily. It’s a bit of extra learning curve that will likely pay back quite quickly.

To make more interactive frontends, people use to code in raw javascript. You’ll also find that CSS can do a surprising amount of things nowadays. However, if you really want to go for it, then increasingly React or Vue are being used. React is the most popular, but if your work is using one and not the other, then I’d just go with that one.

Should you do unit tests? No. It’s just going to complicate things for now unnecessarily. Just press the run button and see what goes wrong.

I recently did a bit of web development, having not actually done any since a teenager, and went with Next.JS (React + nodejs backend) + Typescript + Mantine (easier good looking front ends) + bit of CSS + experimented with various CMSs (Strapi, Notion API etc). NextJS had some good tutorials to get started that were pretty easy. However, it probably helped that while my javascript and CSS skills were pretty poor, I knew about a lot of the development concepts in advance (like static site generation).

Skip the programming and learn about software architecture

Often the detail of how the coding works is not particularly useful for a Product Manager to understand. It’s just too low level.

The challenges that we’re often more interested in are things like:

How will data be stored?
How flexible will the system be to change?
How will it respond under load / how fast will it be?
How reliable will it be? What happens if a server fails?
Are there any pre-built services that can save lots of time?

You then have a choice about how to learn about it:

Explore software architecture explicitly.
Explore cloud services, and pick up the architecture along the way.

I have observed Product Managers successfully geeking out on software architecture directly, but I suspect for most people it will feel more tangible if you look at the cloud services.

A lot of classic articles have been written by Martin Fowler, but you’ll also find that a lot of books have been written about it and many are timeless. You might also find some of it discussed as design patterns.

Some terms to get you started include:

Microservices
API
CRUD
NoSQL
ACID
Horizontal scaling
Caching
Database table structure (normalization, denormalization)

Skip the programming and learn about cloud services like AWS

This relates closely to the learning about software architecture as a lot of modern architecture is combining cloud services together to make an overall system. While focusing just on architecture can sometimes feel a bit abstract, many of the cloud services you’ll probably find you recognise and the reasons for using them are a bit clearer.

Cloud platforms are increasingly very sophisticated and provide higher level tools to develop your software on. When you’re just getting going, they provide access to these tools and servers (or fraction of a server) at low cost. As you scale up, they support very high traffic volumes.

A route that I can recommend is to explore a bit within AWS (or Google Cloud, or Azure) to understand what things are on offer, and why they are used. The cloud platforms have a lot going on now and if you look at AWS it has more than 200 products within it and growing. Some will overlap, like there are 10 different databases each with slightly different benefits. It’s all well documented by the cloud companies, and you’ll find even more on the wider internet.

To navigate this, either follow what’s a current problem in your company, or follow your curiosity. The great thing about learning here is you can just do some quick learning when you have a spare moment. There’s no need to have a lot of dedicated focus time.

You will often find there’s multiple options for solving a problem, and just reading through documents on which one to choose will inform you greatly.

Then you will also find that they will suggest architectures for certain problems. For instance https://aws.amazon.com/solutions/implementations/data-lake-solution/ suggests an overall architecture using different cloud components to create a data lake (store of historical data for analysis later).

Some hints about what to look at (pick what interests you):

CDN and caching - how to speed up websites.
Databases - We almost always store data in databases. There’s lots of types from SQL databases like PostgreSQL, to NoSQL key-value stores like DynamoDB, to document search databases like ElasticSearch (for things like search engines for users), data warehousing databases like Redshift and more advanced ones like time series databases.
S3 - how we store files like images. It’s not that exciting, just worth knowing about.
AI and Machine learning - here you might find some cool off the shelf tools that you thought might be complex for things like converting speech into text or translation.
Function as a service, like AWS Lambda - a different way of structuring codebases and running servers so that rather than setting up servers yourself, you just send small bits of code to be run (and scaled automatically).
Containers, like Docker + Kubernetes - it’s a way of running software across servers in a very easy to deploy and scale manner, and can be low cost if you’re not using much resource.

Skip focused learning, just be curious and look up things you don’t understand

If you’re in the situation where people keep on using terms that you don’t understand, don’t think that you need to go through all the years of learning programming to get a good, high level understanding.

The great thing about most software engineering is that while things might be given specific unfamiliar terms, they tend to be based around fairly simple logic underneath them, and you can get a high level understanding.

For instance, a database index is really just like sorting a table (e.g. alphabetically) to make it easier to find records. An AWS Lambda and serverless computing is really just an easy way of running a small-ish bit of code. CI / CD is really just about running some checks on code before deploying on a server, and then just pushing it to the server automatically.

So when there’s a term that you don’t understand, do a quick google search and read wikipedia. Maybe follow up by checking your understanding with an engineer quickly. Sometimes the article might be too complex, or you might not understand why it’s important, and quite possibly the level of detail will have no relevance to you (why use a “decorator” or a “singleton”), in which case don’t worry too much and move on. It’s not about learning everything, it’s about learning more and more incrementally.

Experiment with Github to understand software development workflow and version control without coding

A lot of what gets talked about within teams is things like “branches”, “PRs”, “committing”. These are just terms about using Git version control. In short, code is stored as text files, and they’re stored in a “repository”, which is just a project. Git stores those files and a history of them, but also provides ways for a team to collaborate on a project together as different people might be working on the same files. So it’s not really so technical, and is more about collaboration.

Github is an online platform built on top of Git. Github is extremely widely used. It has a free plan, so you can just get started experimenting with it on your own. There’s lots of open source software being stored on Github, so you can browse what other people have been doing. You might also be able to get access to your company’s repositories (read only) to see what’s really going on in your company.

Even if you are the sole person working on a software project, it makes a lot of sense to use Github as it stops you from losing your work, and because sometimes you make changes that break things and the best thing to do is to go back to a previous version that actually worked.

Overall tip would be not to go too detailed here, you just want to understand the overall flows. For that, some introductory tutorials or videos should suffice along with looking at some existing projects on Github.