Having a good technical understanding as a non-coder means grasping at a high level how the website is made.
That means a conceptual understanding of software architecture components, gaining some basic knowledge of languages like HTML or SQL, and understanding the software development life cycle.
You don’t need to be a coder, but a solid technical understanding matters if you’re working in a tech company. Becoming a more technical product manager can only help you make better decisions and improve your relationship with your squad.
Without this understanding it’s hard to work well with engineers, even harder to work well with an LLM to vibe code or prototype, and extremely difficult to do the best job you can do in almost every role within a technology company.
In this article we’re going to take you through
- Software application architecture: help you understand what a client, a server and a database actually do
- How the front end works: how HTML, CSS and Javascript combine to create the user interface
- Explain APIs: how data moves through systems, and practice making real API calls
- How the backend works: how the server processes user requests to make the product work
- Understanding databases: how databases work, how the data in your product is structured, and the role of SQL
- The software development cycle: covering Git, testing and deployment cycles
The article also includes a technical cheatsheet to help embed some of this terminology.
Technical product manager cheat sheet
To help with memorization of key concepts, plus as a guide to everyday code concepts and tags, we’ve included a technical product manager cheat sheet.
Hustle Badger Technical Product Manager Cheat Sheet
It includes:
- Software architecture glossary: what terms like front end or back end mean
- Software development cycle primer: what happens at every stage of code development
- Git terminology list: what terms like repo or branch mean
- Common HTML tags: to help you understand what they’re doing on a page
- Common CSS properties: to help read page components and bug test
- Common Javascript concepts: to help read page components and bug test
- Common SQL queries: to help you query data easily from your production database
Let’s get into what to understand to become a more technical product manager now.
Software application architecture
Nearly every software product has the same architecture:
- Frontend or Client: What the user sees and interacts with — buttons, forms, pages on screen - and what sends requests. Often written in HTML, CSS, and Javascript.
- Backend or Server: What processes requests behind the scenes and actually does the work. Handles logic, calculations, and decision-making. Often written in Python, Ruby, or Node.js.
- Database: Where all the permanent data and information is stored - the memory. Common databases include PostgreSQL, MySQL, MongoDB.
These are logical groupings based on the function each software application needs to perform. They use different programming languages and they focus on different use cases.
“You can think of the frontend as the exterior of a car and the backend as all the machinery inside. A beautifully designed car will only run optimally if the internal machinery works properly. However, certain aspects of exterior design also contribute to speed and performance. Similarly, your application's frontend and backend have to be designed cohesively for the best results.” - AWS
How the frontend works
The front end is the graphic interface that allows users to interact with your application. It can be a website, a mobile app, automobile or IOT interface. It covers UI and design elements such as buttons, menus and images.
Critically it is the software code that your users interact with directly, and which serves as the client, or the software which makes requests to the rest of your applications.
It executes directly in user’s browsers and devices, and therefore has specific characteristics associated with web deployment.
There are 3 computer languages standardly used to build frontend applications:
- HTML (Hyper-Text Markup Language): framework and structure for the frontend as a whole.
- CSS (Cascading Style Sheets): the layout and visual style of the page - order, colour, fonts
- Javascript: the page’s dynamic functionality - loading additional elements on the page, allowing sticky components when scrolling, or drop down or hamburger menu navigation (among other things).
If the page is a house, you can think of HTML as the building blocks, CSS as the layout and decor, and Javascript as what happens when you touch a light switch or button. They all work together to make a page.
HTML (Hyper-Text Markup Language)
The clue is really in the name with HTML - it’s a markup language, meaning it allows you to structure and lay out content for various purposes.
It uses tags (formatted in < >) to annotate how different types of content will appear on a page.
What this does:
This is a very basic webpage. It states the HTML language it is written in, and sets out a simple structure. The title, Hustle Badger, of course! is in the header, and underneath there’s a short paragraph, arranged as body text, that says We love Hustle Badger.
The Hustle Badger Technical Product Manager Cheat Sheet: HTML tags
HTML is universally accepted by every web browser, and is one of the core components of the world wide web. It was invented by Tim Berners-Lee in 1989.
CSS (Cascading Style Sheets)
CSS works with HTML to describe the format and style of HTML elements. The same CSS file can be linked to by multiple HTML documents.
CSS is used to set things like font types, sizes and colours, the padding, borders and background colours of containers and so on.
This enables consistent styling across multiple pages, and also makes styling much more efficient vs individually styling HTML elements.
Here’s an iteration on our earlier example, where our basic webpage is now formatted according to Hustle Badger style guidelines:
This is an example of internal CSS, where the styling information is stored within the HTML element.
Here’s another iteration of the example using external CSS: where a centralized style repository is used. You see how centralized external CSS makes things quicker and less prone to variation.
For the above code to work, there needs to be a style.css file, containing the relevant information stored in the same directory.
