Hiring managers: don’t ghost candidates you speak to

I’m actively hiring to fill a role on my team, which means I’m talking to a lot of candidates in informationals and initial interviews. All of this has reminded me of one important thing: do not ghost candidates that you have spoken to.

Let’s say you take 30 minutes or longer out of your day and a candidate’s day to meet with them, learn about them, and discuss your role. Let’s also say that after the chat you decide that the candidate isn’t a good fit. You should at least send them a quick email letting them know you’re moving ahead with other candidates.

I make it a point to followup with everyone I’ve spoken with. I know that’s how I would want to be treated if I were on the job hunt.

Also, the world is small. It’s quite possible you’ll interact with the candidate you’re ghosting down the road. How awkward!

You’re not too busy. Take just one minute to let the candidate know where they stand. They’ll appreciate it.

What product management taught me about releasing an album

Last Tuesday, I released an album of music. It’s something I’ve worked on part-time for almost a year. Each track is inspired by a natural phenomenon.

I initially thought of this as a creative venture fairly different from my day job. Surely nothing from my day job would carry over, right?

Wrong.

While the end product is music someone listens to and not software someone uses, it turns out product management skills and techniques were very much in play as I went from early idea to published work. Here are a few that I used along the way:

Working backward

Product visions illustrate what changes in the world when the product exists, and what success looks like when the product is released and adopted. Some, like Amazon, write this vision down in the form of a future press release.

While I didn’t write a press release for my album, I did think ahead to what a release it would look like, and anticipated the things I would need to figure out:

  1. I knew I wanted an album that combined electronic with acoustic and electric instruments, so I had to research the best ways to get the sounds that I wanted.
  2. I knew I had a fair bit to compose, so I knew I had to research MIDI controllers and other input mechanisms for my setup.
  3. I wanted it to be released on streaming services, which meant I had to figure out what my options were for self-publishing through a distributor.
  4. I knew I wanted it to be listened to, so I had to come up with a plan for how to get the word out.

Defining a schedule

Work often fills available time, and for my album I had no hard deadline. To avoid working on it indefinitely, I set a personal goal of releasing it before end of 2020. This artificial deadline helped motivate me to spend time working on my music. It also ensured I wasn’t spending too much time tinkering, rethinking, or dwelling on parts of the work that were effectively done.

Making hard cuts

Early on, I had desires to have fifteen or even more tracks to my album. I had dreams of doing field recordings, and maybe even collaborating with other musicians. All of this takes time. That, combined with the reality that the last 10% of a project often takes the most time, made me cut back to something that was more reasonable: a 10-track solo album created in my home studio.

Beta testing

Often customers are asked to use a product in advance of it being released, to help the development team find and fix issues. As I was nearing completion of my album and doing final mixing and mastering, I listened to the music on various speakers including earbuds, car stereos, smartphones, and cheap monophonic Bluetooth speakers. I also shared the music with a few people to listen in advance. This all helped me uncover and fix small issues that I otherwise wouldn’t have uncovered.

– – – – –

While there are many differences between shipping software and making music, my day job doing the former certainly helped me figure out the latter.

I welcome your thoughts on how your day job may have helped you with a creative side venture. And, if you’re interested, take a listen to my work.

Don’t piss off your power users

I’m one of those weirdos that listens to podcasts at twice the normal speed. I do this because I listen to hours of podcasts a week, and I consume them more quickly this way.

I use Apple’s Podcasts app to listen on my iPhone. When I recently upgraded my iPhone to the beta of iOS 14.3, I was surprised to find this 2x playback feature broken. No matter what setting I chose, podcasts would play at regular speed.


Needless to say, I was quite disappointed. This bug effectively cut my listening efficiency in half. Plus, suddenly everyone seemed to speak s-o s-l-o-w-l-y.

While this was a bug, and Apple did fix it a few days ago, let’s imagine it wasn’t. What if Apple decided to remove this feature intentionally? After all, most people listen to podcasts at normal speed. Those weirdos like me are just the small minority of outlier users. Apple needs to focus on the mainstream, right?

Not quite.

Power users are free advertising. They laud your product to others. They email you feedback at 3AM. They buy a lot of your products. They’re a small minority of your user base but wield an outsized level of influence over the success of your product.

The 2x playback feature is an example of a power user feature. It’s something most people don’t use. But of those that do, chances are they’re fairly serious about podcast consumption. Take a feature like this away intentionally, and those users will, at minimum, likely complain loudly and switch quickly to another podcast app.

The moral of this anecdote: when looking at features to add, extend, or remove from your product, don’t just look at how frequently the feature is used. Also look at the broader behaviors of the users using that feature, including level of engagement. If you have a small group of users enthusiastically using a feature, don’t take it away. You’ll just piss them off.

Treat your time like investors treat money

When we review strategic plans at Redfin, Glenn reminds us that he wants to behave more like an allocator of capital. This means he wants to evaluate different ways Redfin can spend its money, the potential return for those investments, and then decide what will return the most.

That may seem like a cold way to decide what to do and not do. In truth, we consider much more than just return on capital invested when making strategic decisions. We’ll pass on investing in something that doesn’t make a customer’s buying or selling experience meaningfully better, or an agent’s work experience better. But thinking about return on capital is a good balance to avoid getting too attracted to interesting ideas that have a low chance of paying off.

Time is your scarce resource

As a product manager, you inevitably have more to do than there is time in which to do it. You have user research to conduct, designs to review, specs to write, metrics to evaluate, and roadmaps to put together. You have asks from other teams to manage. You have new people to ramp up. You have random issues in production that your team needs guidance on.

For this problem, I like to think of myself not as an allocator of capital, but as an allocator of another scarce resource: time.

Do your due diligence

When faced with a decision about where to spend your time, think about what return you’ll get for that time investment. Ask yourself the following questions:

  1. Cost: How much time will this take? Is this a high-confidence estimate or could it take much more or less time depending on unknown things?
  2. Value: How valuable is the thing that gets returned for putting the time in? Why?
  3. Expertise: Will you be the most effective if you spend time on this? Or, is there someone better suited that can do it faster and/or better?
  4. Opportunity: What else could you be doing, if you weren’t doing this? Are those things going to return something that’s more valuable?

Saying no is necessary

Investors want to put their money in more things than they are able. They have to say no to some investment options in order to say yes to others.

As an allocator of time, you’ll need to do the same. Saying no to doing something means you get to say yes to something else and give it your full focus. Saying no also may mean you need to find someone else to do it, or get agreement that it can wait.

Make your investments public

Make a list of the main things you’re driving, and where you draw the line below which items remain unfunded.

If your manager or a colleague wants you to invest in something new, share with them your list of where your time is currently allocated, and ask the above questions: what’s the new item’s cost and return, who’s best for it, and is it worth more than current investments?


Having a focused, high-return list of investments of your time is the way you’ll make the most impact as a product manager. As a bonus, it should also help you stay balanced and avoid overwork.

What product managers should do in their first month

Congratulations! It’s your first day at your new product manager job. You’re excited about the company and its mission. You’re looking forward to meeting your team. Your new hire orientation is done. Now what?

Starting a new job can be overwhelming. It can feel like a firehose of information is hitting you in the face every day. Where should product managers focus their time in their first month? Here’s my list.

Meet the right people

Product managers need to learn to be effective in their organizations. That is hard to do without knowing and working with the right people. This goes beyond your immediate team of engineers and designers.

On your first day, talk to your manager and find out two things:

  1. Who are the people outside your team you should work with?
  2. Who are the stakeholders that are interested in making sure you succeed?

#1 may include people in marketing, business development, operations, data science, and the field. They will help you figure out what products to build and how to deliver them to customers. #2 may be leaders in these or other parts of the organization. You may not work with them every day, but they are good sources of feedback on your plans.

Know your customer

To build great products, you need to know your customers and what they want. It’s good to spend time reading customer research that your colleagues have already amassed. But, there’s no substitute for doing your own research. Reading product reviews, driving usability studies, traveling to field offices, and doing first-hand interviews are all good ways to know your customer. Don’t forget to bring what you learn back to your team. Often, you’ll have something new to share.

Ship a quick feature

The best way to figure out how to get things done at your new job is to go through the motions of researching, designing, building, and shipping a feature. Even if you’re a manager, shipping a feature will reveal how decisions are made in your new organizations and highlight the strengths and weaknesses of your team.

This is especially important for managers; if you don’t go through the process of building product first-hand, you won’t be able to judge first-hand what is and isn’t working well.

Get a mentor

Mentors are invaluable in giving you feedback and showing you a perspective you won’t have when entering a new organization. Find someone who’s an expert in what you’re not, and ask them if they’re willing to mentor you. If you’re not sure who to ask, get advice from your manager.

Read a book

There’s likely one or two books everyone around you has read and values highly. Ask your manager or mentor to name them. Maybe it’s a book about being a good manager, or staying innovative, or the trials and tribulations of running and scaling startups. Whatever the book is, if it’s in the headspace of your colleagues, it’s probably a good one for you to read.

. . . . .

The first month at your new product manager job will start slowly and end quickly. If you do the above, I bet you’ll exit the month will a lot of groundwork that will set you up for success in your second month and beyond.