In this post, I’ll offer my idea of the sort of technical abilities expected from a product manager. This can be highly useful for hiring managers, as well as for PMs planning their roadmap.

Guy Barner

here’s been so much written, including by myself, about product management interviews. It’s common to find interview questions regarding product design/product sense, prioritization, and UX (the links are my takes on it). But is a surprisingly small amount of materials about the technical aspect of PM work.

This is actually not surprising; throughout many discussions I’ve had with Senior and Junior PMs, technical skills are the one field that seems to be in disagreement. I’ve heard opinions ranging from ‘A PM should be at least a junior developer’ (only true for highly technical products), to some people actually claiming that ‘a PM should not know anything about development, otherwise they’ll clash with dev (never ever true, and usually stated by people that are either lazy or lack the confidence to improve their technical abilities).

Since the required skill level is not clear, it’s often also not clear what and how to test when interviewing a potential hire.

My take on it: while I love ex-developer PMs, and find that their teams often execute better, this is by no means a requirement. My minimum requirement is:

(1) don’t be shy about getting your hands dirty in understanding, at high-level, the underlying technological details, the different possible approaches, and their pros and cons.

(2) be able to ask dev the right questions to make sure your intentions we understood.

My view of PM-dev collaboration can be summarized with the following chart:

As you can see in this highly scientific analysis, a non-techy PM should do fine as long as the tech team lead has a solid understanding of the business side. However, if a non-techy PM meets a non-businessy team lead, things can go sideways pretty quickly.

Okay, those were way too many words to explain that knowledge is usually not a bad thing for a PM…

Take the following data structure of a note-taking app. The app is simple enough:

  • You should be able to write notes, and share them with a team
  • There are specific features that apply to specific user roles (e.g. only admins can add new users to the team)

The following is a proposed data structure for the MVP of the app:

Table 1: users

userId: 12345username: "guy@company.com"team: "great team"role: "Admin"access: {feature1: true, feature2: false, feature3: true}

Table 2: content

text: "this is my text"username: "guy@company.com"

Interview questions

The question I ask interviewees, and the one I’m asking you now, is simple: Take a minute to reflect on the above data structure. Can it meet the requirements? Is it a “good” structure? What are the upsides and downsides? What possible changes, if any, will you want to discuss with dev?

The thing about testing techiness, is that some non-technical folks are sometimes so intimidated by the sheer presence of a data structure or a few lines of code, that they would immediately shut down and be unable to answer even the simplest of questions.

It’s important to say, the above questions are not difficult; they’re actually quite easy, and anyone that’s been PMing for a few years should be able to answer them with ease. So if you can’t get a decent answer, it should really raise a red flag. And if you’re a PM and not sure you can answer this, I’d strongly suggest you take a short course in web development.



Source link

Leave a Reply

Your email address will not be published.