🛳️ How to learn frontend programming as a PM

Just enough to be conversant with an engineer. It's not as hard as it sounds!

In last week’s newsletter issue, I explained why it’s important for you as a PM to have some basic competency in writing code. In this issue, I focus on one particular area of modern software engineering, namely frontend programming. Most professional software engineers have at least some baseline skills in frontend programming. Specialists in this this type of programming are called frontend developers.

Web apps

In recent decades, the web has become the predominant place where people consume information, communicate with each other, and do business on a day to day basis. Even if you work inside a company where your digital business tools are isolated away from the public internet, they are nonetheless typically still “web apps”, in the sense that that they work inside your web browser, served from a private intranet. Consider your typical work day. How often are you using a desktop app on your computer, versus doing work inside of a browser tab? Even traditional desktop apps like email, word processing, and spreadsheets, have versions that work inside a browser nowadays.

So as a PM, it’s very likely that the digital products you ship in your career will often have a web component, if not totally created in a web context. In other words, the majority of digital-enabled business value delivered today in the world economy is via the web. As traditionally non-tech industries like healthcare, finance, manufacturing, and retail increasingly become digital-enabled in the coming decades, they will require software solutions, and a lot of these will be delivered on the web as a platform. There are of course other technology platforms such as hardware and emerging ones like IoT (internet of things). But these sectors are not growing as fast. So especially if you are a non-technical PM by training, it’s wise to at least get some basic understanding of web technologies, as a way to future-proof your career.

What about mobile?

It’s true that mobile has emerged as the dominant technology platform for consumers in the past decade. So there are indeed many PM jobs that require some knowledge of mobile technologies and how to create mobile apps. But if you are not working on a mobile product now, and don’t have an explicit career goal to do so, I would focus on web first. The mobile market will continue to grow, which includes both smartphones and tablets. But the market for enterprise apps, i.e. tools that you use inside a company, is unlikely to deviate away from web significantly in the coming years. And it will actually grow. In other words, there is a growing market of web apps to help business users sitting in front of their computer, do their work. With trends like automation, knowledge work is only increasing. So at least for the next decade, more folks will end up using business tools on a desktop computer, and these will be web apps.

More interestingly, there is a growing trend to build mobile apps using web technologies. This is precipitated by companies wanting to ship mobile apps with developers who already have frontend skills, as well as broader technology architecture reasons. In sum, just as a frontend developer often already has a head start in building mobile apps, as a PM who knows frontend programming, you’ll have a head start in knowing about mobile technologies. So prefer learning frontend programming first, all other considerations being equal.


In the early days of the internet and the web (or the “World Wide Web”), computers would send each other simple text. These early pioneers wanted a way to provide more richness beyond raw text; for example, to indicate paragraphs or headings in a document. A browser would display this text in a web page. Importantly, folks wanted a way to link web pages with each other. (This is something you probably take for granted nowadays, such as when you get sucked down a Wikipedia rabbit hole. This invention of hyperlinking documents together to organize information was groundbreaking at the time.) HTML (Hypertext Markup Language) was invented to support these use cases. “Markup” languages in computer science get its name from “marking up” a physical document with annotations, such as when a teacher marks up an essay homework assignment. Today when your computer browser downloads a web page, it “parses” (which just means the computer “reading”) the document, looking for pre-defined HTML tags that mark up the text, and “renders” (displays) the content in your browser tab, accounting for the HTML tags. For example, if it sees the anchor tag, it will render the associated text as a link, which you can click (or tap) to visit another web page.


HTML was invented to annotate content, but not to determine how it should be styled when displayed. That should be determined by the browser on your computer. For example, should links be underlined? Should they be blue? Or purple? HTML was quickly abused to allow web page designers to style how they should look. (And to a certain degree, it still happens today.) CSS was invented in this context as a first class solution to solve the problem of styling content, instead of relying on HTML, which was not invented for that purpose, and thus not optimized for it. CSS or Cascading Style Sheets, allows web page designers a unique language to style existing HTML content. HTML and CSS go hand in hand. It’s “cascading” due to a mechanism whereby the designer’s rules cascade down, like a waterfall. (It becomes obvious once you learn it.) In the simple case, your browser downloads a web page HTML file and an associated CSS file at the same time. The browser uses the CSS file when parsing the HTML file, rendering the content in your browser tab according to the rules in the CSS file. For example, the CSS file could say links should be displayed in magenta and underlined, and that paragraphs should have 10 pixels of margin at the top.


HTML and CSS provided a way for web page creators to deliver rich content across the internet. But that content was inherently static, except for the linked nature of the web. People quickly wanted ways to introduce my functionality inside a web page. They wanted to add buttons and animations, and have users input data. They wanted the web page to be dynamic, and resemble the interactive nature of desktop apps at the time (such as Microsoft Word and Excel). JavaScript allows for this. It’s completes the trifecta of web development along with HTML and CSS. Today when you visit a website, your browser downloads many files, with HTML, CSS, and JavaScript programming code. Your computer takes in all that information, and renders a rich, interactive environment. It’s so rich, in fact, that we no longer call them websites or web pages. Instead, we call them web apps.

Contrast this with desktop apps on your computer or apps on your phone. In those scenarios, you first download and install an entire app onto your device. Most of the logic already exists as bits sitting in your device. When you open the app, it may pull in some data remotely from the internet. But by and large, the functionality already exists on your device and is running there. In a modern web app, you are essentially downloading an “entire” app in a real time when you visit a URL in your browser. The browser “runs” the app immediately. Once you close the browser the app, the app disappears from your computer (this is mostly true, ignoring some technical details). Therefore, there’s no notion of “installing” a web app.

Unsurprisingly, there’s lots more technical details when comparing desktop / phone apps (also called “native” apps) versus web apps. But for the purpose of this newsletter issue, know that HTML, CSS, and JavaScript are the basic building blocks of web apps, and you should gain some familiarity with them.

Modern web frameworks

The demand for web apps have become so dominant that technologists have invented many modern web frameworks that hide much of the complexity of HTML/CSS/JavaScript, especially their legacy technical problems. (You could sensibly argue the reverse, that modern web frameworks have allowed high quality web apps to proliferate, thus pushing their usage. But I usually think of things from a business context first, and the marketplace pulling technology forward.) These modern web frameworks free up frontend developers from wrangling with the technical underpinnings of JavaScript, allowing them to focus on delivering business value at a higher abstraction of software. They can treat the web truly as a first-class development platform.

Web frameworks are notorious since there’s so many of them, with many passionate communities arguing why their particular framework is better than others. As a PM, you should be aware of the more popular ones. These include React, Angular, and Vue.

How to learn frontend programming as a PM

This overview of frontend programming may seem overwhelming. But know that that’s precisely why software programming is a well-paid profession, and that there’s specialists who just do frontend programming. It’s a deep technical field that requires years of experience to build quality digital products. But as a PM, frontend programming is still very accessible, especially knowing just enough to make you an effective PM, as explained in the previous newsletter issue. To that end, here are few principles to consider when planning what to learn and how to learn.

  • Hands-on learning is the best learning: Your primary goal should not be to understand intricate computer science theory and definitely not the mathematical foundations of programming. You should know practical skills in order to be conversant with a frontend programmer. That means getting your hands dirty. Fortunately for programming, especially frontend programming, most tutorials show you step-by-step to get an app up and running right away. When you look for a tutorial, find one that focuses on setting up your development environment and getting that “hello world” program working right away.

  • Video tutorials are great for beginners: When learning difficult technical topics, having a person speak to you humanizes the material, often making it easier to comprehend. Video tutorials are great for this. Especially if you have very little technical background, you should have a human walking you through some basic steps. If you start with a written tutorial instead, it may be a too overwhelming. Video tutorials are slower yes. But if you are just getting started, you want to go slower. As you get more comfortable, you can move onto written tutorials. YouTube has plenty of great content. But because videos there are usually free, they may be outdated or generally of lower quality. I recommend investing in a paid and high quality course on a platform like Udemy, taught by folks who often are teaching full time. Be sure to also read the reviews when picking a course.

  • Get the basics of HTML/CSS/JavaScript first: Before jumping into a modern web framework, really focus on understanding the basics of HTML/CSS/JavaScript first. The skills here are very accessible, although sometimes tedious to learn. But once you have a basic understanding of them, you future learning will be much easier.

  • Learn one modern web framework: You only need to learn one modern web framework. Especially as a PM, since you don’t need to know the details, once you have a good understanding of the principles of one modern web framework, you can readily translate that learning to another framework. For example, suppose you learn React since your current team uses it. If the next team you join uses Vue, you’ll still be in good shape.

  • Learn what your team uses: This one is obvious. As a PM, the most immediate purpose of learning technologies, and web technologies in particular, is to be able to do your job better, and that starts with your current job. So you probably want to bias toward the web framework that your current team uses (hopefully it’s modern!). And once you’re comfortable with that you may consider learning others, as a hedge against working in other teams, within the same company, or in another company.

  • Caution against getting help from engineers: Unless an engineer colleague is an expert at teaching non-technical folks, caution against getting help from them, especially at the beginning. They aren’t geared toward explaining things to non-technical folks, so you might end up getting more confused. It’s not their fault. Just be wise in who to seek help from.

🤔 What should I write about in the next issue of Product Management 101?

Reply to this email and let me know!