What to look for when interviewing a Product Manager

If Product Management is both an art and a science, evaluating candidates cannot be something which is 100% objective. That hasn’t stopped people from making millions writing books about acing the PM interview at places like Google or Amazon. This guide isn’t for job seekers, it’s for interviewers, though it could be used by either. It’s particularly targeted at CEOs and other leaders who have not hired a product person before.

You’ve read Ben Horowitz’s Good Product Manager / Bad Product Manager, but what should you look for when the candidate is sitting in front of you?

The psychologist next to me on the plane as I blog says that you should look for eye contact. I agree with her, but that’s really something you should look for in any potential hire. Let’s focus interviewing on a product manager.

Depending on your product, the amount of industry or technical experience required will differ, but all product managers should be good story tellers. That is what the rest of this post will center on, what to expect in the stories that a quality candidate tells. The reason why this is important is because how a product manager communicates with you and your team will define their success.

The ideal PM Interview story format:

  1. Starts with a problem — Product people are problem solvers, so you should expect their stories to start with an issue they observed or were presented with.

  2. Researches the problem — You don’t want to hire someone who jumps straight to a solution, instead look for an individual who invests in understanding the problem first.

  3. Collaborates on solution — If the interviewee doesn’t talk about the other people who worked with them to design a solution, it is a big red flag, collaboration is key.

  4. Validates problem/Solution match — After problem investigation and solution ideation, they ideally talk about how they validated there was a problem/solution fit.

  5. Evolves the idea — Good product managers will leverage the feedback they received while validating their solution to advance the product feature to best match the problem.

  6. Empowers builders — Listen for how they talk about working with the developers and note if they only giving instructions or working with the engineers to create the best options.

  7. Enables sales/marketing — Whether it’s through a B2B sales team or B2C consumer marketing group, an advanced PM will describe how the feature or product was sold to the market.

  8. Measures success — Data driven decisions are what separates average PMs from great ones; an ideal story will include how they collected metrics to define whether the released solution actually solved the user problem.

  9. Follows the data — Unless the candidate includes information about how the metrics guided them towards next steps, what was the point of collecting the information?

  10. Iterates on product — Launching new things is fun, but a lot of the role will consist of iterating on the same product over and over again, it’s important that they are excited by later versions too.

Though the list of things above seems long, the last thing to look out for is the person’s ability to tell the story in a succinct way. You as an executive and other leaders within your organization will not have time to invest in long drawn out narratives.

What do you look for when PM candidates are answering questions?

A Product Manager’s Guide to Planning a Wedding

I’ve previously written about how dating is like SaaS sales, this post will focus on on framing planning a wedding, given that you’ve found that partner you were looking for. Like that other post I’m going to draw similarities between familiar terminology used by PMs to frame how to successfully plan your dream wedding.

Wedding = Product: It’s one of the most important events in your life and all of the effort you put in will pay off. But there’s a very slim chance everything will be perfect. Remember that all products have bugs as so will your wedding, so breathe and remember that vast majority of people never notice the issues.

Wedding Date = Launch Date: Let’s start with the obvious. You only get one shot at this particular product launch, as there’s no way to push it back if everything isn’t ready. If there was a Resource — Quality — Time triangle for your wedding, it would be a fixed time project. Chances are you probably have a budget too, which means you’re in a fixed resource and time scenario. That means the only thing that can change is quality, so be ready to make some compromises. With that in mind you’ll be able to use your prioritization skills to determine what’s really important, don’t sweat the small stuff.

NOT WHAT YOU ARE LOOKING TO DO

Partners = Partners: I’m stressing that which should be obvious. Your life partner whether they are the bride or groom has a vision of what their wedding day will be. Like in all joint ventures, both parties put their name on the finished product and this may yield some brand conflicts. If you can surface why the things are important to them and how it relates to their identity early on, then find common ground your future spouse will feel even more like your partner. If they are passionate about something, let them own it… and let them own some things they aren’t excited about too. But similar to other partners, making it clear who is responsible for what deliverables will minimize fighting later. Also, ever notice that parents names are also on the invitation? That means they have similar brand concerns related to their invited guests which should be understood as well.

Parents = Stakeholders: The classic wedding planning conflict arrises between parents and children, so I find this the one most helpful for brides and grooms to be. Ninety percent of a Product Managers’s role is working with other teams, listening to their requests, and managing their expectations. The same sort of activities are required to keep your parents at bay. Like all stakeholders, parents want to be heard and need to be kept in the loop about how things are progressing. The small investment of time on an ongoing basis will save you hours later. Additionally, if you can let them have their pick on some of those small details mentioned above, they will feel like they have had a few wins and make it less of an issue when their opinion is ignored on other matters.

Guests = Users: It’s your wedding, but you probably want your guests to have a great time too. As product managers, we create delightful user experiences, and the same opportunity is there for your wedding guests. Want to know what will make the event memorable and enjoyable for them? ASK THEM! Getting feedback can also help settle disputes between partners and stakeholders. It’s easier to side with one perspective when many people share it, even if that viewpoint isn’t yours. In our wedding, I thought a sleight of hand magician would be awesome for the cocktail hour… luckily, we asked some friends and learned that I was definitely wrong. On that note, go to other people’s weddings and conduct “user research” :)

Wedding Planner = Project Manager: Not everyone has the budget to work with a wedding planner or day of coordinator, but if you do, treat them like you would your project manager. They have worked on hundreds of weddings, and you will hopefully only plan one, so leverage their experience. It’s still your wedding and your vision, their role is to make sure all of the trains leave the station on time so that you don’t have to worry about it. Be nice to them though, they are the lynchpin in this launch and they’re the often best person to help you navigate trade-offs.

Florist = Designer: Treat your florist / event designer like you would your product designer. They need creative freedom and if you are too precise with instructions, they will recoil. Like with the designer on your team, talk about your vision and goals, and collaborate with them on making them a reality. They often surprise you with innovative ideas as they come from a different perspective.

Vendors = Engineers: Most weddings have at least 6 vendors (venue, caterer, photographer, videographer, florist, and officiant) and there can be many more if your affair is more complicated. Though you are paying your vendors, if you think of them as developers, you will realize that nothing will be completed without their help. It’s best to get on their good side and ensure that they feel proud of what they are working on. What often happens, as it does with engineers, is that they create something even better than you imagined when they are empowered to do so. On a side note, the more quality your developer, the better the code and product, so think about where you want to invest in vendors. You wouldn’t have a junior engineer design the core elements that are supposed to last forever, so don’t skimp on the photographer that’s creating your lasting memories.

A Marriage = A Company: Your wedding is probably the first product you and your partner will launch. Like a company, your marriage is what you want to really invest in making last for decades. The wedding maybe your launch, but without adequate support, ongoing maintenance, and new features, interest will wane. With everything I’ve listed to keep in mind, that is probably the most important.

Are you a product person who recently got engaged or married? Did this resonate with you? What would you add or adjust?

Lean Validation via Email

Engineering time is valuable. Don’t waste it on something you aren’t sure has value or that you aren’t sure what should be included. This is especially true with emails. Even with libraries like blueprints from Mailchimp, coding up HTML emails is the least favorite thing most software developers do. Therefore, make sure that the emails you are asking them to create are both of value to the customer / team and fully baked ideas. I’m not suggesting that they be perfect and never need iteration, but don’t think that changing the copy on them every week or two is in your best interest.

Step 1: Understand the problem

Why are you even sending an email? Is there on an on screen option that could suffice? Even if the conclusion is still an email, understand what user problem this is solving. Ask questions like:

  • Who is the audience for this email? Are there different groups?

  • What do they want to know?

  • What do they need to know that they wouldn’t think to ask?

  • What do they already know? (what stage are they as a customer?)

  • When do they need the information?

  • What voice do we normally communicate to these users with?

It’s ok if you don’t know all of the answer to these question and you make some assumptions. As long as you call that out and decide when and how you will be validating those hypothesis.

Step 2: Create a single template

Don’t try to solve all the problems identified at once. Create a basic email template the covers what you can. Iterate on it… the subject line, the copy, the jargon, the images, the time of day of sending, who it gets sent to if there are multiple users within a group…

Step 3: Create a second template

Iterate on the first one and you’ll probably realize that there are separate user groups who have slightly different needs, create a second template to help with those problems. Create reports and decision trees that help you decide who will get which template. This will establish the business logic the engineers need to know. If you can’t create a simple decision tree, it will probably be hard for the engineers to code the logic as well, so simplify where you can. Iterate on the copy as well as the imagery you’re using based on the replies you get from users.

Repeat and expand your template library until you have the vast majority of use cases covered. If you have more than 3 emails, see where you can find common ground and consolidate. Again, don’t strive for perfection, it’s ok to have a “Here’s who to contact with additional questions” sort of ending.

Step 4: Automate the email

Use the business logic and the copy and images to generate the actual emails to be sent by the product.

Step 5: Continue to monitor open rates and ITERATE

Your job is never done… stale emails suck… schedule a time to review.

Get the Most Out of Remote Teams with these Tricks and Tips

Congrats! Your company is growing. You’re doing so well that you’re about to open another office on the other side of the country (or world). Alternatively, you maybe looking for a second or third location to expand your talent pool. Maybe you have an outside sales team that needs to be closer to prospects.

As exciting as expansion can be, having team members in separate locations comes with some challenges. But don’t worry many successful companies are full distributed (Invision) and most companies eventually expand geographically to be closer to clients.

CONNECTION = COMMUNICATION

When people aren’t physically in the same place they often feel disconnected. That feeling is a result of missing out on interactions with coworkers at an alternative location. FOMO is real at work too (think about that meeting you wish you were in…)

More accurately, it is about missing out on STORIES. Research has shown that telling stories helps create community and empathy. Sharing personal experiences with coworkers adds dimension to an other potentially transitional relationship between coworkers.

Depth of relationship with teammates often translates to employee satisfaction. It also often leads to more streamlined and open communication. Without this depth people may lack the ability to speak freely when something is going wrong which can lead to missed timelines or incomplete products. Projects also seem to take longer to execute because asynchronous communication is inefficient. No one wants buggy products that take longer to build, and you definitely don’t want your shiny new office to be to blame.

What can you do to foster connection across locations? Below are some ideas that I’ve seen work, but they are by no means an exhaustive list. Please send me things that have helped improve connection where you work so that I can add them to my tool belt.

Give everyone time to talk:

This seems obvious but I can’t tell you how many times I’m in a meeting where the person on the screen has to fight to be heard. When everyone is giving an update or opinion, make sure to intentionally include the virtual folks too. Similarly, pause and ask them their thoughts on topics that are being discussed. Mix things up where you ask them first instead of last so that they don’t feel like an afterthought or that everything has already been said.

Pretend Everyone is Remote:

If you’ve ever been on conference call with a group in a room, you know that you can’t always hear everyone clearly. That’s because they aren’t close to the microphone. If you miss parts of the conversation or story, you feel isolated. If EVERYONE is also dialed in (from their desk) then it’s an even playing field.

Hold Virtual Office Hours:

This can be by function, team, or just random. A time where people are available to chat about a topic on a regular schedule at a defined URL (Appear.in or Zoom rooms are great for these). You can also book a room in each office at this time and video chat from there, but that will bring back most of the normal challenges with remote conference calls mentioned earlier. Be sure to choose a time that’s convenient for multiple locations and that if you’re very spread out over time zones that every office has some office hours that are in the most ideal time for them.

Rotate where you meet up:

It’s unfair if one office is always doing the traveling back to HQ. Switch things up and visit the distributed team where they work or meet up in a neutral place where everyone can experience new things together. Each city will have a slightly different culture because the talent pools are different. By switching up the meeting location, each cultural dialect of sorts can be better felt and understood by the other offices.

Have the exec team visit the offices:

Everyone wants a little face time with the company leadership, so go out to see them. When visiting, don’t spend your entire time in meeting rooms, block off some time for your own office hours or to sit at an open area. Meet some of the team members that have joined that office, they’ll feel more connected to the company at large. Executive face time is critical to having the those employees who don’t work at “the home office” stay connected.

Be flexible with work schedules:

You probably opened a second location to be closer to your customers and align with their hours of business. That means your team there can’t have perfect overlap with your HQ. Some people in each office will need to come in early or stay late in order to collaborate with their teammates in other timezones. Be flexible about when people come into the office and how often they work from home.

The actions above will make all team members feel more included, respected, and connected. But, every company is different. What works for one won’t work for all. Which tactics have you tried? What others have you seen work?

P.s. I want to leave you with a positive note. I believe the future of work is distributed and asynchronous and if you as a company can rise above the challenges, you will be setup for greatness. Here’s some insights about how Invision, a 100% distributed team stays connected. God speed to you!

How to use Slack for TO-DO list

I manage a small inbound sales team at Justworks. In a recent 1<>1 one of my direct reports asked about how he could make sure he wasn’t letting some prospects fall through the cracks.

To paint you a picture, I must start by explaining that our team does not have a typical sales funnel where an individual prospect is assigned to a sales rep. We have collaborative queues where any team member can help a prospect. The process isn’t perfect, but it means that we have a response time often within minutes or hours and new customers have confidence that whoever they talk to at Justworks will be helpful and knowledgable.

Here’s the list of places our team has to check to see who to reach out or respond to:

Zendesk is where all prospect email communications come in

  1. Slack Channel with Customer Support who handles front line questions but escalates to our team when needed.

  2. Jira dashboard with requests for more information on benefits quotes requests.

  3. Salesforce dashboard with and follow-up questions to workers’ comp insurance applications.

  4. Slack Channel with Marketing Response team who passes inbound leads to us based on specific criteria.

  5. Redash dashboard with lists of prospects in different stages and contact information for nudging.

  6. Slack messages with other sales, support, or operations teams who help us.

Our team sends / answers 300+ emails and calls daily from prospects.

So when my direct report was asking for help, it was a legitimate request. The first time he mentioned it, I suggested generic methods like using a physical or virtual To-Do list when things came up and adding future follow-up tasks to his calendar as a reminder.

A few weeks later, I asked if that had helped and didn’t get the most positive response. Those workflows had made some things better but the frustration centered around SLACK. Though it is an excellent tool for getting real time responses, with so many channels to monitor and continuously refreshing conversation chains, it was difficult to remember what needed to be done.

Being a product manager, I watched my user in action before making additional suggestions. The struggle was that when a new message or notification came through, the channel would be bolded and on screen alerts would appear. But once opened, there was no visual cue as to where old messages containing important info about prospects and actions to take were.

We thought about looking at threads, but most of the conversations were not in threads. Then I remembered ***the star***. I don’t know exactly why “star message” was added as a feature in Slack, but it always seemed to me like their way to save something for the future. I used it at previous companies to save links that were shared or important information. But at our company, Slack messages are purged pretty frequently so it wasn’t as useful.

But stars were perfect for the current problem! They allowed the inbound sales rep to flag messages for follow-up later in the day. So the new flow became…

If an issue can be resolved right now — do it.

  1. If an issue needs to be resolved later — star it.

  2. “Show Starred Items” at a set time during each day and triage the items.

The new process has been very helpful and less things are falling through the cracks.

Stop complaining that Developers don’t build what you want, Communicate Better!

Many product managers get frustrated when the dev team doesn’t build what they thought they requested. Rather than blaming the engineers, look at how you are communicating and make adjustments.

Properly deciding what level of detail is right for your audience and what to show them can ensure successful impact of your message.

Below are options for how to share your vision for a feature and suggestions for when to utilize them. They are in a chronological order that should become a cycle.

  • Sketches: A rough hand drawing of what you’re trying to accomplish is often all that’s needed to spark a conversation and clarify confusing topics. Always start with a sketch when designing new screens or flows.

  • Wireframes: More detailed than a sketch, but still not a full fledged view of what will be built, a wireframe is a great discussion tool when getting high level effort estimations from developers and for receiving feedback from potential users to ensure you’re headed in the right direction with your design.

  • Screenshots: After validating the basic wireframes with users, creating a pixel perfect representation of what the designer thinks is correct will allow for more accurate estimation and more detailed conversation with developers and customers.

  • Prototypes: Thanks to Invision, generating a clickable tangible mock version of your site or application is super easy. Allowing prospects and team members to play around with one of these will surface where things are confusing and when the functionality is well understood.

  • User Stories: Writeup of the goals of the feature and acceptance criteria so that the design and development team have a clear understanding of what’s included and what isn’t. Attaching a screenshot or prototype for the team to review will add color to the written description. The set of upcoming features’ user stories should be reviewed in regularly scheduled sprint/iteration planning meetings.

  • Product Briefs: Sometimes grouping the features together and describing the overall value they deliver is helpful. This can be written up as an epic or one page document to share with internal stakeholders. Marketing and sales teams love these documents because it helps them anticipate what they’ll be able to promote in the future. Customer support teams appreciate them accompanied with prototypes so that they can familiarize themselves with upcoming features.

  • Roadmaps: These overviews for the long term strategy of your product are excellent to show investors, exec teams, and occasionally employees, but generally let your internal team focus on the immediate tasks at hand. Make them more specific in for the upcoming months and hazy in the future, everyone knows you aren’t going to stick to it perfectly, so why pretend?

Each organization will utilize the above in slightly different fashions, and sometimes whole steps are skipped. Do what works for you and your team, but when process starts breaking down, return here to see what you might be missing.