4 pieces of advice I give to PMs working on technical projects

If you’re a PM on a largely technical or backend project, you might be feeling all like 🤔 “what do I even do here”. Don’t worry, I’ve felt the same before. I want to share what have I learned (read: initially messed up, then figured out how to get right)? First and foremost:

Don’t go where you’re not needed

When I was working with two engineers on our team’s first machine learning project, I did what I normally do as a PM: research the space, try to understand how all of the systems would work and how they would fit together, etc. Turns out, going from zero to ‘useful’ in the world of ML is really hard. I found myself reading technical surveys and signing up for a online ML course. Then my boss pointed out to me that all I really need to know about ML is what it can and can’t solve for us — not all of the specifics about how it works. Case in point — the engineers that I worked with on this project were Chinese speakers, and so was the Microsoft Research team we were working with. Rather than worrying about being on those calls and being intimately aware of the implementation details, I asked the engineers — do you want to do the calls without me, that way you can all speak in Chinese?

The project was quite smooth after that.

Periodically validate the technical work from the perspective of an end user

When I was working on notifications at Imgur, I created a giant spreadsheet that listed out all of the rules for each notification. Would that notification trigger an email? Just a site notification? When would we send a push notification? It ended up being pretty complex. I held a review for us to go through it, and we clarified things that weren’t clear. After that, I left the engineers to work on the backend, and focused my time on other projects.

Unfortunately, about 90% of the work for this project would be backend work. And as a result, the engineers starting diving into the backend work first, and we worried about the UI later. Unfortunately, this resulted in some features that weren’t built right on the backend. At the end of the day, this was my fault. I ended up being too hands off with this project. The spreadsheet of rules was pretty massive, and I should have had the foresight to make sure we built the system iteratively.

This agile approach is what I’m using right now with my current team. We’re staging our features in such a way that we build features with a base set of features first, then add complexity later. This allows me to pull from our repo every day and constantly provide feedback.

You speak for the business, not just your users

Often times, technical decisions will have an impact on something other than end users — expenses, partner teams, partner companies, legal, etc. For example, if the engineering team is deciding between two different big data platforms, you may need to help your financial team decide if the shinier platform is an expense that you can handle as a company. You may also need to make sure that other teams within your company are onboard with moving to a different platform, as it may have an impact on their work in the future. This is where your role as a coordinator will be very much appreciated by the engineers.

Go ahead, ask your dumb questions. They’re not actually dumb.

When you’re working on a technical project and you have very little domain experience, it’s going to feel like you’re providing zero value. But at the end of the day, one of the greatest values that you may end up providing is asking the right questions. In order to ask the right questions, you need to ask a lot of dumb questions. When I first joined Microsoft as an intern, I was working on the team that handled the streaming and installation of Office (like a YouTube video, we actually let you stream Office to use it, even if it’s not installed on your computer). Before joining the team, I had a vague understanding that applications were stored in a “Program Files” folder, but I didn’t even know why there was a “Program Files (x86)” folder. In order to ramp up, I learned that asking questions during team meetings is actually okay, because about a quarter of the time, it helped other people on the team as well. I also started asking my mentor for 15–30 minutes of his time every day to go over questions that I had written down in my notebook throughout meetings or reading through documentation. Some of these questions ended up in deep discussions, and helped me plan the feature that I worked on.