13 Hard Things I Do to be a Dope Database Product Manager

If you want to be a Product Manager but haven’t read “The Hard Thing About Hard Things” by Ben Horowitz, I recommend it. The book isn’t explicitly about Product Management, per se, but Horowitz has an important perspective for you. Don’t take my word for it. He was the first product manager at Netscape, the company that brought us the web browser. (Yes, you can blame them for Internet Explorer.)

Depending on the situation you find yourself in organizationally, you may not have the option to do one or any of these things on day one. A product manager’s number one job is to do what needs to be done, and this blog isn’t about that.

In “The Hard Thing About Hard Things,” Horowitz does two things that I also like to do:

(1) He starts every chapter with iconic hip hop bars from modern-day poets.

(2) He talks extensively about the need to focus on what matters. You are what matters, so my list is about you.

Take a little trip, hater, pack up yo’ mind
Look forward, not behind then you’ll see what you find
I caught a sucker dyin’ ’cause he thought, he could rhyme— Andre 3000, “The Whole World”

1. Use the product constantly.

I need to know the product to effectively manage its priorities. As a product manager, I strive to capture how it feels to use the product, ergonomically. I need to understand the feedback from the customers, the engineers, and the field teams to catalog, analyze, and triage their concerns. Of course, I’d rather just come up with ideas, go to meetings, and get coffee.

2. Break the product.

There’s something bad about everyone’s product. Pushing my products to their failure points has provided invaluable clarity on what use case(s) to focus on, and where to invest. If it’s a database product, it’s much better for a product manager to know this information before their customers. I direct my intellectual curiosity to this realm.

3. Simplify the messaging.

This is a multi-step process that is never done until my grandmother knows what I do for work. Everyone in your target market should know exactly what you are talking about when you use your product messaging. Remember, it’s going to be distributed to sellers.

4. Explain the product in your third most proficient spoken or programming language.

For most normal people, like me, your vocabulary drops way off once you get to language 4. If you can explain your product in a language that you don’t get a lot of practice with, you have likely reduced your product to simple terms, which is hard for technical product managers.

5. Wake up very early in the morning at your local time, and take a call with a customer who suffered an outage.

You must feel the pains of your customers. Hearing them is not enough. If you are a database product manager, one of your European customers was likely on call and had to wake in the middle of the night because of the outage. Wake up one time so you get the fix prioritized for all your customers. This one is less sustainable than others, so use it sparingly. Boundaries are more important.

6. Average one new spreadsheet per week (these are often edited, reformatted, or beautified by team members).

I hate spreadsheets so much. It’s partly due to brain injury, and my consequent reliance on augmentative and alternative communication (For example, I pace and gesticulate.) Spreadsheets were my initial motivation to eschew business school. Turns out, B-schoolers are probably right about that one. Spreadsheets are a super effective tool for both data analysis and structuring the unstructured. Spreadsheets, when organized in folders and bookmarks (more on this later), help me scale and collaborate. I honestly should use spreadsheets more, but it’s just so hard.

Ask Questions, and Always Be Shipping

7. Tell many prospects “do not use the product!”

Salespeople do not like this muscle, but it’s such an important part of the job. Good Product Managers tend to have a customer obsession, but the best ones know when to walk away from a problem you know you cannot solve.

8. Chase usage and value to your customers, not dollars.

If you work at a bad company, this action would eventually get you in hot water. The money will come. You need usage from your customers to iterate based on feedback. If you don’t have a high-fidelity feedback loop, your product will be bad. Who wants to buy that?

9. Write imperfect documents.

I can thank my boss and skip-level of my current job for this one. Engineers will push for perfection from their point of view, and product marketers will push for perfection from their point of view. It’s a painful process to get used to, but it’s critical to the design process of a well-oiled product organization.

10. Cutting scope is easy these days, increase it when it counts.

So many of the training courses and the product leaders in the world will teach you that scope creep is the death of all products, and you should iterate incessantly. There’s nuance to this point. If you know an engineer is working on something complex that is risky to switch context on, yet their first iteration did not deliver the expected business value for the customers, go back to the drawing board. Of course, you need to know when to abandon the endeavor and move on.

11. Run experiments that perform worse than the control.

It’s easy to spot if a product manager comes from an experimenting culture. I’m an OG Test and Target user, extremely early Optimizely user, and have run all kinds of experiments from the linux kernel to HTML for my whole career. Sufficiently testing means that n% of your experiments fail and that’s ok if you frame the problem as an experiment to learn from at the outset.

12. Listen to people who don’t know what they’re talking about.

You should consider yourself lucky. Beginner users are a gold mine for product improvements. I meditate all the time in an attempt to return to the beginner’s mind. If you think someone does not understand what you are talking about, usually it means that they are giving you invaluable insight that you might not have because of the first practice on this list.

13. Write SQL queries.

There will come a day in the not too distant future where nobody will need to write SQL queries. Today, I still need to do so on occasion. I try not to overfit on small sample sizes or jump to conclusions. Occasionally, I slip into the pattern because I am looking for answers where they are unclear. For most product managers, you need to write some SQL occasionally. Thankfully, there are a lot more tools to choose from and ways to conduct data analysis that never involve SQL. Databricks needs to launch their MQL product.

Bookmark this blogpost. Organize bookmarks is an honorable mention in my list of “hard things.” There’s so much information out there and documents to track, not doing so is so much harder. Maybe these important tasks will become easier and get replaced by other challenging idiosyncrasies.

I want to have empathy for my customers and learn from the winners. Ben Horowitz is the inspiration for this blog post because some people think that Product Management is easy. They must not do hard things.