Understanding tech basics for non-technical product managers

“Hey PM! The frontend is failing at the login step. The API service is broken and sending a 4xx response code.”

As a PM, you’ve surely heard something similar from a developer in response to a customer support ticket or while debugging a feature.

But what’s all this jargon? Frontend? APIs? Why are they important? In this article, we’ll go over basic (but important) tech terms and processes that you need to know as a non-technical product manager.

Why having a good grasp of tech is important as a PM

As a product manager, you will be conversing a lot with tech or engineering teams on a day-to-day basis. This can be for several reasons, take a new feature launch or a bug found in an existing feature, for example.

A few main reasons for having a basic understanding of how tech works in general (and specific product features you own) are:

1. More informed conversations with tech: this understanding enables you, as a PM, to go deeper. You’ll be able to understand the feasibility and timelines of the tech tasks or features teams are proposing, as well as associated challenges. Ultimately, you’ll be able to better empathize with the tech team
2. Reduced dependence on tech: while I am not suggesting that a PM can start solving software bugs or coding, this helps in areas such as basic debugging of customer issues and testing in-development features
3. Stakeholder management: as a PM, you will usually be bombarded with requests from various other teams, such as customer support, business, and operations. Having an enhanced knowledge of the technology allows you to better manage their expectations and anxieties up front
4. Keeping up-to-date with the latest technology: the post-COVID adoption of technology has increased rapidly, leading to digital disruption across industries. Thus, a key part of your role as a PM is to stay updated with the latest tech trends in your industry, as well as other applicable industries, and see how they can be implemented internally if required

How a tech team is organized in a product-led company

Typically, in a product-led company, teams are divided into smaller pods. They could potentially be organized by the customer acquisition funnel stages, such as awareness, acquisition, activation, etc.

Further, each pod will have members from different departments, including tech, design, product, and business so that each one can almost function independently.

Talking specifically about the tech team, it consists of members with different skill sets:

• Frontend (FE) engineers: as the name suggests, FE means anything that is user- or customer-facing. FE developers work on aspects that users directly interact with. For example, a Submit details button on a website or app, built using coding languages like JavaScript, CSS, and HTML
• Backend (BE) engineers: while customers only see the frontend aspect, a lot of things happen in the background. Continuing with the earlier example of a user clicking Submit details on the website, BE engineers work on what happens once the user clicks that button. For example, a log is created for that specific user in a database along with their details, and maybe even triggers a welcome email. Thus, they are involved in areas like data storage, databases, APIs, and other server-side functions. They are masters in programming languages such as Python, Ruby, PHP, and Java
• Full-stack engineers: in short, they can work on both frontend and backend tasks, i.e. the full stack. They know the programming languages needed for both sides
• Quality assurance (QA)/testing: QA engineers test a feature once it is developed, working in collaboration with both frontend and backend developers to ensure the feature works as envisioned and is bug-free
• Engineering manager (EM): this is more of a managerial role and is mostly a senior FE/BE/full-stack developer who has risen through the ranks and now manages the tech pod. As a PM, t is extremely important to have a good rapport with the EM to ensure that your features are prioritized in upcoming sprints and that you get the resources needed

How does the software development lifecycle work?

Now let’s take an example to understand the software product development lifecycle.

Suppose you are tasked with creating a sign-up/registration page for customers. You’ve done the hard work of speaking to users, understanding their challenges, defining and sizing the problem (need for sign-up page), writing the PRD, and developing the designs in collaboration with the design team. Now, you hand it over to the tech team for implementation.

Initially, FE and BE engineers will take up their respective parts for creating the sign-up page. Post writing the code, they will do some sanity testing to see if everything is working fine. After that, QA engineers take up the integration of the frontend and backend and do complete end-to-end testing.

As the last step, a product demo is scheduled with all stakeholders, including product and design, to showcase that the sign-up flow is working per expectations and that there are no bugs, before being released in a planned manner.

Types of meetings with tech teams

Tech is the most critical function and the backbone of the company. PMs may fantasize about new features all they want, but without a tech team to ship them, may the force be with you!

The main meetings are:

Backlog grooming

Duration: 45–60 mins; weekly (or every two weeks)

Key stakeholders: engineering manager

Objective: PMs provide a view on tasks expected in upcoming sprints while getting a sense of the tech feasibility of proposed jobs

Pre-sprint planning

Duration: 45–60 mins; every two weeks (or as per sprint frequency); ideally a few days before the next sprint begins

Key stakeholders: senior folks from engineering; other PMs

Objective: prioritization of suggested tasks for the next sprint

Standup

Duration: 30–45 mins; daily

Key stakeholders: engineering manager

Objective: developers/QAs provide quick updates about task progress in the current sprint (a two-week block), request support if needed, and share revised timelines

Retrospective (retro)

Duration: 45–60 mins; every 4–6 weeks

Key stakeholders: senior product leaders; other PMs; tech EMs

Objective: identify positives and improvement areas over the past 4–6 weeks from a product lifecycle perspective, gaps to be addressed, key learnings, and best practices. All with the goal to keep improving iteratively!

Commonly used tech terms

If you’re a non-technical product manager, understanding tech jargon is going to feel daunting. Based on a survey I conducted of recently-graduated PMs, the following are some key tech terms a PM needs to be aware of:

Tech stack

The selection of technologies that a company uses to build and monitor its products. It is also called the tech infrastructure or solution stack. Usually, it will include frontend/backend tech, programming languages, frameworks, and databases.

Agile

A method of software development where a particular task is broken down into smaller chunks, completed in a time-bound manner and an iterative fashion. It allows for faster development and enhanced collaboration between cross-functional teams to course-correct before the entire product gets developed.

Backlog

A running list of previously-discussed features and requirements that are yet to be prioritized and executed by the tech team, usually due to bandwidth constraints or other higher-priority tasks.

APIs (application programming interfaces)

APIs allow a requester (or client) access to certain information from a provider (server). This information can be stored internally in another database or externally with another vendor.

A simple analogy would be a customer (client) going to a restaurant (server) to order some food. Here, a waiter acts as an API — they provide the menu (information from the kitchen), take the order (information from the customer), convey it to the kitchen, and then serve the final dish to the customer.

A few more terms related to APIs:

• Latency: the time between when an API gets a request and when it returns a response
• Response time: the total time it takes for an API to receive, process, and return a response
• Endpoint: a digital location (usually a URL) mentioned by the requester that indicates where the requested information is available

Microservices

A method of software development where the software is broken down into small, or “micro” services that are independent and communicate with others through APIs.

Their failure doesn’t affect other services. This approach allows the application to scale and develop faster.

It is in direct contrast to monolithic architecture, where all processes are combined and operate as one service. Here, the downside is that if even one process gets a spike in demand, the entire service needs to be scaled, leading to increased complexity and dependencies. Further, failure in one process may cause the entire application to fail.

Regression testing

A type of software testing done to ensure a new feature or bug fix does not impact existing features/functionality of a product. Usually, it includes checking for a known bug (discovered in previous versions) in all subsequent iterations.

Sandbox

A separate, secure environment where code can be tested before it’s released to a more extensive set of users — where it can have a significant negative impact if there are bugs.

Sandbox includes a development server and a staging server, largely similar to the production environment. This ensures that if a new piece of code works fine in the sandbox, there is a high likelihood of minimal issues in production.

How to improve your tech knowledge and stay updated as a PM

Below are a few resources to help advance your tech knowledge.

(Mostly) free resources

Social media

Such as Twitter, Youtube, LinkedIn, and podcasts. Follow the top product/tech leaders in your industry and overall to stay aware of the latest tech trends and terminologies.

Industry-specific publications and general tech or PM blogs

Similar to the above, these will give more in-depth guides on the latest technologies and features.

Experienced PMs and engineers within your company

This is the best way to learn company- and industry-specific tech quickly in a cost-efficient manner (while building relationships!)

Paid or other resources

Here are some resources I have used myself or are generally highly recommended:

• Product School has an excellent YouTube channel that regularly features talks by experienced PMs on myriad topics. It also has several free resources including e-books and paid certifications
• Books that I highly recommend are Swipe to Unlock and Tech Simplified for PMs & Entrepreneurs
• Tech newsletters such as TLDR and HackerNoon
• PM leaders like Shreyas Doshi, Deb Liu, Lenny Rachitsk, and Shyvee Shi

Conclusion

A solid understanding of tech basics is essential for PMs to be successful in the long run — it helps build strong relationships with tech and other stakeholders and adapt quickly to relevant digital disruptions in the industry.

The concepts and guidelines mentioned in this article should definitely give early PMs a leg-up over their competition in developing value-added features.

Featured image source: IconScout