Tag Archives: josh elman

Practical Product Ep 9: The Harsh Truth of Interviewing & Hiring Product Managers

3 December 2022

Unfortunately, the product management interview process at most companies is poor. Navigating the interview process, or creating a good one at your company is a tall task.

In this wide-ranging interview we cover both perspectives to help you think about both the perspective of the interviewer and the interviewee. You’ll learn how to prepare to run a great interview process, when a project is appropriate and how to make it effective, as well as tips for your resume, and how to handle imperfect interviews for your next job.

This episode is with Willis Jackson, a long time friend of mine who has been the first PM at recently IPO’d Grove Collaborative, as well as VP of Product at Apto. He’s now hard at work on his own startup, but he took some time to share a lot of hard earned knowledge on the interview process in this episode of Practical Product.

The Product Management Hiring Process: How to thrive as the interviewer or interviewee

On this episode, we cover terrible PM interview practices, the key fundamentals of hiring you need to follow, how to ask behavioral questions the right way, making good PM assignments, and how to build your resume like a pro.

Highlights of the episode include discussing:

  • (0:44) – Introducing Willis Jackson 
  • (2:18) – The different types of Product Management and how they affect interviews
  • (8:09) – Recommended resources to learn to be great at hiring.
  • (17:15) – Handling ridiculous hypothetical questions and what to do instead.
  • (26:51) – The importance of networking, reputation and interviewing stories
  • (38:33) – How to make good, fair PM assignments for your interview process
  • (52:43) – Whether you should include company problems in your interview process
  • (59:13) – Resume crafting do’s and don’ts for PMs
  • (1:22:45) – Finding the right type of PM roles and filtering opportunities to save all sides tim

Key Show Notes & Further Reading:

We covered a lot of ground for both the interviewer and those seeking their next job, so some key takeaways are grouped below for each.

For the interviewer:

  • If you know you’ll be hiring down the road, start planning now. Think about the skills you want, the values you want, and the process you’ll follow. 
  • Interviewing is a skill. Spend time reading and learning how to do it well. 
  • It’s much easier to create your interview plan in small, incremental steps leading up to when you need them than being buried, desperately needing help and spread too thin.
  • Avoid puzzles, brain teasers, and hypothetical situations that are nothing like the job they’d have. Research shows it has no bearing on evaluating candidates effectively.
  • If you’re going to make an assignment, make it:
    • A reasonable time request (a few hours, not days worth of effort)
    • Consistently applied to everyone (don’t give one person a day and someone else 2 weeks)
    • Involves what the job would really include. (Willis’s example is a plan after an experiment / launch fails) 
    • Extremely clear what you’ll evaluate them on and what you will not. (Like whether you care about design or format)
  • Be proactive in communicating with your recruiting team. Enlist their help and expertise to find & close great candidates.
  • Remember that hiring the wrong person is extremely expensive in time wasted by your team, cost on your budget, and setbacks on your projects. 

For the interviewee:

  • Make your resume succinct and include data & numbers as much as covering skills and actions
  • If you do not have numbers now, start working on it now. Get in the habit to look up numbers and see what work you did has moved the needle.
  • Your resume becomes talking points and great questions in the interview.
  • Prepare good questions to ask an interviewee to make sure the company does the kind of product management you like doing.
  • Reflect on your current job regularly. Willis recommends weekly journaling on subjects like:
    • What wins have you had recently? What happened?
    • What did you learn from a project that recently didn’t go well?
    • What do you enjoy about your work and want future jobs to also offer you? 
    • What’s changed over time in my notes?

Helpful links mentioned in this episode:

Learn more and connect with Willis Jackson

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

Practical Product Ep 8: How to Write Product Specs Your Team & Executives Actually Want to Read

23 November 2022

Are your product specs high quality? Do they succinctly and clearly convey what you’re working on, why you chose them, and what your engineering and design partners need to do their jobs well?

Or are they kind of random, with each one different than the last?

I’ve helped dozens of PMs improve their product specs, and I’ve been lucky to learn from one of the best how to make a great product spec. Which is why I knew I needed to do an episode on the subject to help everyone improve their product specs.

Today, we cover:

  • The most common mistakes PMs make in their product specs
  • How I learned the right way to make a spec
  • The key, fundamental concepts underlying good product specs
  • and most importantly: Exactly what goes into a great product spec (aka- Product Thesis)

How to Write Product Specs Your Team Actually Wants to Read (AKA – The Product Thesis)

Everyone writes product specs regularly in their job as a PM, but few do a great job with them. These poorly constructured specs then cause all kinds of problems on product teams including:

  • Engineers and designers confused and uninspired about what they’re making
  • Delays in shipping due to misunderstandings and miscommunication about priorities
  • Disappointed execs who don’t get what they expect

And a lot more. Yet, it keeps happening because PMs don’t realize that the root cause in their specs that:

  • Do not cover the right topics
  • Are wayyyyy too long, and filled with fluff
  • Tend to be overly prescriptive on the solution instead of collaborating with your team on it
  • Lack data to back up your decision
  • Fail to share an inspiring WHY to motivate your and convince your team
  • Are inconsistent spec to spec making it harder to read and digest

That’s why we need to hit the reset button and reshape how you make product specs with something called The Product Thesis. Listen in to learn more about it:

Highlights of the episode include discussing:

  • (0:49) – Mistakes made on the average Product Spec
  • (3:17) – Introducing you to The Product Thesis 
  • (10:06) – What goes into a Product Thesis?
  • (12:05) – Section 1: Why are we working on this next?
  • (14:57) – Section 2: When and how do people use this feature? (Aka – what are the use cases?)
  • (18:24) – Section 3: What problems do we need to solve, and in what priority?
  • (24:19) – Section 4: How much time is budgeted for this project? When does this need to be completed by?
  • (25:56) – Section 5: What are the future considerations that must be accounted for?
  • (27:28) – Section 6: What is our KPI or metric for this thesis?
  • (29:59) – Optional: For larger companies: Who are the stakeholders and how/when do they need to be involved?
  • (31:14) – Optional: What kind of launch or marketing/sales efforts go with this feature?
  • (32:27) – Section 8: Further Reading

Key Show Notes & Further Reading:

Want to be the first to hear about new episodes of the Practical Product podcast, and blog posts I write about Product Management? Sign up here:

How to Write a Product Thesis to Communicate Customer Needs to Design and Engineering Teams

3 June 2014

Ever been handed a 10 page product spec that no one wants to read? Ever write one yourself? Tired of struggling to communicate what needs built next to your designers and engineers so they really understand the who, what, when, where, why of the next feature you need?

I’ve been using customer development, analytics, and information from my team to learn to build the right thing for years, but I always struggled communicating all the information locked in my head to the rest of the team. They needed to know why we were building it and all the necessary information to build the right thing without endless meetings or a massive spec they won’t read.

Fortunately, when I joined KISSmetrics, Hiten and I got to learn a better way from Josh Elman, who worked on product teams at Twitter, Facebook, and Linkedin.  Josh taught me about the Thesis, which is a lightweight way to communicate all the essential details your product team needs.

Now that I’ve used the Thesis on dozens of projects and tweaked it based on what I found worked best, I’m going to teach you how to write your own thesis for the next feature or product you build.

The Product Spec Alternative: How to Write a Product Thesis

> Know when to write a Product Thesis

The biggest crime product managers can commit against their team and their profession is to make up answers to critical decisions. Don’t be that guy/gal.

If you don’t know the answer to one of the sections in the Thesis, go find out. Dive into your analytics, talk to customers, run a survey, talk to your sales/account management/support teams that interact with customers regularly. You will gain the full respect of your designers and engineers if they know you always have a customer story and/or data to back up everything they may ask you about in the Thesis.

The following are all sections of the Thesis. I literally use these as headings to break up the parts and try to keep each section to 5-10 bullet points or a few concise paragraphs.

1) Why are we working on this next?

Every company, and especially startups, are resource constrained. What you choose to build affects your company’s bottom line, their standing in the market, and what your team thinks of your judgment. Use this area to concisely present your case for why this is the most important thing to work on right now.

I try to have a mix of qualitative and quantitative data here. If a mandate came from the leadership team to focus on this area, or sales needed it for a big customer, I make sure to include that. The more your designers and engineers can understand why this matters, the more interested they will be in working on it. In the end, you’re a team and everyone on the product team wants to be sure they’re building the right thing.

2) What are the use cases for this?

Most products end up having a variety of different users and ways that people use the product. To help your team better design a specific feature for the right part of your customer base, you need to detail who this new feature is for.

Be specific! A use case section that is just something like, “As a marketer, I want a mobile app so I can access my data away from a computer” is total weaksauce. Instead, provide the kind of context and detail that paints a picture of the situation:

  • On their way to work on the subway, content marketers like to check how their blog traffic is doing for items they published that morning or the day before. It helps them get into work and know how they’re doing before they sit down. If a number is low, they may try promoting it extra to try to raise the number. If the number is high, they may share the win with others on the team.

Could you picture that situation in your mind? Can you see Jenn the marketer opening an app on her iPhone while sitting on a subway car? I bet you could. Your team can too and they can also then start thinking about what the perfect (not just good) solution would be for them.

Write out as many use cases as you feel are needed. I often have as many as 4 or 5 detailed cases for a big feature.

3) What Problems do we need to solve?

Features are really solutions to your customer’s problems.  It doesn’t do any good to build a feature that doesn’t actually solve the problem, so it’s important to detail what problems you need to ensure the solution your team creates addresses them.

Problems should either be existing problems your product has (especially if you’re iterating on an existing feature) or the problems related to the use cases you just described above. Some example problems may be:

  • Performance Problem: Customers are experiencing frequent crashes. This feature is critical for customers and they are constantly having to refresh and start over, losing their work in the process.
  • Design Problem: Customers are having issues with the current UI. They can’t find key features that exist that they asked me for (Include a markup of the interface to show these.)
  • New Problem: Customers spend hours manually copying numbers to a spreadsheet and making their own visuals for their VP. If we automatically make those reports, we’ll save them time and can then have the VP see our branded reports frequently.

I usually write out 5-7 problems that a feature addresses in bullet form. If it only applies to some of the use cases I described, I’ll specify that as well.

I also try to rank the problems, so that the most important issues get the most attention.  Top problems may be because it affects the most people or functionality issues like the feature crashing constantly. When it’s time for tradeoffs when building the feature, having these detailed, ranked problems will help you make sure the right things avoid being descoped.

4) What are Future Considerations that must be accounted for?

Products are always evolving. Startups can be unpredictable, but you still know generally the direction you may be heading, especially if you’re driving hard towards product-market fit. Help your team anticipate what’s coming next whenever you can.

Depending on the feature, this could be very short or long section. If there are things you know are not going to make the first version of this feature but expect will be needed to be added later, be sure you tell your team! This section is all about avoiding hearing from engineering, “I wish you had told me that before we built [X]!” 

Balancing the present and the future is a constant struggle for a product. The best thing you can do for your team is give them the key information you know so they can do their best to balance their work against the present and future as well.

5) What is our KPI for this Thesis?

You should ask yourself, “What would make this new feature a success?” A KPI (Key Performance Indicator) is the most common way to determine that success since ideally you will tie the success of the feature to one or more of your company’s key metrics.

It’s okay to have more than one KPI, but keep it simple or there will be too many things to measure. When I’ve had multiple KPIs for a feature they’ve been things like:

  1. Support requests will drop by 90% for this feature after relaunch.
  2. Usage of the app will grow by at least 50% after relaunch.
  3. Because this feature affects the sign up flow, we expect a 5% lift in conversion after this relaunch.

You will fail sometimes, but by forcing yourself to quantify what you expect to happen, you will keep you and your team honest. By setting a number that you must hit you can also know when you should go back and iterate.

6) Further Reading:

Your main document shouldn’t be longer than 2-3 pages, so Further Reading can act as an Appendix for you.  In this section, I include links, screenshots, early mockups of ideas, markup of existing features for UX issues, and anything else that I believe would provide additional, helpful information and inspiration related to the project.

Remember: You want all the detail you can without the fluff and verbosity that makes engineers and designers skip reading it. Further reading is a great place for specific information that didn’t fit in the above sections and may be relevant to specific team members.

How does your team document what features need built next?