Can LLMs really get cheaper?

Two weeks ago, I asked Peter Welinder, VP of Product at OpenAI, this question.

Peter explained, "There are two ways for LLM inference to be cheaper:"

1. Energy prices drop.

2. We find an alternative to NVIDIA.

Then he added:

1. Energy prices will continue to rise as demand increases much faster than supply.

2. NVIDIA currently has a monopoly, so we'll see about that.

In traditional businesses, you achieve economies of scale by reducing the cost per unit. Later, you sell the items with some margin, which, at scale, covers fixed costs (factory, equipment, employees, rent, etc.).

Model training is a fixed cost; however, the issue lies in the variable cost of inference. Being bound by energy prices, hardware/infrastructure, and the growing size of models (meaning more compute to train [fixed cost] and more expensive inference [variable cost]), the only logical approach is to increase prices.

However, competition emerges, providing better models in different areas every 3–6 months, raising consumer expectations for quality. With almost zero switching costs and no brand loyalty (like with Coke/Pepsi), R&D spending is increasing even more, adding to the total cost.

Now we have:

• Models that are expensive to train.

• AI labs can't (yet) charge a premium for providing the model.

• Energy prices are not decreasing.

• Heavily invested AI labs need to generate revenue at some point (within 12–24 months).

Given these factors, I don’t see a way for prices to decrease, assuming market dynamics remain the same.

LLMs gained popularity through a UX innovation with ChatGPT. Now, it seems we need a financial innovation to sustain their growth.

What do you think?

• The fundamentals of REST architecture

• Key REST methods: GET, POST, PUT, DELETE

• Code example using Node.js

• Hands-on demonstration with Postman

Whether you're new to APIs or looking to level up your technical knowledge, this course provides practical insights to help you communicate effectively with your engineering team. We'll walk you through code examples and show you how to use essential tools like Postman to interact with APIs.

📚 Topics covered:

• What is REST?

• REST architectural constraints

• Understanding API requests and responses

• Implementing a simple API server in Node.js

• Testing APIs with Postman

Don't let technical terms intimidate you! By the end of this video, you'll have a solid grasp of REST APIs and be ready to dive deeper into the world of API development.

👨‍💻 Perfect for: - Product Managers - Aspiring Technical PMs - Anyone looking to understand APIs better

🔗 Resources:

1. Course slides and materials are available on

2. HackerPM Crash Course repository on Github

Hope you enjoy this video! Let me know what you think in the comments. Bye! 👋

Leave a comment

We'll go step-by-step, from brainstorming the app name to deploying the final product. You'll see how AI can help generate UI, write compelling copy, and even troubleshoot errors. It's like having a coding wizard by your side! 🧙‍♂️

In the video, I will go over a 10-step guide on how to build the landing page:

1. Download Cursor and sign up for a free account.

2. Choose a project name and specify that it’s a web application.

3. Install the necessary tools including Versal, a tool that helps generate UI, Cloud 3.5, an AI tool to help generate code, and a GitHub account for hosting the code.

4. Use the chat function in Cursor to brainstorm a name for the application.

5. Use Cursor to create a Next.js app.

6. Use the chat function again in Cursor to write a landing page copy that is optimized for conversion.

7. Use the composer function in Cursor to automatically apply the code for the landing page copy.

8. Preview the landing page in the browser.

9. Push the code to a GitHub repository.

10. Use Vercel to deploy the landing page.

Enjoy and let me know your feedback and questions in the comments!

Subscribe now

Useful Links

1. Cursor: https://www.cursor.com

2. Vercel: https://vercel.com

Today, we're going to be discussing the concept of serverless computing and how it can be used to deploy software products. This is the other side of the coin compared to yesterday, where we talked about Web Servers and why we need them.

Serverless computing is a way of building and running applications and services without the need to manage infrastructure. This means that developers do not have to worry about setting up and maintaining servers and can instead focus on writing and deploying code.

But before jumping into it, a small announcement! (super big actually)

📣 Upcoming course for HackerPM

I'm working on building a live, 2-week-long cohort-based course for Product Managers to learn technical concepts with ease and get ready for managing technical products. You’ll learn how to tackle a new technical product, how to do technical discovery together with your engineers as well as how to build long and sustaining relationships with them.

I’ve worked on this topic for the last 5 years working at leading scale-ups in the Nordics. Now I’d love to teach you. Fill out this survey to get on the waitlist & be the first to hear when enrollments open.

🎁 You'll also get a 10% discount on the final price (and 20% if you are a pro member of HackerPM).

Why Serverless?

After a small announcement, back to the topic. 🤓

Serverless computing was invented in order to address the challenges and complexities of managing infrastructure in traditional computing models. In the past, developers had to worry about setting up and maintaining servers, as well as scaling the infrastructure to meet the needs of their applications. This required a significant amount of time and effort and could be a barrier to getting applications to market quickly.

In a serverless model, the provider (such as AWS, Azure, or Google Cloud) is responsible for executing the code and scaling the application as needed. The provider charges for the actual execution of the code, rather than for a pre-allocated amount of computing resources. This can lead to cost savings, as the developer only pays for the resources that are actually used, rather than for a fixed amount of computing capacity.

Comparison to web servers

If you remember from yesterday's post, a web server software such as Apache or NGINX is a program that runs on a server and is responsible for handling HTTP requests and serving web content. In this model, the developer is responsible for setting up and maintaining the server and the web server software, as well as deploying the application code.

One key difference between serverless computing and web server software is the level of control and responsibility the developer has over the underlying infrastructure. With serverless computing, the provider is responsible for executing the code and scaling the application as needed, while with web server software the developer is responsible for setting up and maintaining the server and the web server software.

Another difference is the way that the developer is charged for the use of computing resources. In a serverless model, the developer is only charged for the actual execution of the code, rather than for a pre-allocated amount of computing resources. This can lead to cost savings, as the developer only pays for the resources that are actually used, rather than for a fixed amount of computing capacity.

Let's explore popular Serverless providers in the market.

Does serverless actually mean no servers?

Any program on the computer runs on the hardware, as well as serverless applications are run on the servers, but this part is not exposed to the developers and is self-managed by the vendors.

So in the end, the general mental model we have of how online software products work is still correct.

AWS Lambda

Amazon Web Services (AWS) Lambda is a serverless computing platform. It is a service that allows developers to run code without having to worry about the underlying infrastructure.

With AWS Lambda, developers can upload their code and the service will automatically execute it in response to specific events or triggers. These events or triggers can include things like a change in a database, a message arriving in a message queue, or a request to an API.

One of the key benefits of using AWS Lambda is that it automatically scales the execution of the code based on the number of incoming requests or events. This means that the developer does not have to worry about provisioning or managing servers, and can instead focus on writing and deploying code.

AWS Lambda is charged based on the number of requests for the function and the duration of the execution. This means that the developer only pays for the resources that are actually used, rather than for a fixed amount of computing capacity.

• Link to Serverless page on AWS

As you'll notice, there are many different services only in Amazon Web Services to support "Serverless" architecture. We touched only Lambda as one of the key elements in the serverless package.

Google Cloud Functions

Google Cloud Functions is a serverless computing platform offered by Google Cloud. It allows developers to run code in response to specific events or triggers, without the need to worry about the underlying infrastructure.

Like AWS Lambda, Google Cloud Functions automatically scales the execution of the code based on the number of incoming requests or events.

Google Cloud Functions is charged based on the number of invocations of the function and the duration of the execution, just like AWS Lambda.

Comparison between Lambda, Cloud Functions, and Azure's Serverless offering

In one photo:

Other providers

AWS Lambda and Google Cloud Functions are only the tips of the Serverless iceberg. There are many more providers in the market, ranging from enterprise-grade to open-source ones. Here is a quick list of other popular serverless choices:

1. Azure Functions: A serverless computing platform offered by Microsoft Azure that allows developers to run code in response to specific events or triggers.

2. IBM Cloud Functions: A serverless computing platform offered by IBM Cloud that allows developers to run code in response to specific events or triggers.

3. Oracle Cloud Functions: A serverless computing platform offered by Oracle Cloud that allows developers to run code in response to specific events or triggers.

4. AWS Fargate: A fully managed container execution service offered by AWS that allows developers to deploy and run containerized applications without the need to worry about the underlying infrastructure.

5. Google Cloud Run: A fully managed serverless platform offered by Google Cloud that allows developers to deploy containerized applications.

6. Azure Container Instances: A serverless computing platform offered by Microsoft Azure that allows developers to deploy and run containerized applications.

The updated mental model for Serverless architecture

A quick recap:

• Frontend frameworks to build the client-facing application.

• The Serverless infrastructure to host the application logic (in comparison to a backend framework and web servers)

• Databases and other libraries, if any (such as authentication, notification, ...) stay the same as before.  

To be serverless or not? That's the question

Product managers should consider a number of factors when deciding whether to use a web server or a serverless architecture. Some of the key considerations include:

1. Cost: Serverless computing can be more cost-effective in some cases, as the developer is only charged for the actual execution of the code, rather than for a pre-allocated amount of computing resources.

2. Scalability: Serverless computing allows for automatic scaling of the application based on the number of incoming requests or events. This can be useful for applications that experience fluctuations in traffic.

3. Time to market: Serverless computing can allow for faster development and deployment of applications, as the developer does not have to worry about setting up and maintaining infrastructure.

4. Complexity: Serverless computing can be simpler for developers to use, as they do not have to worry about managing infrastructure.

5. Integration with other services: Some serverless platforms, such as AWS Lambda and Google Cloud Functions, offer a wide range of integrations with other services, which can be useful for building more complex applications.

Overall, serverless computing can be a cost-effective and efficient way to deploy applications, as it allows developers to focus on writing code and allows the provider to handle the underlying infrastructure.

Thank you for reading, and we hope you found this information helpful. Until next time!

But before that, as we are only a few days away from the end of the #AdventCalendar series, let's have a look back at the content we covered over the past 3 weeks.

Summary of the past three weeks in 2 minutes

Here are some common technologies that are often used in modern software development:

• Programming languages: Some popular programming languages used in software development today include Java, Python, C#, C++, and JavaScript. Even though we haven't covered this, we assume we are all aware of the fact that there are several different programming languages, each with its pros/cons, community, and use cases. A hacky introduction to popular ones will be a series soon!

• Web development frameworks: These frameworks provide a structure for building web applications and include tools for routing, templates, and database access. Examples include Django (Python), Ruby on Rails (Ruby), and ASP.NET (C#). We covered these on Day 17, Backend Frameworks.

• Database technologies: Many software applications use databases to store data, and there are several database management systems (DBMS) to choose from. Some popular DBMSs include MySQL, PostgreSQL, and Microsoft SQL Server. Check out Day 18 for more info on DBs.

• Cloud computing platforms: Cloud computing platforms such as Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform provide a range of services including computing, storage, and networking that can be accessed over the internet. This an adjacent topic for today's, but not exactly. We'll take Cloud computing when we are building a product together, over a newsletter, isn't that cool? 🤩

• Containerization: Containerization technologies such as Docker allow developers to package their applications and dependencies into a container that can be easily deployed and run on any machine. We explained this topic on Day 21, Containerization for Product Managers.

• Version control systems: Version control systems such as Git allow developers to track changes to their codebase and collaborate with other team members. Don't forget to check out the 3 part tutorial on Git: Part 1, Part 2, and Part 3.

• Continuous integration and deployment (CI/CD) tools: CI/CD tools such as Jenkins, CircleCI, and Travis CI automate the process of building, testing, and deploying code changes. Learn more on CI/CD on Day 7, and Day 8.

• Server software: Server software such as Nginx and Apache are used to host web applications and serve web content to users. We will cover this in today's session!

😍 With this, you can say you have a full view of most of the technologies used in a typical software development project. 

Server software

First, let's define what we mean by the server software. Simply put, the server software is a type of software that runs on a server and enables it to host web applications, serve static content, or perform other tasks. Some examples of server software include Nginx, Apache HTTP Server, and Microsoft IIS.

Now, let's dive a little deeper into two of these server software options, NGINX and Apache HTTP Server.

NGINX

NGINX (pronounced "engine x") is a web server that is often used to host web applications and serve static content, such as images and HTML files. It is known for its high performance, stability, and low resource consumption, making it a popular choice for web servers.

NGINX can also be used as a reverse proxy, load balancer, and HTTP cache.

As a reverse proxy, it can route traffic from the internet to one or more back-end servers, which can be helpful in several scenarios, such as serving multiple applications from the same domain, load balancing, and offloading SSL/TLS termination.

As a load balancer, NGINX can distribute incoming requests to multiple servers to improve performance and reliability.

As an HTTP cache, it can store commonly requested content in memory, reducing the load on back-end servers and improving the response time for users.

Some alternatives to NGINX include Apache HTTP Server and Microsoft IIS. Both of these servers are also widely used and have similar features, but NGINX is generally considered to be faster and more efficient than Apache and has a smaller memory footprint than IIS.

In comparison to other web servers, NGINX has several benefits:

• High performance: NGINX is known for its fast performance and can handle a large number of concurrent connections with minimal resources.

• Low resource consumption: NGINX has a small memory footprint and can run on relatively low-powered machines, making it a good choice for environments with limited resources.

• Modular architecture: NGINX is built on a modular architecture, allowing users to choose the features they need and minimizing the risk of security vulnerabilities.

• Versatility: In addition to serving as a web server, NGINX can also be used as a reverse proxy, load balancer, and HTTP cache, making it a versatile tool for web infrastructure.

• Wide adoption: NGINX is widely used by several high-traffic websites, including Netflix, Dropbox, and Airbnb, giving it a proven track record of stability and reliability.

Apache HTTP Server

Apache HTTP Server is a popular open-source web server that is widely used to host web applications and serve static content, such as images and HTML files. It is developed and maintained by the Apache Software Foundation and is available for several operating systems, including Linux, Unix, and Windows.

Apache HTTP Server is known for its stability, security, and flexibility. It supports a wide range of features, including support for multiple protocols (such as HTTP and HTTPS), virtual hosting (allowing a single server to host multiple websites), and the ability to run multiple modules that can extend its functionality.

One of the main advantages of Apache HTTP Server is its widespread adoption and large user community. It has been around for a long time and has a proven track record of stability and reliability. There is also a wide range of third-party modules available that can be used to extend its functionality, such as mod_rewrite (for URL rewriting) and mod_ssl (for SSL/TLS support).

In comparison to other web servers, Apache HTTP Server has several benefits:

• Wide adoption: Apache HTTP Server is widely used by a large number of websites, giving it a proven track record of stability and reliability.

• Customization: Apache HTTP Server is highly customizable and can be extended with a range of third-party modules.

• Security: Apache HTTP Server has several security features, such as support for SSL/TLS and the ability to run in a chroot environment.

• Flexibility: Apache HTTP Server can be used to host multiple websites on a single server and can support a variety of protocols.

• Community support: Apache HTTP Server has a large user community, which provides a wealth of resources and support for users.

Recap

In summary, server software is a type of software that runs on a server and enables it to host web applications, serve static content, or perform other tasks. Some examples of server software include Nginx, Apache HTTP Server, and Microsoft IIS. These options have different features and capabilities, and it's important to consider the specific needs of our products when choosing the right server software.

Now, you might be wondering why these different server software options matter for the products we manage. The server software that we choose can have a significant impact on the performance, security, and scalability of our products. It's important to consider the specific needs of our products and choose the server software that will best meet those needs.

I hope this helps to give you a better understanding of server software and how it relates to the products we manage. If you have any questions or would like to learn more, don't hesitate to reach out.

One of the technologies that are less than 10 years old but is commonly used today is Docker and the concept of Containerization of software.

In this post, we'll provide a high-level overview of these powerful tools and show you how to get started using Docker and Kubernetes.

At a super high level, Docker, Kubernetes, and all the other "containerization" platforms help with breaking down the code to microservices and running them across different environments with ease (or as easy as it gets 😬). It's the most common way for companies to build Saas products today.

You might recognize the DevOps and Microservices above which we explained before. 😎

Get the slides for this post for quick review.

What is Containerization?

Containerization is a software development technique in which applications are packaged and deployed in lightweight, standalone containers. Containers allow applications to be run in isolated environments, which helps to ensure that they are portable and can be easily deployed and run on any machine.

For engineers, Containerization simplifies the process of developing, testing, and deploying applications by eliminating the need to worry about differences in infrastructure and dependencies. It allows engineers to focus on writing code, rather than worrying about the underlying infrastructure.

It can also make it easier to scale applications and deploy them to different environments, such as between development, staging, and production environments. Remember Environments? 😉

What containerization platforms are out there?

There are a number of containerization platforms that are popular among developers for packaging and deploying applications in containers. Some of the most popular include:

Docker

Docker is a containerization platform that is widely used for developing, deploying, and running applications in containers. It is easy to use and has a large ecosystem of tools and resources.

Kubernetes

Kubernetes is an open-source container orchestration platform that is designed to be scalable and flexible. It is often used to manage large-scale deployments of containerized applications, and it is supported by all major cloud providers.

🤓 Have you seen Kubernetes being written as "K8s"? (which is still pronounced the same as "Kubernetes"). This technique of abbreviating is called "Numeronym". In the case of K8s, it's the first letter K, the last letter s, and 8 is the number of letters in between.
You might have also seen i18n which is short for "Internationalisation", just like K8s.

Apache Mesos

Apache Mesos is a cluster manager that can be used to manage containers as well as other types of workloads. It is designed to be highly scalable and is used in a number of large-scale deployments.

Amazon Elastic Container Service (ECS)

Amazon ECS is a fully managed container orchestration service provided by Amazon Web Services (AWS). It is designed to be easy to use and integrates seamlessly with other AWS services.

Azure Container Service (ACS)

Azure Container Service is a fully managed container orchestration service provided by Microsoft Azure. It supports a number of different container orchestrators, including Kubernetes, and Docker Swarm.

We'll cover Docker and Kubernetes in this post.

What is Docker?

Docker is a containerization platform that allows developers to package and deploy applications in lightweight, standalone containers. Containers allow applications to be run in isolated environments, which helps to ensure that they are portable and can be easily deployed and run on any machine.

Using Docker can simplify the process of developing, testing, and deploying applications by eliminating the need to worry about differences in infrastructure and dependencies. It allows engineers to focus on writing code, rather than worrying about the underlying infrastructure.

Docker is widely used today because it offers a number of benefits, including:

• Portability: Docker containers can be easily moved between different environments, such as between development, staging, and production environments.

• Isolation: Docker containers provide isolated environments for running applications, which helps to ensure that applications do not interfere with each other.

• Resource efficiency: Docker containers are lightweight and can be more resource-efficient than traditional virtual machines.

Common terms in Conterization-verse

Or more correctly, in Docker-world!

Dockerfile

A Dockerfile is a text file that contains instructions for building a Docker image. It is used to automate the process of building and deploying applications in containers.

It allows developers to define the steps needed to build an image and package an application in a container, which can make it easier to deploy the application to different environments.

A Dockerfile typically starts with a base image, which is an image that provides the foundation for the container. The base image might be an operating system image, such as Ubuntu or CentOS, or it might be an image containing a specific application or framework.

Image

An image is a blueprint for a container. It is a package that contains the code, libraries, and dependencies needed to run an application.

Container

A container is a lightweight, standalone package that contains an application and its dependencies. It is designed to be portable and can be easily run on any machine.

Containerization platform

A containerization platform is a piece of software that allows developers to package and deploy applications in containers. Examples of containerization platforms include Docker and Kubernetes.

Registry

A registry is a repository of images. It is a place where images can be stored, shared, and downloaded.

All in all, putting all the concepts together, here are the pieces of Docker put together:

Kubernetes

Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications. It consists of a number of components that work together to provide a flexible and powerful platform for managing containers.

At a high level, Kubernetes works by deploying containers onto a cluster of machines and then managing the containers to ensure that they are running as intended. The Kubernetes control plane is responsible for coordinating the activities of the various components in the cluster and making decisions about how to manage the containers.

Here are some of the key components of Kubernetes and how they work together:

• Master nodes: The master nodes are the central control plane of the cluster. They consist of a number of components, including the API server, scheduler, and controller manager, which work together to manage the cluster.

• Worker nodes: The worker nodes are the machines on which the containers are actually deployed and run. Each worker node runs a kubelet, which is responsible for managing the containers on that node.

• Pods: A pod is the basic unit of deployment in Kubernetes. It is a logical host for one or more containers, and all the containers in a pod share the same network namespace and storage.

• Deployments: A deployment is a higher-level object that manages the deployment of a set of replicas of a pod. It ensures that the specified number of replicas are running at all times, and it can be used to roll out updates to the pods.

• Services: A service is an abstract way to expose a set of pods to external traffic. It provides a stable IP address and DNS name for the pods, and it can load balance traffic to the pods.

Overall, Kubernetes is a complex system with many components that work together to provide a flexible and powerful platform for managing containerized applications.

Docker vs. K8s

Docker and Kubernetes are both tools for developing and deploying applications in containers, but they have some key differences:

• Scope: Docker is primarily a containerization platform, while Kubernetes is a container orchestration platform. This means that Docker is focused on building and running individual containers, while Kubernetes is focused on managing a cluster of containers and scaling applications across multiple machines.

• Architecture: Docker uses a client-server architecture, with a daemon running on the host machine and a command-line interface (CLI) for interacting with the daemon. Kubernetes has a more complex architecture, with a number of components that work together to manage the cluster, including the API server, scheduler, and controller manager.

• Ecosystem: Docker has a large ecosystem of tools and resources, including a registry for sharing images and a number of third-party tools for managing containers. Kubernetes also has a large ecosystem, but it tends to be more focused on enterprise-grade tools and solutions.

• Deployment: Docker can be used to deploy applications in a variety of settings, including cloud and on-premises environments. Kubernetes is particularly well-suited to cloud deployments, and it is supported by all major cloud providers.

Container vs. Virtual Machines

You might have heard about Virtual Machines (from somewhere 👀). Containers and virtual machines are both technologies that allow developers to run applications in isolated environments. However, they have some key differences:

• Isolation: Both containers and virtual machines provide isolation by running applications in separate environments, but they achieve this in different ways. Virtual machines use hardware virtualization to create a completely separate environment for each application, including a separate operating system and hardware resources. Containers, on the other hand, use operating system-level virtualization to share the host operating system and hardware resources but provide isolation for applications at the process and namespace levels.

• Resource usage: Containers are generally more lightweight and resource-efficient than virtual machines, as they do not require a separate operating system and hardware resources for each application. This can make them more cost-effective for running applications in the cloud or on other shared resources.

• Deployment: Virtual machines are typically deployed as a single entity, with the operating system and application bundled together. This can make them more difficult to deploy and manage at scale, as they require more resources and take longer to start up. Containers, on the other hand, are designed to be lightweight and portable, and they can be easily deployed and scaled using container orchestration platforms like Kubernetes.

Containers may be a good choice for applications that require isolation and portability, but have modest resource requirements, while virtual machines may be a better fit for applications with more demanding resource requirements or that require a dedicated operating system.

If you want to test them out

Getting Started with Docker

To get started using Docker, you'll need to install it on your machine. You can download the Docker Desktop for Windows or macOS from the Docker website.

Once Docker is installed, you can use the docker run command to pull an image from a registry (such as Docker Hub) and run it as a container. For example, to run an Ubuntu container, you could use the following command:

docker run -it ubuntu

This will pull the latest version of the Ubuntu image from Docker Hub and run it as a container. You can then use the docker exec command to execute commands inside the container. For example, to start a bash shell inside the container, you could use the following command:

docker exec -it <container-name> bash

Getting Started with Kubernetes

To get started using Kubernetes, you'll need to install it on your machine. You can download the Kubernetes command-line tool, kubectl, from the Kubernetes website.

Once kubectl is installed, you can use it to interact with a Kubernetes cluster. You can use the kubectl create command to create resources in the cluster, such as pods and deployments. For example, to create a deployment that runs a single replica of an nginx container (more on this later), you could use the following command:

kubectl create deployment nginx --image=nginx

You can use the kubectl get command to list the resources in the cluster, and the kubectl describe command to get more information about a particular resource.

Summary

Docker and Kubernetes are powerful tools for developing, deploying, and managing applications. They can help to streamline the development and deployment process and make it easier to scale applications.

I hope this post has provided a useful introduction to these tools and has given you the confidence to start using them in your projects.

Happy containerizing!

I hope you enjoyed yesterday's post on the modeling language you can use to design a database. I'm looking forward to your submissions for the "Design a Database in ERD" challenge. The submission form is here.

In today's post, we are going to go one step deeper in database design and learn more about data. And more correctly about Data Types and Data structures.

Buckle up, it'll be a geeky road ahead! You can also go over the slides over here.

Data types

As product managers, it's important to have a basic understanding of data types, as they play a crucial role in how we design and develop our products.

Data types define the kind of data that a program can handle and the operations that can be performed on that data. In this post, we'll take a look at some common data types and why they are important for product managers to know about.

Common data types

Integer

An integer is a whole number that can be positive, negative, or zero. Examples include 42, -23, and 0.

Floating point

A floating point number is a number with a decimal point and can represent fractional values. Examples include 3.14, -0.01, and 1.0.

String

A string is a sequence of characters and is often used to represent text. Examples include "Hello, world!", "This is a string", and "123".

Boolean

A boolean is a data type that can have one of two values: True or False. Examples include True, False, and False.

Array

An array is a data type that stores a collection of values and can be of any data type. Examples include [1, 2, 3], ["a", "b", "c"], and [True, False, True].

Dictionary

A dictionary (also called a map or associative array) is a data type that stores a collection of key-value pairs, where each key is associated with a value. Examples include {"a": 1, "b": 2, "c": 3}, {"name": "John", "age": 30}, and {"True": "Yes", "False": "No"}.

Set

A set is a data type that stores a collection of unique values and does not allow duplicate values. Sets are often used for tasks like searching and filtering and can be implemented using various data structures such as hashtables or trees.

Tuple

A tuple is a data type that stores a fixed-length sequence of values and can be of any data type. Tuples are often used to store related pieces of data that should not be modified and can be accessed using indexing or unpacking.

Mainly used in Python, tuples are similar to lists except for the following:

A quick guide on the nomenclature here:

• Immutable means the tuple object can't be modified after it's created. If you want to change something, you need to create a new one with a copy of the data + the modified element.

• Because they are immutable, their size will be fixed too. (as no element can be added or removed).

Function

A function is a data type that represents a block of code that can be executed and can accept parameters, and return a result. Functions are often used to encapsulate reusable code and can be passed as arguments or returned as values from other functions.

Examples of languages that function is a data types are Javascript and C/C++.

Object

An object is a data type that represents a complex data structure and can contain a combination of different data types and methods. Examples might include an object representing a person, with properties such as name, age, and address.

🤓 When designing a database, most of the time we are designing the tables to copy the Objects used in the code and save them in databases. This concept is called "persisting" the data. Most of the time there will be additional columns in the table that are not part of the object, such as data it's created, edited, deleted, etc.

Class

A class is a data type that represents a blueprint for creating objects and can contain data (properties) and behavior (methods). Classes are often used to model real-world concepts and can be used to create objects that share a common structure and behavior.

In another word, Objects are created from Classes.

Enum

An enum (short for enumeration) is a data type that represents a set of predefined constants and is often used to represent a set of related values that do not change. Enums can be used to make code more readable and prevent the use of magic values.

Wrap up

It's important to note that the specific data types and their characteristics will vary depending on the programming language being used. Some languages, such as dynamically typed languages like Python, have a more flexible type system and allow for the creation of custom data types, while other languages, such as statically typed languages like Java, have a more rigid type system and define a fixed set of data types.

Understanding data types is an essential skill for product managers, as it can help us make informed decisions about how to design and develop our products, communicate more effectively with technical team members, and understand the trade-offs and limitations of different approaches. I hope this post has provided a helpful overview of some common data types, and encourages you to continue learning and exploring this important topic.

If you missed yesterday's post, check it out here. We introduced basic concepts about Data, Data types, What is a Database (DB), and different Database types, such as Relational and NoSQL databases.

We also touched upon several commonly used terms around Data and databases, such as Transactions, Normalisation, and Primary Key.

In today's post, we'll explore working with Databases hands-on, from a schematic perspective. By schematic, I mean being able to read UML diagrams and Entity Relationships (ER).

Why hands-on? Because I think it's the best way to learn something that sounds complex. This is called Top-down Learning and looks something like this:

According to the Merriam-Webster dictionary, Top-Down refers to the breaking down of large general aspects (as of a problem) into smaller more detailed constituents: working from the general to the specific.

In this post, we'll explore Data and Databases from this angle, and with the best, I can make it Top-down. 😄

Slides can be found here

What do we need?

If I want to break down Databases top-down, after we have covered the basics yesterday, I'll walk you through how to Design a Database by yourself. Sounds scary?

Well, it shouldn't be. Because we will do it all "on paper" and there is no cost for any mistakes. You can design any app you want (or use) in any way you'd like.

But before jumping into designing, we need to know how we are going to design a database. For that, we'll get familiar with UML first.

What is UML?

UML (like any other concept) can be deep and complex by itself, but let's touch on this in the Top-down approach too. We will learn only the things we need.

UML (Unified Modeling Language) is a standardized modeling language that is used to create visual diagrams of software systems. It is a visual language that is used to represent the structure and behavior of a system, including the relationships and interactions between different elements of the system.

UML includes a set of graphical notation elements that can be used to create visual models of a system. These elements include things like classes, objects, relationships, and interactions. The UML specification defines a set of rules for using these elements to create visual models of a system, and these models can be used to communicate the design of a system to stakeholders and developers.

These symbols (and a UML chart) look something like below. (Note it's a Cheat Sheet, so the text is explaining the symbol itself).

UML is often used to create diagrams that represent the structure of a system, including class diagrams that show the relationships between different classes, and sequence diagrams that show the interactions between objects and their relationships over time. UML is also used to create activity diagrams that show the flow of activities within a system, and state machine diagrams that show the different states that an object can be in and the transitions between those states.

In that sense, UML is like a map. Map of the system we are building, in the data and class levels. 

Note that UML can be used for many more applciations and there are many different types, such as Structural (Class Diagram, Component Diagram, Package Diagram,..) and Behavioural (Activity, Communication, Interaction Diagrams, ...).
Today we focus on ERD (Entity Relationship Diagrams) to be specific.

Example UML diagram

Before jumping to understanding the pieces inside the map (which would be "normal" in a bottom-up approach, as we did in school), let's have a look at a complete UML for a database and then explore each element of it.

Let's look at a sample UML diagram like below.

The chart above has two main object types:

1. Boxes (called Entities)

2. and Lines, connecting the boxes, probably showing their "relationship".

ERD basics

A quick for me to dive into a new concept in the Top-down approach is always looking at the "cheat sheets" available for that topic.

🤓 I will use UML and ERD interchangeably going forward. ERD is a subset of UML diagrams, but in this post, we only talk about ERD diagrams.

You can start by searching for "ERD Chear sheet" and you'll get many images like the one below, explaining basic elements in one or a few pages.

Homework

Having the above cheat sheets and an app of your choice (for example Uber, Airbnb, Netflix, Amazon,...) design the ERD for each entity you can think of and connect them using the association links (cardinalities).

Which tools you can use?

You can use tools such as Miro and Lucidchart, among many others, to design your ERD.

More resources to read on ERD if you need any help:

• ER Diagrams by Lucidchart

• A Guide to the Entity Relationship Diagram (ERD)

• What is Entity Relationship Diagram (ERD)?
  

Have fun diagramming!

One of the core concepts in any modern software product is Data and Databases. I can't write or emphasize enough the importance of Data and "Insights". The best I can do is to say:

Data is not the new oil, it's even more valuable and important!

In the next couple of episodes, I'll cover more on Data and its related concepts, so you can feel more comfortable talking about Data and Data products, as well as be able to utilize it more and more in your day-to-day work.

Slides can be found here

What is Data?

Just to cover the basics, let's go with our definition of Data:

Data is a collection of facts, statistics, or other pieces of information that can be used to inform decisions or support conclusions.

Data can be numerical, textual, or graphical (data type) and can be collected from a variety of sources, such as databases, surveys, experiments, or observations.

Importance of Data

Data is a valuable asset for organizations and individuals, as it provides insights and information that can be used to make informed decisions and take strategic actions. Here are a few reasons why data is important:

• Data helps to drive business growth and innovation: By analyzing data, companies can identify trends and patterns, and use this information to improve their products, services, and processes. Data can also help businesses to identify new opportunities and make better decisions about where to invest resources.

• Data can improve efficiency and productivity: By analyzing data, organizations can identify inefficiencies and areas for improvement in their operations. Data can also help to automate and streamline processes, which can increase productivity and reduce costs.

• Data helps to inform decision-making: Data provides a factual basis for making decisions, rather than relying on assumptions or gut feelings. By analyzing data, organizations and individuals can make more informed and accurate decisions.

• Data is a key component of analytics and machine learning: Data is the fuel that powers analytics and machine learning algorithms and is used to train these systems to make predictions, detect patterns, and take actions.

• Data can be used to personalize experiences and create targeted marketing: By analyzing data about customer behavior and preferences, companies can create personalized experiences and targeted marketing campaigns that are more likely to be successful.

Overall, data is a critical asset that can be used to drive growth, improve efficiency, inform decision-making, and create personalized experiences.

Qualities of Valuable Data

Just like "oil" which is not refined and not all oils are equal, Data should have several characteristics to be valuable and useful. These characteristics are:

1. Accuracy: Data should be accurate and free from errors, in order to be reliable and trustworthy.

2. Relevance: Data should be relevant to the problem or decision at hand, and should provide useful information for the context in which it is being used.

3. Completeness: Data should be complete and contain all relevant information, in order to provide a comprehensive and accurate view of the situation.

4. Timeliness: Data should be current and up-to-date, in order to be relevant and useful.

5. Accessibility: Data should be easily accessible and available to those who need it, in a format that is easy to use and understand.

By having these characteristics, data can be valuable and useful for a variety of purposes, including decision-making, problem-solving, and analysis. If any of these characteristics are under question or not verifiable, you might need to think twice before basing your "next big decision" on it.

📊 There is a lot to say about "Data-driven" decisions which deserve their own series after we covered the basics of Data and are comfortable with using and analyzing it.

What is a Database and why do we need it?

To go over the breadth quickly, our next stop in the "universe of data" 🪐 is Databases. It's defined as:

A database is a structured collection of data, usually stored and accessed electronically. It is a way to organize and store data that can be easily accessed, updated, and managed by computers.

In other words, a collection of data in an organized manner (easy to store, find, retrieve, edit, ...) is called a Database.

This organization of data helps us to utilize it for the purpose we have. (Note: There should be a purpose with data collection and analysis, sometimes we forget about this simple concept 🙈)

The history of databases dates back to the 1960s when the first database management systems were developed. These early systems were used to store and manage large amounts of data for scientific and government applications. In the following decades, databases became more widely used in business and other industries, and the development of the Internet and the World Wide Web led to the creation of many new database-driven applications.

Databases are used in a wide variety of applications, including online stores, social media platforms, banking systems, and customer relationship management systems. They are an integral part of modern software development and are used to store and manage data for many different types of applications.

☝️Fun fact: the word "database" was coined by IBM researcher Dr. Edgar F. Codd in the 1960s when he was working on the development of the first relational database management system.

Different types of Databases

Because there are many different types of data and we might use them for different purposes, naturally we need a different way to store and organize them.

There are several types of databases, including relational databases, which store data in tables with rows and columns, and non-relational databases, which store data in a more flexible format.

Some common examples of relational databases include MySQL, Oracle, and Microsoft SQL Server. Non-relational databases include MongoDB, Cassandra, and Redis.

When choosing a database for a particular application, it is important to consider the type of data that will be stored, the number of users who will be accessing the database, and the performance and scalability requirements of the application.

Are these the only database types we have?

Actually "No!", there are many more database (DB) types, depending on how we categorize them (how the data is stored, whether is it central or distributed, what data type is stored and so on). Let's go over these types in more detail:

Relational Database

Relational databases are organized into tables with rows and columns, and SQL is used to create, modify, and query these tables. SQL (Structured Query Language) is a programming language that is used to manage and manipulate data stored in relational databases.

NoSQL Database

NoSQL (Not Only SQL) is a term used to describe a category of databases that are designed to handle large amounts of unstructured or semi-structured data. These databases are typically non-relational, meaning that they do not use the table-based structure of relational databases. Instead, they use more flexible data models that can store data in a variety of formats, including documents, key-value pairs, and graphs. Some common examples of NoSQL databases include MongoDB, Cassandra, and Redis.

Other types of Non-relational databases are:

• Column-based

• Key-value database

• Graph database

• Document or Object-oriented database

Column-based Database and more

Column-based databases are a type of database that stores data in columns rather than rows. This allows for more efficient querying and faster access to specific data points. Column-based databases are often used for data warehousing and analytics applications, where large amounts of data need to be analyzed and queried quickly. Some examples of column-based databases include Apache Cassandra and Apache HBase.

Other types of databases include object-oriented databases, which store data as objects in an object-oriented programming language, and graph databases, which store data as nodes and edges in a graph structure.

It is important to choose the right type of database for a particular application, based on the data being stored, the performance and scalability requirements, and the needs of the application.

Concepts around Data and Databases

Now that we touched Data and Databases at a very high level (we'll get our hands dirty with SQL too, but that's for another day, my friend 😉), let's go over some key concepts that you might hear or see when talking about Data:

Data model

A data model is a way of organizing and structuring data in a database. Different types of data models include the relational model, which organizes data into tables with rows and columns, and the object-oriented model, which organizes data as objects in a programming language.

Table

In a relational database, a table is a collection of data organized into rows and columns. Tables are used to store data in a structured format, and each row represents a unique record, while each column represents a specific piece of information about that record.

Primary key

A primary key is a column or set of columns in a table that uniquely identifies each row in the table. Primary keys are used to ensure the integrity and uniqueness of data in a table.

Foreign key

A foreign key is a column or set of columns in a table that refers to the primary key of another table. Foreign keys are used to establish relationships between tables in a database.

Index

An index is a data structure that helps to improve the performance of queries by allowing the database to quickly locate specific rows in a table. Indexes can be created on one or more columns in a table.

Query

A query is a request to retrieve data from a database. Queries are written in a specialized language, such as SQL, and are used to search, filter, and manipulate data in a database.

Normalization

Normalization is the process of organizing a database in a way that reduces redundancy and dependency. Normalized databases are more efficient and easier to maintain than non-normalized databases.

I used to hear a lot when engineers were talking "but that denormalizes the data and that's not good". There are places where "denormalization" is helpful, but overall, because of the reduction in redundancy, engineers like it more.

Transaction

A transaction is a group of database operations that are treated as a single unit. Transactions are used to ensure the consistency and integrity of data in a database, by either committing all the operations in the transaction or rolling back any changes if an error occurs.

Let's call it a (sun)day and explore more concepts on Data in the following days!

What is your experience with working with Data? How comfortable are you with querying the data you need for your product? Let me know in the comments. 🙏🏻

Check today’s slides over here.

Yesterday, we walked over basic Mental Models for Saas products, and now we have a framework to refer to when talking about different technologies.

As a refresher, let's look at the first mental mode, a basic setup for a Saas product:

We have previously discussed:

1. Frontend Frameworks

2. and APIs.

Even though there is a lot more detail we can cover in the topics above, we first focus on having a good overall understanding of the systems, before a deep dive. For Product Managers as Generalists, "breadth is first, depth second." :)

What is the Backend?

One reason to start with Frontend frameworks is that they are easier to understand as they are tangible. You always see and touch them (via your mouse or your fingers when using touch screens).

Backend on the other hand is more "abstract". It's all the code running in a computer on the "cloud", namely called a "Server".

The Backend is responsible for handling the logic and data storage for the application. The backend is typically built using programming languages, and it is responsible for performing tasks such as storing and retrieving data from a database, processing business logic, and communicating with external APIs.

Together, the frontend and backend of an application work together to provide a seamless user experience and enable the application to perform its intended functions.

Note that in the definition above, the Backend is also responsible for storing the data, but for thinking about applications in a Modular way, I decided to separate them visually.

Well-known Backend Frameworks

There are many popular backend frameworks that are widely used for building web applications, each with its own set of features, history, pros, and cons. Here are a few examples:

PHP

PHP (Hypertext Preprocessor) is a popular programming language that is commonly used for building web applications. It was originally developed in the mid-1990s as a set of scripts that were used to create and manage web pages. Over time, it has evolved into a full-featured programming language that is used for a wide range of purposes, including building web applications, creating command-line scripts, and interacting with databases.

PHP has traditionally been a popular choice for building web applications due to its simplicity, ease of use, and wide range of built-in features. It is often used in combination with a LAMP stack (Linux, Apache, MySQL, and PHP, more explanation below), which is a common setup for building dynamic web applications. Many well-known websites, including Facebook, Wikipedia, and WordPress, have been built using PHP.

However, in recent years, other programming languages and frameworks have gained popularity as alternatives to PHP for building web applications. For example, Python, Ruby, and JavaScript have all become popular choices for building web applications, and frameworks such as Django, Ruby on Rails, and Express.js have become widely used for building web applications with these languages.

Django

Django is a high-level Python web framework that encourages rapid development and clean, pragmatic design. It was developed in the mid-2000s and has since become a popular choice for web development due to its emphasis on convention over configuration and its extensive set of built-in features. Django is used by sites such as Instagram, Pinterest, and The Washington Post. Some pros of using Django include its robust set of features, strong security measures, and ability to scale to handle high traffic. Some cons include a longer learning curve for those unfamiliar with Python and the potential for slower performance compared to some other frameworks.

💡

Another popular backend framework for Python is Flask, which we don't cover in this post. 

Ruby on Rails

Ruby on Rails is a full-stack web framework written in Ruby that is designed to make building web applications easier and more efficient. It was developed in the early 2000s and has become popular for its emphasis on convention over configuration and its use of the MVC (model-view-controller) architecture. Ruby on Rails is used by sites such as Airbnb, GitHub, and Hulu. Some pros of using Ruby on Rails include its simplicity and ease of use, a large and active community, and the ability to build applications quickly. Some cons include potential performance issues at scale and a smaller pool of developers compared to some other frameworks.

ASP.NET

ASP.NET (Active Server Pages .NET) is a web framework developed by Microsoft that is designed to build dynamic web applications using the .NET framework. It is written in C# and uses the MVC (model-view-controller) architecture.

ASP.NET was first released in 2002 and has since become a popular choice for building web applications due to its strong performance, support for a wide range of languages and platforms, and integration with other Microsoft technologies. It is used by sites such as GoDaddy and Visual Studio.

Some pros of using ASP.NET include its strong performance, support for a wide range of languages and platforms, and integration with other Microsoft technologies. Some cons include a steeper learning curve for those unfamiliar with C# and a smaller community compared to some other frameworks.

Express.js

Express.js is a minimalist web framework for Node.js that is designed to be flexible and easy to use. It is built on top of the Node.js runtime and is a popular choice for building web applications with JavaScript. Express.js is used by sites such as MySpace and AccuWeather. Some pros of using Express.js include its simplicity, flexibility, and ability to handle high traffic. Some cons include a lack of built-in features compared to some other frameworks and the need to use third-party libraries to add additional functionality.

Ultimately, the choice of backend framework will depend on your specific needs and requirements. Some factors to consider when deciding which framework to use include the programming language you are comfortable with, the type of application you are building, and the level of complexity and scalability you need.

What are Stacks then?

If you remember from Day 13, Tech Stacks, we defined a stack as:

Stack is the combination of technologies and tools that are used to build and run a web application. Different stacks are designed for different purposes and may include different combinations of technologies for the frontend (client-side) and backend (server-side) of the application.

Stacks are the combination of Database, Backend, and Frontend framework to build the application. Because some technologies work better or easier together, these acronyms were created to refer to them, just to name a few:

1. LAMP

2. MEAN

3. MERN

4. MEVN

We haven't covered Databases in detail yet, but bear with me, we'll get into that too. 😉

LAMP stack:

LAMP stands for Linux, Apache, MySQL, and PHP. It is a stack that is commonly used for building dynamic web applications. Linux is the operating system, Apache is the web server, MySQL is the database management system, and PHP is the programming language used to build the application.

MEAN stack

MEAN stands for MongoDB, Express.js, AngularJS, and Node.js. It is a stack that is used for building web applications with JavaScript on both the frontend and backend. MongoDB is the database, Express.js is the web framework, AngularJS is the frontend framework, and Node.js is the runtime environment.

MERN stack

MERN stands for MongoDB, Express.js, React, and Node.js. It is similar to the MEAN stack, but it uses React as the frontend framework instead of AngularJS.

MEVN stack

MEVN stands for MongoDB, Express.js, Vue.js, and Node.js. It is similar to the MEAN stack, but it uses Vue.js as the frontend framework instead of AngularJS.

💡 For a refresher on React, Angular, and Vue.js, refer to our post on Frontend Frameworks on Day 14 of the #adventcalendar. 

These are just a few examples of different stacks that are commonly used in web development. There are many other variations and combinations of technologies that can be used to build web applications, and the choice of the stack will depend on the specific needs and requirements of the application being developed.

Did you learn new aspects of Backend frameworks? Share what else a Product Manager should know about backend frameworks in the comments below.

Check the slides for Backend frameworks over here.

Yesterday I mentioned that I'd like to take a step back from different technologies and details and look at the big picture of digital and SAAS products.

The benefit of having a mental model for us Product Managers is countless, in the next section, let's get deeper into it.

Importance of Mental Models

Mental models are frameworks that help us understand and make sense of the world around us. They are simplified representations of complex systems, e.g. how Uber, HelloFresh, Miro, or Amplitude work in high levels.

They allow us to process information more efficiently and make better decisions. Mental models are essential for problem-solving and decision-making because they help us to break down complex issues into smaller, more manageable pieces and to identify patterns and relationships. Two tasks that Product Managers do constantly.

Using mental models can help us to:

• Understand and analyze complex systems

• Make informed decisions

• Identify cause-and-effect relationships

• Predict outcomes

• Solve problems effectively

Mental models are not always accurate, and it is important to constantly update and revise them based on new information and experiences. However, they can be a valuable tool for understanding and navigating the complex systems we are dealing with.

Different categories of Saas products

There are many different ways Saas companies and online service providers (who might not be necessarily Sass with a subscription fee) provide value to their end customers.

In this post, we will cover 3 common and simple methods, at a high level.

Notes to keep in mind:

1. We are covering technical setup for the value delivery done by the product. The company might have other products and services that are valuable for the company, but that's for another post to cover. Such products and services can be Physical products, Access to the customer base, initial training, support, and consultants, ...

2. Last disclaimer, the world of IT and technical setup are quite complex, and I didn't find any other post around these mental models. These are only simplifications and there are many more innovative ways or even a mixture of the base models in the real world. Ping me if you have seen such categorization or have an idea about new models that I haven't covered.

The three mental models we'll cover are:

1. Simple Saas model

2. Simple Mobile application

3. Simple Data Provider Company.

Okay, enough with the intro, and let's get into it! 😎

1. Simple Saas model

Database, Backend, and Frontend.

In this common setup, the application consists of the following main pieces:

1. Frontend

2. Backend

3. Database

4. A way for Frontend to talk to the Backend

And that's it, almost.

As you can see, even this simple mental model, can help us understand what we mean by different frontend frameworks (as in Day 14) or where API is used.  

General comments about this setup:

1. The end user can be divided into several groups which are ignored in this simplification. An example can be Amazon, where the "DB-Backend-Frontend" for Sellers and Buyers can be quite different (even though they share a lot of resources).

2. The communication between Frontend and Backend doesn't necessarily need to be API, but it's chosen here because of its simplicity, and popularity. Other technologies such as GRPC and GraphQL can be used to connect different pieces.

3. We wrap the Database as generally as possible. Most of the time, the company's value is created by having proprietary data which is either produced by its other software or gathered from other producers. We'll dive into the Data side of things more in the future.

💡Note: Even though I haven't posted anything on GRPC, or GraphQL, but as soon as you know what they are used for, i.e. the communication between two different pieces of software, you are well ahead of many other Product Managers and "business" stakeholders. So kudos to arriving to this point! 🥳

2. Mobile application model

Database, Backend, <a way to communicate with the app> and the Mobile app.

The second common model is of course model for Mobile applications. Even though it's very simple and looks quite the same as a normal web-based Saas company, due to the increase in popularity and impact, I believe it needs its section.

On popularity, first time in 2017 the traffic from Mobile devices passed the traffic from other devices, such as desktops and tablets, according to Statista.

1. The technologies for building Mobile apps were quite different from those for Web App development. Namely "Native apps" is the term used for developing platform-specific apps. With the introduction of cross-platform frameworks such as React Native, Flutter, and Cordova,... this gap is getting smaller but still, there is quite a difference.

2. Mobile has its strengths and weaknesses. On one side, mobile devices provide new capabilities that are not available in most desktops, such as GPS, easy access to Cameras, touch screens, ..., but on the other hand, screen size and stable connectivity might be a challenge in developing mobile apps.

3. Data providers

Databases, Backend, and APIs.

The last mental model for today is the Data provider model.

In the first model, I mentioned that the Database side might be more complicated than just the "database". One example is when the main data is provided by a 3rd party company.

An example of this setup can be Trading apps, where the Price for Stocks and Bonds are provided by Market Data Providers, and the "app" is only an interface to show the data nicely.

If you are working on a Data provider or API products, your end product is not a Web-based app or a mobile app, but it's the data and the APIs (plus its documentation, authentication, and authorization) that are your product.

Note that your customer can be an internal team too.

A popular example of API companies is Stripe and Open Weather App.

And that's a wrap for today.

What do you think about these mental models? What are your favorite models that helped you a lot in your life and career so far?

As always, you can check the slides for this post over here.

If you have been with me in the last 14 days, you've seen quite a lot. We have touched on interesting technical concepts that are useful for Product Managers in understanding what their team is going through and why things are the way they are 🤓. More specifically, we touched upon the following concepts:

• Day 1: What is a REST API?

• Day 2: Webhooks, why we use them, and how they are different than APIs.

• Day 3: Microservices vs. Monolith architecture, what are their pros and cons, and when we should use each architecture?

• Day 4, 5, 6: We talked about Git, and how its shared repositories allow engineers to work on a single product in scale. As I said in the material, I believe it is the most underlooked technology piece because everything we have around us is partly thanks to having Git. (bold statement but I think so)

• Day 7 and 8: DevOps, what it means, and why we have it. (do you still remember? 😉)

• Day 9: Engineers, and their many many different types 👷🏽

• Day 10: Environments and stages: A newly developed feature goes from a developer's laptop (local machine) up to the production environment.

• Day 11 and 12: Feature Flags, and how we can control who can see the new feature we are launching (and why we might roll it out that way).

• Day 13 and 14: Tech Stacks, how they are similar to Lego pieces, and how knowing them can be helpful for PMs. Also yesterday we went deeper into popular Frontend frameworks, talking about React, Angular, and Vue.js.

It's a good base so far. I planned to publish the Backend frameworks for today, but in today's post, I want us to take a step back and look at the big picture.

How these different technologies and concepts are fitting together, will help with understanding any other concept much easier.

The next post will be about the Technical Map of Digital Products, as best as I can, with as much as I have experience with. Like any other map, No map is perfect, but it needs to be good enough to help us navigate our way. And I hope it will be a good enough map to start with. You can see a preview of it below:

Take care and see you tomorrow!
Love you 💌

In the first part of the series on Tech Stacks, we talked about how they are like pieces of Lego and why general knowledge about them is helpful for Product Managers.

In today's post, we'll cover popular front-end frameworks and some key features about them.

Before we jump in

If you have noticed, not only do I want to describe the concept we are talking about (the "What"), but I would like to give an idea of the "why" we need them in the first place too.

This way, you can remember knowledge for a longer time as well and when faced with a new instance of the same concept, in this case, a new web framework, you will grasp it much easier and independently.

Recap on what is a software development framework

Software development frameworks provide a set of tools and standards for developing software applications.

These frameworks can help simplify the development process by providing a common structure for the code, as well as pre-built modules and components that can be used to implement common functionality. This can save time and effort for developers, and can also help ensure that the resulting software is more consistent and maintainable.

Some examples of software development frameworks include Ruby on Rails for web applications, Angular for front-end web development, and TensorFlow for machine learning.

Frontend Frameworks

Keeping the quest for the "why" in mind, let's explore briefly why we need a front-end framework in the first place. Why not simple HTML, CSS, and Javascript not enough to build modern web applications?

The What

Frontend frameworks are used to facilitate the development of user interfaces for web applications. These frameworks provide a set of pre-written code and tools that can be used to build user interfaces that are consistent, responsive, and easy to use.

Pre-framework era

It's a very rough division, but let's go back to the time when using frameworks was not common among developers, either they didn't exist or they were too young and companies haven't had the chance to migrate or create a new application based on them.

Before the existence of front-end frameworks, developers had to build user interfaces from scratch, which required a lot of time and effort. This often resulted in user interfaces that were difficult to maintain and scale, and that lacked consistent design and functionality. In short, a lot of headaches and a very long time to market.

It is also worth looking into the design of popular websites back in, let's say 2005. I'll let you explore them by yourself here:

Web Design MuseumWeb Design Museum

Or this gold mine of Best websites according to Time in 2005.

With the advent of frontend frameworks, developers can now build user interfaces more quickly and easily by using pre-written code and components provided by the framework. This can help to improve the consistency, responsiveness, and overall quality of the user interface.

It can also make the development process more efficient, as developers can reuse and extend the components provided by the framework instead of having to write everything from scratch.

As a result, frontend frameworks have become an essential part of modern web development.

If you remember from Day 9, we talked about the website that surveys different Javascript frameworks and technologies, called State of JS.

Now let's look into the popular frameworks for Frontend and explore them. We have to rely on 2021 data because the survey for 2022 is ongoing.

💡 If you are a software developer, head to the survey to provide data 🙌🏻

1. React

2. Angular

3. and Vue.js

Also, note the rise of Svelte in the charts. I'm very curious about the results for 2022 🧐. You can get a hint from the trends on StackOverflow too:

React

React is a JavaScript library for building user interfaces. It was created by Meta (Facebook back then) in May 2013 and is used by many companies and developers to build web applications.

React's core concept is the use of components to build user interfaces. In React, a component is a piece of code that represents a part of the user interface, such as a button or a form. Components can be reused and composed to build complex user interfaces, which makes the development process more efficient and modular.

One of the main reasons to use React is its efficiency. React uses a virtual DOM (Document Object Model) to update the user interface, which makes the process of rendering components to the screen faster and more efficient. This can help to improve the performance of web applications, especially those with large and complex user interfaces.

Another advantage of React is its flexibility. React components can be used in different contexts, such as in a web browser, on a mobile device, or on a server. This allows developers to build applications that can run on multiple platforms, and to reuse components across different projects.

Some potential drawbacks of using React include its steep learning curve and the need to write code in JavaScript or Typescript.

React also has a large ecosystem of third-party libraries and tools, which can make it difficult to choose the right ones for a given project. Overall, however, React is a popular and powerful tool for building user interfaces and is widely used by developers.

Components in React are written in .jsx or .tsx (if using Typescript) and it looks like this:

function Welcome(props) {
  return <h1>Hello, {props.name}</h1>;
}

function App() {
  return (
    <div>
      <Welcome name="Sara" />
      <Welcome name="Cahal" />
      <Welcome name="Edite" />
    </div>
  );
}

Angular

Angular is a JavaScript framework for building web applications and apps in JavaScript, HTML, and TypeScript. It was created by Google, kinda a competitor for React. Note that what we refer to as Angular nowadays is a successor to AngularJS (or more specifically AngularJS Version 2.0 and onward which was released on October 2014 is renamed to Angular, due to its huge overhaul).

The core concepts of Angular, just like React, include components, directives, and services. Components are the building blocks of Angular applications and are the most basic UI elements. Directives are markers on a DOM element that tells Angular to attach a specific behavior to that DOM element. Services are reusable pieces of code that can be injected into different components to provide specific functionality.

One reason to use Angular is that it allows for the creation of reusable components, which can make development faster and more efficient. Additionally, Angular offers strong support for building complex, large-scale applications, and has a large and active community.

Angular uses ng-* HTML properties to connect code with HTLM elements. An example Angular code will look like:

<!DOCTYPE html>
<html>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.6.9/angular.min.js"></script>
<body>

<div ng-app="" ng-init="firstName='John'">

<p>The name is <span ng-bind="firstName"></span></p>

</div>

</body>
</html>

Vue.js

Vue.js is a JavaScript framework for building web applications and user interfaces. It was first created in February 2014 by Evan You, a former employee of Google who used Angular in several projects.

The core concepts of Vue.js, like Angular and React, include components, reactive data binding, and the virtual DOM.

Reactive data binding means that when data in the application changes, the user interface updates automatically. The virtual DOM is an in-memory representation of the actual DOM, which allows Vue.js to update the UI efficiently by only changing the parts of the DOM that have actually changed.

One reason to use Vue.js is that it is easy to learn and use, especially for developers who are already familiar with JavaScript. Vue.js also has a small size and good performance, making it well-suited for building fast, lightweight applications. Additionally, Vue.js has a strong focus on developer experience, with helpful error messages and a focus on making the code readable and maintainable.

Some potential drawbacks of using Vue.js include a relatively small community compared to other JavaScript frameworks, which can make it harder to find support and resources. Additionally, Vue.js may not be as well-suited for building large-scale, complex applications as other frameworks like Angular.

In comparison to Angular, Vue.js is generally considered to be easier to learn and use, with a shallower learning curve. Vue.js also has a smaller size and better performance than Angular. However, Angular has a larger and more active community and may be better suited for building larger, more complex applications.

In comparison to React, Vue.js and React have many similar features and capabilities. Both use components and a virtual DOM, and both have strong performance and a focus on developer experience. However, Vue.js has a more straightforward and intuitive API, which may make it easier to learn and use for some developers. React, on the other hand, has a larger community and a more robust ecosystem of third-party libraries and tools.

Comparison and Summary

In the end, React, Angular, and Vue.js are all popular JavaScript frameworks for building web applications and user interfaces. All three frameworks have their own strengths and weaknesses, and the best choice for a particular project will depend on the specific requirements and use cases.

React is a good choice for building complex, large-scale applications, and has a large and active community. It is also well-suited for building applications that will be used on different platforms, such as web, mobile, and desktop.

Angular is a good choice for building large, complex applications, and has a large and active community. It offers a powerful set of tools and features and has strong support for building reusable components.

Vue.js is a good choice for building lightweight, fast applications, and has a focus on ease of use and developer experience. It is also a good choice for developers who are new to JavaScript frameworks, as it has a relatively shallow learning curve.

Overall, the best choice of the framework will depend on the specific requirements and use cases of the project. A developer should consider factors such as the size and complexity of the project, the desired performance and scalability, and the availability of resources and support from the community.

What do you think about Frontend frameworks? Which one are you using in your company?

Let me know in the comments below or reply to the email.

Get the full slides for this post over here.

Or What my engineer means when she says:

"I need more time because the new project is in React."

What is a Tech Stack?

Software development has increased in complexity and variety over the past few years, let alone decades.

All the new libraries and frameworks are created to satisfy a special need or improve on an existing one. All of these helped to build …

Read more

Recap on Feature Flags 1

Yesterday we learned that by using Feature Flags (FF) we can control how a piece of our software, or a product feature will be distributed among our users.

We talked that we may want this because of:

• Rollout released in stages

• Compare two variations at the same time (e.g. in A/B tests)

• The feature is temporary and is relevant for a portion of users (e.g. Alert boxes, Reminders, ...)

Any standards?

Depending on what you want to do, Feature Flags' design and implementation can be straightforward or a nightmare.

Even though there are several tools and services that provide A/B testing and Feature Flags functionality, integrating with them and their cost are hurdles in their adaptations.

So most of the FF systems I worked with, were implemented in-house (and that works well, thanks to very talented engineers who worked on it).

Best Practices

I'd like to touch on some practical aspects of Feature Flags that I learned over the years using them in production.

Server-side vs. Client-side FF

Most of the tools I am going to mention in the next section are helpful for Client-side testing. But what is Client-side FF and how they are different from Server-side?

Client Side Feature Flags

... are done by placing a cookie on the user's browser to determine which variation of the test to show them.

It's mainly useful for testing on Landing pages and websites where there isn't any login required to see the page or content.

Server Side Feature Flags

Whenever you need to play around with features behind a login, for users, things get more interesting.

In these cases, a simple cookie will not help anymore and your app needs to read the flags from your server (the backend, or your FF management provider).

In this case, having FF management (either developed internally or from a 3rd-party provider (3pp)) is more important. Using this tool, you want to have these functionalities:

• Create a new feature flag and see a list of all active/inactive ones.

• Assign users (or customers, if you are in B2B) to it in several ways, such as: At random based on a %, predefined. customers based on a property (email, location, ...)

• Enable or disable it with ease. (make sure your software handles the edge cases).

• Some fancy 3rd party tools also provide tracking and reports on the feature flag (how many users/customers saw it, ...) but this is not a must. You can track this better in your own Tracking plan (topic for another day). It's more of a nice-to-have.

All of this helps you to be independent of the engineers and modify the App's functionalities based on the real-time data, with a toggle of a switch, rather than a new code deployment (and going through all the 3-4 environments, remember Environments?)

Remember that you would still need the newly created feature flag to be in the code, so initializing a feature flag on the dashboard is not enough. But after your engineers insert it in the right place in the code (see the code example below), you can control the feature from the dashboard.  

Flags should Enable functionalities

Even though feature flags are simple boolean variables, it's important to use them as "enablers" and not disablers.

This is especially important as you move to Server-side FF because there might be a lag while getting the FF from the server or even a bug in FF implementation (a small typo for example), and in these cases, the software needs to default to the standard features, not the experimented ones.

Let me give an example:

Let's say you just finished developing a fancy new widget on the dashboard of your app and you want to roll it out for 10% of the users if it is working well, and is useful for the users, and ... (all the product usability things).

You can do this in two ways, logically:

1. Enable the widget for selected users (what you should do)

2. Disable it for the users who are not selected (oh no 🙈)

In this case, you should opt for naming and default values in the following way (in pseudocode):

// default value if for some reasons, ff_manager is not working or the variable doesn't exist

if (ff_manager.show_new_widget(user_id, default = False) ){ 
    // insert the new widget
} else {
    // do nothing :)
}

Be careful of conflicting feature flags

If you are running lots of A/B tests and are not careful with defining the scope of Feature Flags, your end data may not be very reliable, depending on how the code is implemented.

This is more of a nuance in the implementation detail, but keep an eye on it and go through it with your engineer to make sure the feature flags are working as expected.

Tools and software

As I mentioned before, I've only used internal implementation of Feature Flags functionality but during the implementation and discovery, I've checked a few providers that are worth mentioning. With a simple Google search, you can find many providers. Some have public pricing, but others require contacting their Sales team to get a quote (which is very annoying IMO.)

⚠️ Disclaimer: I'm by no means sponsoring or promoting them. Your own due diligence before purchasing or integrating with them is required.

These tools are:

• Google Optimize (https://optimize.google.com/)

• Firebase Remote Config, also by Google (https://firebase.google.com/products/remote-config)

• Optimizely (https://www.optimizely.com/)

• VWO (https://vwo.com/)

• LaunchDarkly (https://launchdarkly.com/)

• Statsig (https://statsig.com/)

• Flagship (https://www.flagship.io/)

• Feature Flag by Split: https://www.split.io/product/feature-flags/

• CofigCat (https://configcat.com/)

References

Some good articles and resources I came across while I was researching Feature Flags:

1. Feature-Flags (https://www.feature-flags.net/)

2. A great article by JOSH PITZALIS on nitty-gritty details of Feature Flags: https://usabilitygeek.com/a-b-testing-the-words-in-your-product/

3. All the tools above :)

Slides for today’s post

Here is the slide for today’s post.

Or What my engineer means when she says:

Do you want to release our <big feature> incrementally with feature flags?

Yesterday we talked about different environments our app is running on, mainly:

1. Development environment (env).

2. Testing env.

3. Staging env.

4. and Production env.

What if Prod is not enough?

Now imagine you have a feature that works well on testing and staging environments but:

• it's so big that you don't want to release it to everyone yet or

• is just an idea and you want to gather feedback from real users or

• is a variation of the current design and you want to compare its performance before enabling it for everyone

• is only relevant for a portion of users (based on location, products they bought, membership type, behaviors, ...)

or many more cases where you need to release a piece of code only to a portion of your users (either at random, e.g. 5%, or targeted, e.g. all users based in Germany).

You can achieve some of the above with an if/else clause in your code but what if you also:

• want to "track" their behavior as well, and

• in case it has any side effects, you want to "disable" the feature immediately and roll back the app to its previous version.

Well, feature flags are a software pattern to enable exactly these functionalities.

Feature flags are...

a software engineering technique that turns select functionality on and off during runtime, without deploying new code.

This enables teams to make changes without pushing additional code and allows for more controlled experimentation over the lifecycle of features.

In nature, they are still an "if statement", but the main keywords are, being able to do it in runtime, without deploying a new code, makes them more scalable and maintainable.

Let's keep today as an introduction for this lovely topic, especially if you are into A/B testing and incremental release, you'll love Feature Flags.

More on them coming tomorrow!

Check the slides for today’s post over here.

Or What my engineer means when she says:

Can you test it on Staging before I deploy it to Production?

We covered Git, Microservices, and DevOps. Let's add one more related concept on your journey to be a #hackerpm!

Welcome to software development environments.

Why different environments?

Between the development of software on an engineering laptop (the local environment) to the hands of users (the production environment), there are several more stages with slightly different purposes to ensure the code that is written on the "local machine" fully satisfies the requirements without breaking any other part of the product.

The most common environments in a software development lifecycle are:

1. Development environment

2. Testing environment

3. Staging environment

4. Production environment

Let's go through them one by one.

⚠️ Disclaimer: Different companies, depending on their need and restrictions might have a slightly different implementation of each environment or completely skip one.

Development Environment

The development environment is the first environment the code engineers have developed on their local machine deployed to and tested.

It's also used for:

• Feature previews

• Collaboration

• Proof of concept for a technical implementation/library

Usually, the development environment has only dummy data and is also more open to engineers to build, deploy, and test changes independently, without waiting for someone's approval.

Testing Environment

A testing environment is where the QA team can use a variety of testing tools to run all their different tests over the application code taken from the development environment. While developers check their code for simple bugs before passing it for quality assurance, QA engineers execute more complex and time-consuming types of tests to check the compatibility of the new and old code, the correct integration of different modules, the system’s performance, etc. Types of testing that can be done in this environment are:

• functional testing

• integration testing

• performance testing

• load testing

Staging Environment

In an ideal world, a staging environment is an identical replica of the customer’s production environment, which also typically contains real production data that’s been sanitized for safety purposes. It is hosted in the same way as the production servers and involves identical setup and update operations. Therefore, testing on a staging environment offers the most reliable way to check code quality and ensure the production servers are successful.

Another name for Staging Environment is Pre-Prod Environment.

Production Environment

The production environment is the final environment in your software development process. It is the work that is ready to be publicly available, and only the most thoroughly tested code should end up here.

It's what your users see and interact with. But there are some methods to test features, especially if you want to release a very big feature or validate the need for a feature, such as Feature Flags. More on that in the coming days!

Summary

⚠️ Disclaimer: Different companies, depending on their need and restrictions might have a slightly different implementation of each environment or completely skip one.

In today's #adventcalendar post, we will go through different titles among software engineers and developers and what each one of them covers.

We will talk about the following roles (first 4 are published now):

1. Frontend Engineer

2. Backend Engineer

3. Fullstack Engineer

4. DevOps Engineer

5. QA Engineer

6. Security Engineer

7. Mobile Developer

8. Data Engineer/Scientist

9. Game Developer

10. Embedded Software Engineer

11. Database Engineer

12. Network Engineer

Let's get started!

Frontend Engineer

One of the most common engineers you might have on your team is Frontend Engineers, or in short "FEs".

Frontend engineers are responsible to develop the visuals and experience of everything in your "web application". The 3 pillars of frontend development have been (and still are): HTML, Javascript, and CSS.

But due to many reasons (fit for another day), almost all of the new frontend applications use a "framework" that standardizes best practices and ways of working, gives some functionalities outside of the box, and opens up a platform of plugins to be installed instead of developing in house.

According to the "State of JS" survey for 2021, the following 3 frameworks are the most commonly used in 2021 (results for 2022 to be published next year).

1. React

2. Angular

3. Vue

Backend Engineer

Frontend software is the easiest one to explain because it's mostly all the things you see. But things get messier as you move "back".  Backend engineers enable other tools and software (including the frontend software) to interact with your core business logic and data.

They enable this by providing APIs for other systems and handling the business logic on the "Server" side.

Common backend technologies and servers widely used are:

• NodeJS

• Python

• PHP

• Ruby on Rails

• Server-side languages (Java, Ruby, or Python, .NET)

• API communication protocols (REST, SOAP, RPC)

• Databases (MySQL, MongoDB, Oracle, SQLServer)

• Servers (Apache, Nginx, IIS servers, Microsoft IIS)

And referring to the State of the JS again:

Fullstack

After covering "backend" engineers very briefly, we arrive at Fullstacks. It's easier to describe them after we covered FEs and BEs (backend developers) because:

They do both Frontend and Backend. Sounds like the best of two worlds, no?

But there is a catch.

Even though in theory they are doing both backend and frontend depending on the application, company needs, and even toolset and frameworks, almost always a full fullstack is either majorly an FE or BE (let's say 80%), and the rest is doing the other platform.

Fullstacks are very popular in the early stages of a company or an app since "one person" can do everything and halves the costs at least.

More on human resource optimization later!

DevOps Engineer

As a recap, DevOps ensure your development operations run smoothly, the code your engineers work on get merged into proper repository and branches, it is fully tested and is delivered to the correct environment (development, staging, or production).

You might think yeah we covered almost all engineer types you might have on your team, but I need to make a disclaimer that there are many more types. We haven't touched anything on Mobile developers (let alone native or cross-platform developers), Security engineers, Embedded software engineers, Game developers, Networking Engineers, Database Engineers, and many more.

Curious to know about these? Sign up (for free) and continue reading about the rest of the engineering roles.

In today's post, we dig deeper into what CI/CD means and the different tools around it.

📝 #task: Ask your engineer which CI/CD tool your company is using. They will be surprised by the question and your technical credibility with them will increase, which is very important to building trust with your team.

Also, today's post is special, because I included a cool startup that I met today at Techstars Demo Day, 1st batch in Stockholm, Sweden.

The startup that totally fits today's topic is Ankra (Techstars '22) (Ankra.io), which automates CI/CD and helps companies save a lot of time and resources. Glad to meet Benjamin Klingsbo and the team today.

Finally, if you want to receive these posts in your mailbox, please sign up for HackerPM's newsletter on our website 💌

Check the slides for DevOps - part 2 over here.

Check here for slides of DevOps - Part 1.