How To Get A PM Job With The Yammer Mafia
Part 2, The In-Person
In Part 1, I discussed the PM hiring process, my recommendations to get into the process, and pass homework phase of a Yammer Mafia company (where ex-Yammer employees run Product or Engineering). Now we’ll take a look at the in-person interview, the theory behind what you’ll be asked and the expectations of the interviewers.
The in-person interview will be challenging and cover topics ranging from statistics to product sense, project process and execution to thinking minimally, intuition and Econ 101.
First, try to understand our context. Why do we do what we do and why do you want to be a part of that? A little passion goes a long way.
The team is going to expect a lot of you. Yammer’s project process is a little different, in that there are no “product owners.” Impact over a broad area of the product is not a privilege of rank or management, but granted in every project.
In 90 days on the job you should have shown that you can execute a good sized project autonomously, you can reason out and defend product positions, and contribute worthwhile ideas and feedback to the rest of the team. We can’t just trust anyone with that.
The day of, depending on the size of the team, you will most likely meet a few product managers, a data analyst, and an engineer. They each have a role in assessing the following.
the ability to look at a product, figure out what the creators care about, and form a plan for what to do next
As it turns out, product sense is extremely difficult to gauge in an hour conversation. Expect every PM you talk to to try and dig into this in some way.
Expect to be asked about a variety of products, what metrics the PMs of those products care about, and how to best improve those products. A common mistake is to forget the relation between these two: if you tell me the PM team of a given product cares about the number of files uploaded, your feature better increase the number of files that get uploaded.
The goal of any project in the Yammer process is to ship the smallest thing possible to deliver the value we are trying to create. Unused functionality is tech debt and overbuilt features are a waste of time.
Interviewers will likely ask you to design a feature with them. Your inclination will be to overbuild or throw out one of my favorite gotchas, the magical algorithm. What we really want to see is something very small or a multi-part plan to test to the big thing they’re asking you about.
Project Process / Execution
We’re trying to answer two questions:
- Can you adapt as project process changes? Everything changes, we can’t be wedded to a form of agile with a bunch of capital letters in the name.
- Can you lead a team (that you don’t manage) to the best possible outcome? Ideas, as they say, are easy. Execution is extremely hard.
These aren’t easy to gauge, we’ll likely ask how you’ve worked in the past, what went well and what didn’t. What part did you play in the success or failure? What would you do differently?
If you’ve been paying any attention to product development over the past 5–10 years, you’ll understand why metrics are important. The old measure of success, revenue, is a lagging indicator and doesn’t lead to good product or near term outcomes.
That which is measured, improves. That which is measured and reported, improves exponentially. — apocryphally attributed to Karl Pearson
Expect Yammer Mafia companies to measure everything. But while this portion of the interview will likely be conducted by a data analyst, that doesn’t mean PMs can abdicate all understanding of stats to the Data team. You will be expected to get your hands dirty, find anomalies in your tests, understand cohort analysis, and work with the Data team to find testable correlations in historical data.
App metrics aren’t just metrics, attention is currency. The things you want users to do with your product cost your users some of that attention. Some have started to refer to this as “behavioral economics.”
Understanding economics and associated modeling is the advantage of MBAs who want to be PMs, assuming all the other traits and skills align.
A few more attributes we believe make PMs successful:
Passion for great product + Product Curiosity + Intelligence + Intuition + Ownership + Technical Competence + Social Competence + Solid Communication
These will be addressed somewhat ad hoc throughout the process and be the primary focus of the Engineering interview. There should be healthy friction between Engineering and Product, so they’ll also try to assess whether they can disagree with you professionally and still be friends at the end of the day.
I hate. Hate, hate, hate that estimation questions have slunk their way into PM interviews. This is an absolutely worthless skill for a product manager. I don’t have a billion users and, even if I did, your ability to calculate things about them doesn’t make a single difference in building the right thing.
And that’s about it. Not easy by any stretch of the imagination, but with the right preparation and experience maybe you’ll get an offer you can’t refuse.