What to Look for When Hiring a Product Manager

Screenshot 2016-02-10 08.05.23

Product managers can make or break organizations, which is why hiring managers must spend time landing the most talented PMs. Great hires help their companies level-up.

So, what exactly should you look for in a PM?

When I’m hiring, I look for candidates who are what I call “smart chameleons.”

These people immediately impact a particular product. They adapt quickly and efficiently whenever new ideas or initiatives emerge.

To this end, a candidate’s experience—alongside examples that demonstrate his or her ability to adapt—are the key qualifications that I explore during the interview process.

No One is Born a PM

A master blacksmith teaches an apprentice how to shape metals. Similarly, PMs need to get their hands dirty while on the job to learn their craft.

At Fuze, we typically hire PMs with at least three years of experience. It’s great when that experience comes from places known for producing great PMs, like big software companies that have established PM disciplines and training programs. Amazing PMs can also come from medium-sized tech firms and often have very cool and interesting backgrounds that led them to Product Management.

Some of the best Product Managers I’ve worked with have the most amazingly diverse backgrounds: an art history major, a finance manager, and once even an astrophysicist. You can also often find great PMs inside of Sales and Sales Engineering teams; they often have amazing customer empathy given the amount of interactions they have with them.

I also seek candidates with relevant domain experience to our industry and technology. It simplifies the onboarding process when new hires have a basic understanding of our tech, B2B sales, and enterprise platforms from the beginning.  

Adaptability

Anyone who’s worked in the startup world knows how quickly things change. PMs need to be versatile enough to keep pace with those changes.

During the hiring process, I ask candidates to provide examples about how they’ve shipped their products. More specifically, I ask candidates to describe times when they had to get creative to ship something. Maybe they had to deal with missing information. Maybe there was no existing process. Maybe they were competing for resources.

Whatever the case may be, the more creative the candidate’s response, the more likely we are to proceed to the next round of interviews.

Great PMs Empathize with Customers

Those who know me have heard me talk about how important customer empathy is for a PM. Let’s reiterate.

When I’m hiring, I look for candidates who have extensive experience talking to customers. I seek out people who can provide examples of turning those interactions into products and feature improvements.

Empathy is one of the most important skills for anyone in any industry. Candidates who can place themselves in their customers’ shoes and see problems (and solutions) from their perspectives tend to succeed in PM roles.

Communication Skills are Critical

If candidates can’t communicate effectively, how can you expect them to ship on time?

One part of our Fuze interview process involves homework. We give candidates an assignment and ask them to present their response to us. Topics change periodically, but they always focus on a real business challenge that we’re facing.

Forcing candidates to prepare presentations in a relatively short period of time is a great way to ascertain how well they think on their feet and whether they can communicate content clearly and concisely.

Thanks to this component of our interview process, we can gauge whether candidates have the communication skills that are necessary to thrive.

Although different candidates appeal to different companies, strong PMs will be experienced and quick on their feet. They are empathetic and communicative. Keep this in mind and with luck you’ll make amazing new hires.

For more on the topic, check out Steven Sinofsky’s post on hiring your first PM.

 

4 Things Every Product Person Should Do

Image by Flickr user 42614915@N00

Image by Flickr user 42614915@N00

It would be a shame if growing in your career took you further away from having an up-to-date perspective of what’s happening with your product.

You can quickly forget what life is like in the trenches. If you want to be an effective product manager, you need to actually work on the product. Some people estimate you should spend 30% of your time with hands-on work in engineering roles.

I would suggest that it’s paramount for product managers of all levels to be do-ers.

It’s crucial for managers in the Product space to:

  • Get out of meetings
  • Walk away from product roadmaps and strategy
  • And lead by example by consistently getting into the weeds

How to get your hands dirty

Write a Spec

Product Requirement Documents drive the efforts of the entire product team. Its hard to come by a more important, higher leverage piece of work for a company. Every quarter I make sure to take one project or feature and write the entire PRD and spec for it.

This includes writing up wireframes, mockups, business case, scenarios, technical discussion, and timeline. I also put it through the same process  my PM’s need to go through: review, iterations, sign-off, etc.

Teardown a Competitor

When I see a competitor that seems interesting or a technology that could be useful to our products, I will spend an hour on a Friday performing a teardown.

A good teardown will involve – where possible – getting hands on time with the tech or product in question, taking relevant screenshots, and writing up evaluative feedback. I then provide some ideas about how we can either beat the competitor or, failing that, integrate with them. I post these ideas into our wiki and share with the team. 

Triage Bugs

About once a week I will jump into JIRA, pick a product, and review the Priority 1 and 2 bugs. Do they match my expectation of priority? Great. If there are any questions, I will sit down with the individual PM and ask them about it.

Attend Individual Scrums

There are too many projects on my team to go to every scrum, so instead I pick one day each week to attend a different product’s meeting. I usually sit and listen quietly, then afterward will use my one-on-one with that PM to ask questions about what I heard. Theres a lot you can tell about a team just by occasionally showing up to their daily standup.

Why would you do this?

Respect

Students in my Product Management class at General Assembly this semester heard me start every lesson with some form of “This stuff is so cool! I love building products.” One of the first things I look for when hiring PM’s is their raw passion for wanting to build cool stuff.

Doing individual work like this shows your team, your peers, and your management that you are fired up about building products. You’ll earn their respect, which can be especially helpful when onboarding into a new team.

Improved efficiency

The first time you write a spec as a newly promoted manager (especially if you haven’t written one in a while), youll instantly discover what in the spec process needs improvement. Fixing these issues will make your entire team more efficient.

On our team, I realized that we had four different flavors of PRDs. I worked with Alex (one of our Directors of Product Management) to unify them into a single format. We then came up with a template for the new PRDs and put it into our wiki. That’s the spec process we use on all of our products today.

A Dose of Realism

It’s easy to think projects and products will execute extraordinarily well. As a manager in the Product organization, your goal is to balance your optimism for completing a project against your pessimism, your previous experience telling you how complex it is going to be.

Periodically writing a spec, attending a scrum, and triaging bugs can help you stay much closer to what’s actually happening inside your products and code.

Spend your time wisely.

Which will be more expensive: time spent on non-managerial work, or the risk of failure stemming from a knowledge gap between strategy and execution?

Why I’m Teaching

SpringfieldElementary3

It was 10th grade in high school and I was taking a class called “College Marketing.” It was a college-level course being taught as a part of a business program our school was piloting. The teacher, Mrs. Stein, pushed our class to explore potential career paths through cool projects and presentations. Mrs. Stein was always encouraging me to explore fun side projects and to network with everyone that I met. She eventually gave me advice when I started “MicFlash Enterprises” that fall (my 1-person desktop publishing ‘company’), and through our conversations that year she helped me understand what a career in business and technology could be. Mrs. Stein later introduced me to her husband at a class field trip to his office at Viacom in NYC, and some follow-up conversations with him led to my first internship at Viacom headquarters in Times Square. I can trace almost every job (and a best friend) since then back to the people I met at that first internship.

Mrs. Stein played a seminal role in my life. As an educator she taught me skills about business and professionalism that I still remember and use today, and as a mentor she gave me guidance about my career and connected me to my first job. I can never thank her enough for the path she showed me.

Twice a year for the last nine years, I have been going back to my old high school on Long Island and giving a talk to the students in Mrs. Stein’s classes. I call the talk “You Don’t Have To Be The Valedictorian To Have A Career You Love,” and it’s my attempt to show them how important the experiences, people, and relationships they make will be to their life. I do this by walking the students through a bit of my career journey: building web pages at a leather gun holster manufacturer in New Hyde Park when I was 14, DJ’ing, building web apps for Viacom, being a personal fitness trainer, then mainframe programming for insurance companies, eventually going to Microsoft, then Contactive, and now ThinkingPhones. I share how every opportunity, every job, and every success (or failure) was the result of a relationship I had made with a key person in my life.

Throughout my career I have continued to look for ways to coach and mentor others. As a manager at Microsoft I quickly realized and embraced that much of my role was teaching and coaching my team so they could grow and perform as quickly as possible. Working in the NYC startup scene at Contactive was a big change since our team size made it so I had a very tiny team and almost no time to manage. That wound up being a great impetus to jump into mentoring and advising other companies, and it’s something I continue in earnest now at ThinkingPhones.

Recently a mutual connection introduced me to one of the founders of General Assembly, Matt, at an event in NYC. He told me about GA and their mission, and almost immediately I said “Sign me up!” I loved the idea of working with a set of industry veterans to teach and coach others who were passionate about Product Management and design.

I’m now extremely excited to be joining the General Assembly family as an Instructor for their part-time Introduction to Product Management course. You can check out the details here on the GA site.

I can’t wait for the summer. I look forward to learning as much from the students as they (hopefully) learn from me.

Thanks!

A Product Manager Should Be The Most Curious Person In The Room

the_riddler_vector_by_tauntaunwampa-d59vg56

image (C) Tauntaunwampa

I was talking earlier this week with a new product manager on my team. It was our 1:1 and we were discussing his latest project. It’s the first big product area that this PM has taken on and it’s very important for our next release, so we were using our conversation to make sure everything was on-track. I was peppering him with questions after he shared his update:

“How do you feel the project is going?”
“What challenges have you hit working with your feature team?”
“Is the spec ready for review?”
“Okay, can you show me the diagram for the main use case that you’re stuck on?”
“What about this part of the lookup, can we also double-back with the phone number?”
“I just thought of these two uses cases, have you considered them?”
“What’s left between now and the spec review?”

Later that same day I was in a feature team meeting discussing the status of a new product offering. The lead developer was sharing his detailed update, which included a few specific areas that had risk and ambiguity.

“Why did you choose that implementation path?”
“Will this scale if we 10x the amount of users in a year?”
“Is there a faster way to do it?”
“What if we added more resources?”
“What are the biggest remaining risks?”

Folks who have worked with me before know that I love to ask questions. A lot of questions. 🙂 The questions I asked during the 1:1 with my PM (and their resulting answers) helped me quickly understand the status of the project and where he was blocked. It also set the stage for the type of information I’d want to hear in the next update I get about the project. He and I then spent a few minutes talking about questions, curiosity, and why they’re both so important for Product Managers to be effective in their careers.

Awesome Product Managers have an unrelenting sense of curiosity. They’re equally curious about the latest competitive apps, their own project statuses, industry news, how a piece of backend technology works, the reason a bug occurred, or why a partner team is late on delivering. A great PM should use precision questioning to drill into every conversation and problem to understand what is really going on and what they can do to move things forward. This can reveal gaps in use cases, technical knowledge, or even a partnership agreement that need to be addressed.

Checking for curiosity is critically important when evaluating a PM for a role on your team. Many parts of my PM interview process, from the “What’s your favorite app?” question all the way through the product design case study, are used to see how curious the candidate is. Do they start out the case study by immediately jumping into a solution on the whiteboard based on something they know, or do they open with a set of questions back to me to help understand what they don’t know.

Ultimately your use of precision questioning as a PM must be balanced with the amount of investigation and discovery you do on your own. You will also gain a lot of experience over time simply from being in more and more product cycles.

The simplest way I can frame this advice? Don’t wait if you’re curious about why something is. Get curious and ask the question.