Basic troubleshooting for non-tech PMs

Product managers without a CS background might find it daunting when faced with making decisions involving technical nuances.

I’ve had interest in hobby electronics for a while now. Unfortunately though - I’ve never had the heart to learn coding (in today’s app/web sense). This puts me squarely in the same box as all my fellow non-tech PMs out there - former designers, Ops/Sales/finance reps, business development execs & many more. Despite aggressively up-skilling to start their journey as a PM- what bothers most non-tech PM’s early in their careers is the lack of confidence when facing technical hurdles.

Now most of us have seen senior developers take a look at a bug/issue and after a few minutes of pause - breaking it down into smaller parts, its probable cause & possible fixes. To us non-tech noobs, it might look like sheer madness- but trust me, there’s a method to this madness.

In-case you’re enthusiastic about learning how to code (or a developer breaking into PMing), this in no way is meant to dissuade you. I cannot stress this enough - there’s no alternative to a hard skill like coding.

Let’s first lay the ground work -

Understanding how components on your product work/interact with each other

First, we’d need to get our heads around how features/components work on the product we’re dealing with. You might be working on an e-commerce or ride-hailing or ticket-booking product. These are complex products with hundreds of working components. Pick one to dive deep. Bring along a developer who can help you make sense of it all.

It’s not necessary to understand the inner workings of each tiny piece of a feature/component right away. You can assume complex sections or interactions to be a blackbox. All you need to know is “what does this blackbox do?” (inputs & outputs). Once you have understood the basic working, come back again to concentrate only on one of these blackboxes. This process can be repeated several times till you’re satisfied (or tired) of your understanding of this feature.

How to deep dive a common ‘Search’ feature

You’ll need to keep repeating this exercise with almost all major components of your product. You can gradually deep dive a combination of components to understand how two or more of them interact with each other.

🌟 One such example could be understanding how payment works on your product which can include internal (cart checkout) & external (payment gateway) components.

There are a few clear outcomes of this exercise

1. Step level understanding of the product: You can now think, understand & explain ideas & issues in terms of steps involved in a feature or component.

   🌟 An issue like “Payment failure” can now be more specifically described, say “there was no response from the payment gateway”. 

2. Understanding basic ‘blackboxes’: You’ll start to find that the same ‘blackboxes’ keep repeating in a lot of features you deep dive. And in the course of time, you’ll learn how a few of these work. This understanding will help you immensely when discussing solutions with engineers.

   🌟 One example could be “RegEx” - you’ll find this in all sorts of features like Phone verification or Chat moderation. Once you understand how it works, you can suggest it as a solution for a user problem- like preventing profanity in profile description.

Understanding limitations of tech/ services

It is fair to assume that all systems have limitations. So do the services & components built for the product. It is quite valuable to know & appreciate the underlying limitations of each. This helps when designing a new products or a flow- taking care not to put unwarranted strain on a legacy component OR not to expect unrealistic output of a an existing service.

🌟 Let’s say you’re writing copy for a receipt email to be sent out when users complete a purchase. You might want to include not only the total amount paid but also show the “math” of addition of each item, minus discounts, plus platform fee etc. But if you knew that your current legacy payment service calculates all these in run time (from all sorts of different tables) & stores only the final payable amount, you’ll likely not create such a requirement. Instead you’ll first discuss storing these details in a more accessible table so that later on it can not only be used for the emailing service but also reused for other products.

Troubleshooting

Now comes the ‘fun part’ - troubleshooting. There’s no bigger joy than to be able to look at an issue a user is facing & diagnose what might have gone wrong. Since PMs don’t fix bugs themselves - one might ask “what’s the use of diagnosing if someone else needs to fix it?” Well, realistically most issues have multiple possible solutions - each with it’s own pros & cons. And this is where a fair understanding of the issue might help.

There’s no silver bullet to this - but let’s try to take a shot.

• Has the issue occured on the Front-end(FE) or the Back-end(BE)?

  • The first step to any diagnosis is to roughly find out where’s it happening. Being able bucket an issue into FE or BE is a great start.

    🌟 It might sound simple - if the problem ‘appears’ on the screen it’s FE, right? Not quite. In-fact you need to know if the part you’re concerned about - say a typo on the booking confirmation button - is hardcoded within the application or is fetched from the BE via an API. The former is a FE, later is a BE. 

  • FE issues on apps usually cannot be fixed without rolling out a new build (which might take several days to a few weeks), whereas BE & Web FE issues can be fixed quite quickly (unless there’s something catastrophically wrong). This also means you can give estimates to the stakeholder pretty quickly- rather leave them hanging till the ticket it taken up.

• Asking the right questions

  • A “payment failure” issue could be attributed to one of several sub-components & asking the right questions help diagnose better - are all payment methods failing or a particular one? Is it failing on website, mobile app or both? Are several users facing the same issue?

  • Each of these questions help you & the developers get closer to the right sub-component where the issue might be occurring.

    🌟If the payment is failing only on the app but not on the website, one probable cause could be payment gateway SDK (Next we can ask - was there a recent update?)

• Understand long term consequences

  • The engineers might propose multiple solutions to fix an issue. It’s important to listen to each one of those and carefully weight the pros & cons.

  • Some solutions might be quick & dirty. Others could be reliable but might take longer. It’s the decision of the PM to either decide to fix it quickly or fix it properly.

  • Most quick fixes adds to the ‘debt’ that needs to be handled later down the line. Proper fixes take time and might also mean keeping your feature offline for a bit.

  • A controversial opinion could be not to do anything ‘bout it if the issue is traced to a legacy service and affects a small user segment. Rather, make way in the roadmap to properly fix it. Engineers will bless you for it.

The aim here is to develop enough know-how of working components, issues & possible fixes that one might start to get intuitive about it.

At the same time, never mistake this intuition for core competency (even if you know how to code). Make sure never to step on the foot of the engineers & start pushing your solutions. Stay humble.

Example

Here’s a real life example.

The background: At Carousell in Singapore & HongKong we have a feature that allows sellers to link their WhatsApp to their product page (this is different from account registration) to chat with buyers. This requires the sellers to verify not only their phone numbers, but also confirm that there’s an actual WhatsApp account linked to it. For this we use a third party to deliver OTP as a WhatsApp message. When a seller is registering for a new account though we send an OTP via SMS (more versatile).

The reported issue: A few sellers complained that they are getting an error “Invalid mobile number” when they try to request for an OTP. Interestingly they were able to successfully request an OTP via SMS during account registration using the same phone number. Another weird fact is that most sellers facing this issue are senior citizens.

How’d you troubleshoot this? Comment below ↓

Thank you for reading! You can also download the visual version of this article here