The PM's intro to Logging

Hey y'all, it's Irene here👩‍💻

..with today's issue on the PM's intro to Logging.

Why logging? Well, I talk a lot about one of core skills of technical literacy: broad awareness of the availabilities in technology and how we can use them in creative ways to solve product problems. Logging is another one of these availabilities in technology.

In fact, there's been a couple of instances in my time as a dev where logging was a solution to a problem but the dev team struggled to communicate the solution to our PM (I share this story below).

So here's a breakdown of this issue:– A lowdown of logging (including example log files)– How does logging affect my role as a PM?

TLDR; I get it–you're busy. If you don't want to slosh through this entire issue, I recommend at least reading the "The Lowdown on Logging" and "How does logging affect my role as a PM".

Connect with me on LinkedIn and Twitter and follow Skiplevel on LinkedIn!

Read my Twitter thread (and follow me!) for a quick and effective way to improve empathy and collaboration with your dev team

A PM's intro to Logging

The Lowdown on Logging:

Logging is an essential part of software development and no app is deemed "shippable" until proper logging is setup. So yes, that timeline you're working with developers on includes the time they're spending setting up logging.

Logging allows your team to monitor what's happening in your app, and how your application is being accessed and used. In programming, logging means to record in real-time an application's information, system performance, and/or user activities into detailed "log files".

Without logging we're essentially shipping a piece of software blind without any visibility into the health of the application and system once it's live. And this is a big no-no because what if critical bugs happen? Or leadership wants to know when peak traffic is, and who your visitors are?

If logging is done well, it allows your team to quickly debug errors, and get business insights around visitors and how the product is being used.

Sounds stalkerish...... tell me more!

The process of logging processes different log files based on what info is being recorded. These log files are organized into dates and hours and then stored on server(s) somewhere. It's up to the developer's discretion which log files a system should create, but there are 3 basic log files every system should have: access logs, debug logs, and system logs.

Access logsAccess logs allow us to monitor who is accessing your app and what is being accessed. This can provide us with important business insights like the demographic of users, and peak app usage.

Debug logsDebug logs are exactly what they sound like - they help developers debug errors and in general provide information about what's happening or clues to why an error happened. Typical debug log files label each log entry based on the criticalness of the information: INFO, WARN, ERROR, FATAL, DEBUG (See example below).

System logsSince all applications are built on top of an operating system, it's important to also monitor the health and status of the OS via the system log, or syslog. System logs log everything from OS startup, failures, errors, restarts, and shut downs.

How does logging affect my role as a PM?

Logging affects your product and role broadly in 3 ways:

 – Increased product timeline
– Improve time to fix critical errors
– Source of information for business insights

Increased product timeline

The most obvious way logging affects your product roadmap is the time and energy it takes for dev teams to implement logging–a process that includes setting up infrastructure, deciding what info and how to log, how to store log files, and how to access logs. Because logging is essential to building software, there isn't really a way around the added timeline.

However, allowing devs enough time to set up logging properly can save valuable time in future iterations of the product and later parts of the software development lifecycle (SDLC).

Improve time to fix bugs and critical errors

The first step developers will take to debug errors is figure out where in the code or system the error is happening and what the root cause of the error is. In order to do this, developers will narrow their search to specific log files to get a picture of what the system was doing at the time of error. If log processes are not set up efficiently, the time to fix bugs and critical errors is higher affecting your company's bottom line and customer satisfaction.

Source of information for customers and business insights

Log files are a treasure trove of information about customers and this information can often be used to solve business and product needs.

Here's a real-life example from my time as a dev: I recall an instance when I worked on the internal documentation software at Amazon where logging was a solution to a business critical need. Amazon's security policy had changed and the policy critically affected Windows users. The change required action on the part of Windows users who used our product within a specific time frame. In order to comply with Amazon's policy change, our product manager needed to reach out to these affected users. The only way for us to identify the users affected was for us to query access log files. In this situation, communicating with our product manager about the solution and the complexity it involves was difficult since our PM had little knowledge of logging or software maintenance practices.

The bottom line

I often talk about how product requirements affect technical requirements as much as technical requirements affect product requirements, and logging is just another example of this reality.

While you don't have to understand the specifics of the technical details of logging implementation, it's important to know what it is and add it to your toolbox of available technologies for solving product problems.