“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.
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:
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:
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.
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:
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
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
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
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!
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:
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.
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.
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 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:
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.
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.
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.
Below are a few resources to help advance your tech knowledge.
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.
Similar to the above, these will give more in-depth guides on the latest technologies and features.
This is the best way to learn company- and industry-specific tech quickly in a cost-efficient manner (while building relationships!)
Here are some resources I have used myself or are generally highly recommended:
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
At its core, product lifecycle management (PLM) software is a tool designed to manage every aspect of a product’s lifecycle.
Scenario analysis is a strategic planning tool that helps you envision a range of possible future states and the forces behind them.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Learn more →
