The Product Interview — A Technical Exercise
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.
There’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…
Exercise 1: know your data structure
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.
A possible solution/discussion
Obviously, the correct answer here is C. The correct answer is always C.
But seriously, let’s take a look at that data structure. Will it meet the requirements? Sure. You have all of the elements in place — you have users that belong in teams, they have user permissions, and they can add content that connects back to them. But is it a “right” structure?
- Entity ids
In general, all entities should be identified by a unique id, In our case, we have three entities: Users, Teams, and Content (and arguably Roles as well). while the user name does have a unique id, the team and content do not. Why is this important? Names are fragile — they might not be unique (and enforcing uniqueness leads to other issues), and they sometimes need to be changed (if a user changed their email, for example). - Connectivity by id
While the user does have an id, it’s actually not used in the content table. So if the user does decide to change email, or if somehow someone has the same email, this can potentially cause issues. It’s perfectly fine to have the username as well in the content scheme, but not instead of the userId. - Separate the entities
The way the permissions are currently implemented is that the user is given a role, and their permissions are added to the user. The upside is that it’s very easy to get the permissions in one query. The downside here is that if you want to change the permissions in any way (say, give the admin permission to a new feature), you will have to run a migration script on all users, which is never a good thing (PMs and QAs have lost countless weekends over migrations went wrong).
The way permissions are usually done, is by having another table for roles, specifying the permissions each role holds.
The idea of separation can (and probably should) also apply to the ‘team’ entity, in much the same way. - Missing dates
While dates are not a requirement for the current version, they should be saved in the DB, as we might need them in the future, and they’re impossible to recreate. Specifically, the content creation dates are highly likely to be required for future versions, and it really doesn’t take a lot to save them in the database.
It’s important to note that I won’t expect a candidate to just spit out these issues (and others) as a monologue. This can definitely be a back-and-forth situation, thinking about future features and the changes that might be required to the DB, much as this is done in day-to-day work.
A real-life scenario
This exercise is not theoretical. PMs encounter these issues all the time. A while ago, I was working on a task management app that required task types (similar to Story, Bug, and Task in Jira). The task types we editable, but 2 task types were ‘special’ and had unique features (e.g. a specific task was tracked and shown in analytics pages).
Our (business-savvy) dev team lead approached me with a simple enough question: how should we design the presets: (A) on account creation, ‘hard code’ the presets to the account’s list of actions, or (B) create a separate table for the presets and point to it from all accounts. He was leaning towards option B, but wanted to consult.
While both architectures would have 100% worked for our current spec, they were massively different, and the decision should have definitely involved the PM. The reason is that while both options work today, they affected the options for the future, and the PM probably has a much clearer guess of what that future might look like.
Take a minute to reflect on the two options. What are the pros and cons to consider?
Here are my considerations for making the decision:
- Deletability
In the current design, the presets, as I mentioned, were ‘unique’, and we did not want to enable the users to delete them from the list, so it made sense to separate them. However, would this always be the case? If the events are separated, it’s really hard to delete them. If they are hard-coded, it’s easy to block them from being deleted. Point 1 for hard coding the event types. - Changing the presets
If we ever wanted to change the presets (say, change the icon on an absence event, which is kind of like changing the icons of a Jira bug), it’s much easier changing it in one place, rather than in all existing accounts. We thought about this, and decided this is unlikely, and in any case, running a contained migration wouldn’t be the end of the world. Hard coding the event types also meant we were able to change the settings only for new accounts, while keeping the old settings for existing accounts, which was not possible had we separated the presets. - Flexibility
We were a new startup, and releasing our first ever version of the app. In these cases, you have to assume that what you don’t know outweighs what you do by quite a lot. We assumed the presets were a good feature, and pretty much a one-size-fits-all. But what if we were to discover, upon launch, that 20% of the customers hated the presets (which we did soon enough, by the way. Turns out some liberal schools do not like focusing on ‘negative events’ such as tardiness, and do not mark them in their systems). It was much easier to enable deletion on specific accounts with the hard-coded version.
This scenario might not seem dramatic to some, but a hands-on PM might encounter these cases a few times a week, and making an informed decision might mean that a month or two down the road, the development of that new feature might take a day instead of a week, or a week instead of a month. At the end of the day, a techy PM (and a business-savvy team lead) can highly improve the execution of the team.
In other cases, seeing the technical design of a feature led me to understand that dev was over-thinking the feature, designing for a robust, easy-to-grow code, when the feature itself was a bone we threw at a large client, not intending to further develop it a lot (yes, not a great practice, I know). While we intended it to be a 3-day task, dev estimated it at 2 weeks, creating a gap that was only bridged by reviewing their plans.
If you’re a UX- or marketing-oriented PM, this post might have left your head spinning, or your eyelids heavy. Going back to the intro — no, I do not think every PM needs to be an ex-coder. You might even do okay without any ‘techiness’, as long as your team lead knows to ask the right questions.
But understanding how software works allows for fewer misunderstandings and less misalignment between dev and product, saves time and some pulled-our hair.
That’s it, hope you can make good use of this resource. Clap away so more people can see it 👏👏👏, and let me know what you think!
