Although there’s plenty of debate on this topic, product managers don’t need to be technical. A deep understanding of the programming languages, APIs, databases, software, and information architecture used to build and run a product isn’t essential to the job in most cases. Regardless of how helpful that knowledge may be. The non-technical product manager should understand a handful of technical concepts.

Product managers straddle development, operations, sales, marketing, and pretty much every other part of the business. We don’t ask product managers to be experts at creating invoices or running direct mail campaigns. However, they have to comprehend the basics and be receptive to the needs and concerns of stakeholders across the organization.

On a day-to-day basis, product managers inevitably come across jargon and concepts that require a certain level to be productive. A bit of fluency with the terms of the trade always expedites interactions with more technical colleagues. Moreover, it builds up your credibility within the organization.

With this in mind, it’s essential to identify which technical concepts influence a product manager’s ability to perform their duties. For the non-technical product manager, they need in their toolbox a grasp of certain technical areas. Can this understanding help them create clarity and provide guidance to those involved?

5 Technical Concepts for the Non-Technical Product Manager

Here are five technical areas worthwhile for the non-technical product manager to invest time in learning and development:

1. Agile

Agile isn’t particularly technical, but it represents the methodology and processes that most product development organizations now rely on. If you’re not comfortable and conversant with Agile concepts and language, you’ll struggle in your interactions with the team. Moreover, you may have difficulty landing many product management gigs.

Agile chunks product development into short bursts of coding called sprints, typically two to four weeks long. Developers tackle prioritized items during these sprints, which results in working code released as a product update.

This model of continually iterating with a more frequent cadence has two primary benefits. First, it delivers value to customers faster and more often. Second, it shortens the feedback loop. The subsequent learnings get incorporated into the next sprints. The results of which address any problems and improve customer experience.

Agile is light on documentation and leans more on short, regular meetings with the scrum teams, with product managers (or product owners) answering questions and clarifying requirements. Product managers working in Agile must familiarize themselves with its terminology, rituals, and expectations. They must also build good relationships with the developers, who bring the product vision to life.

2. Analytics

It’s a data-driven world, and we’re all just living in it. The non-technical product manager must utilize quantitative data in many aspects of their role. The data measures success to prioritize the contents of the product roadmap. No stakeholder wants to decide without the numbers to back it up.

A non-technical product manager needs to understand and manipulate data. A developed foresight requires proper instrumentation to collect that data in the first place. Knowing which product analytics you’ll want or need to know in the future lets product teams anticipate which product metrics must be tracked.

Google Analytics is the standard starting point for most product managers exploring analytics. Thanks to its ubiquity, ease of use, and unbeatable price point. Product management job descriptions now include an understanding of SQLs. Product managers can query the company’s databases to retrieve this information for themselves. This increasingly common requirement highlights just how paramount data and analytics have become.

Beyond knowing what data you want to be collected, figuring out where to find it, and understanding how to get it, product managers must know what to do with it once they’ve got it. If you’re lucky enough to have business analysts at your disposal, they’ll need explicit instructions. But if you’re on your own, Microsoft Excel skills—or Tableau or SAS—are a must to generate the stats and charts.

3. A/B Testing

When always striving to deliver the optimal customer experience, experimentation is critical to accelerating innovation by learning what works best. And while our user research helps us narrow things down, there’s nothing like customer feedback.

A/B tests allow product teams to test out their hypotheses in the real world. Whether it’s comparing something new to the status quo control group or putting out two different versions of a feature or UX to see which performs best. A/B tests swap guesswork and hunches for actual, measurable user behavior.

Marketing leverages this style of split testing. The same model applies to the product, which might test which ads get more clicks or which landing pages convert more often. From discovering whether a green button gets more clicks than a blue one to pricing experimentation to toggling on a brand new feature for only a subset of users. A/B tests limit the variables for an actual apples-to-apples experiment.

Depending on the nature of the product’s underlying technology, some A/B tests may not require coding support from the product team. Structuring the experiment, explaining its goals and requirements, then measuring and sharing the results, however, will always remain under product management’s purview.

4. Information Architecture

Understanding the building blocks of the technology stack and how those elements interact with each other is essential for product managers to have any credibility when collaborating with technical staff. Too many vital conversations require baseline knowledge of these systems and how they communicate for a product manager to remain blissfully ignorant.

Three-tier model

Let’s begin with the three-tier model, which has been around for decades. Here are the basics:

• The client tier encompasses the user interface and might be an app running on a mobile device, computer, or website. It could also be all three of those, each providing a slightly different user experience.
• One level down is the “application tier,” also sometimes referred to as the server. This is where the “brains” of the operation reside, including most of the business logic.
• Finally, there’s the “data tier.” This includes the database(s) housing all the backend info.

As a product manager, you’re primarily concerned with the client tier because those apps and websites are what users see and interact with. But those clients can’t do much without the supporting layers beneath, and those tiers are also home to most non-UI coding.

Application programming interfaces

Product managers should also be familiar with APIs (or Application Programming Interfaces). This acronym gets tossed about quite often, and for a good reason. APIs are how one app talks to another. They’re sometimes used internally—letting one system talk to another—enabling different parts of the product and underlying infrastructure. For example, the shopping cart on an app may use an API to query available inventory or pricing information.

But APIs also allow different businesses to communicate instantly by using this standard interface. When that shopping cart needs to calculate shipping information, it might use an API to get rates from FedEx or UPS before the customer checks out. From there, the API may enable shipping labels to be printed and generate tracking numbers.

Of course, today’s information architecture also often relies on the cloud for hosting some or all of the application and data tiers. Cloud computing enables businesses to scale quickly and not worry about running hardware and networking equipment on-premises or hosting facilities. But since cloud computing remains priced as a service, those costs can skyrocket with increased usage and storage, so product managers must be knowledgeable enough to factor those expenses into business models, ROI calculations, and project budgets.

The other element of information architecture that impacts product managers and their roadmaps is technical debt. Over time, different parts of the architecture need some dedicated maintenance or significant overhauls to improve efficiency and capacity. Being a little more familiar with this topic lets product managers better assess the urgency of these concerns and prioritize them accordingly.

5. Information Security

In our current era of rampant cybercrime, a non-technical product manager needs to understand how to handle data. They need to ensure that no information gets stolen, leaked, or otherwise mishandled. Given the high-profile nature of these breaches, thefts, and ransoms, product managers must be more familiar with this oft-ignored aspect of their products.

Product managers have a responsibility to ensure that user data is secure. Leaving this matter up to chance puts the product and business at serious risk.

Governing regulations

Regulations such as Europe’s GDPR (General Data Protection Regulation) and California’s CCPA (California Consumer Privacy Act) make mishandling of personally identifiable information (PII) a severe offense with hefty fines. Compliance with these rules lets users know what PII is being stored and requests that their entire record get deleted.

Not having this baked into the product can quickly escalate into a customer support nightmare. Additionally, if the product touches any medical data or supports financial transactions, the product must not run afoul of HIPAA, PCI, or other applicable regulations.

Securing the information architecture above is a must, including regular malware scans, keeping third-party software up to date, monitoring suspicious network traffic, and other preventative, defensive measures.

But product themselves have their security obligations. Ensuring that all data traffic is encrypted, using only HTTPS connections, limiting personally identifiable information collection and storage to the bare minimum, and storing it as securely as possible is just a sampling of the protective measures product managers must demand and prioritize.

Assessing your product vulnerability and proactively addressing any deficiencies is vital. And don’t forget about redundancy, disaster backup, recovery, and all the other good security hygiene best practices any business should aspire to. It may not be as fun as adding a new feature, but no product is exempt from investing in this area. Getting these critical items into the product roadmap falls to you.