15 Things I Learned In My First 90 Days As A PM

You know the drill with these inspirational posters

90 days ago*, I started my adventure into product management after working in professional software engineering for almost four years.

*due to procrastination, by the time of this article’s release, it’s been almost six months, so I apologize for the clickbait 😂.

Entering the product management universe having done engineering work for so many years led to equal part excitement and equal part fear for me, as with all career transitions. In this article, I’ll talk about the 15 things I learned in my first 90 days as a PM at MemSQL.

As an aside, are you interested in how I transitioned from engineering to product management with no professional PM experience prior? I wrote a 3-part series on how I did it and got three stellar PM offers in two months — you can read it here.

Now that I got the self-advertising out of the way, let’s begin. Here are 15 things I learned in my first 90 days as a PM at MemSQL.

1. Importance of Good Mentorship

First of all, I’d like to thank my manager Rick Negrin, who’s the VP of Product at MemSQL. He’s the best mentor and manager I’ve had so far — he manages to be both compassionate but also fair in his feedback to me. He reminds me to trust my gut when it comes to product stuff. He’s taught me how to effectively prioritize. He’s challenged me in so many ways just the brief few months. Most important, he believes in me and reminds me to not give myself too much pressure. He’s an incredible example of servant leadership and leading by example. Rick’s role in MemSQL as VP of Product means incredible pressure and is constantly pulled in many directions from everyone. But he manages to mentor me, excel at his job while flying from Seattle to San Francisco weekly, and treats everyone with respect.

2. Communicate Effectively

A common thing you hear about being a product manager is — you need good communication skills. Well, what is that?

There’s the usual of having the confidence to speak with people, running a productive meeting (P.S. set an agenda, or just don’t meet), articulating your thoughts on paper, or public speaking, but there’s more to that.

In your day-to-day as a PM, you are also assisting other departments in communicating with each other when they speak a different “language”. You are the communication bridge with design, engineering, marketing, sales, and more. You have to strive to understand the motivation of each individual , and find the best way to communicate as a result of that. Many issues in an organization often falls back to poor communication. Ultimately, you are responsible for ensuring not only your communication with other people, but also clarity of communication between departments.

On top of this, it’s also important to be a good story teller. A good story writes a narrative, builds emotion, and articulates why a feature or a product needs to be done. Your stories usually relate to the user in many ways — you are the voice of the customer. Can you rally the troops within your organization to build solutions for the user’s pain? Can you articulate why something is important?

There are many ways to tell a story, but one framework I enjoy using for writing product specification is McKinsey’s Situation-Complication-Resolution Framework.

3. Importance of Public Speaking

A product manager’s responsibility includes ensuring information is effectively shared between people. This can be between coworkers, departments, stakeholders, prospects, customers, and more. So, a product manager is always speaking publicly. The ability to speak effectively, confidently, and charismatically is crucial. The other benefit of being an effective public speaker is that your audience isn’t bored by what you are saying. If your audience is falling asleep from your presentation — not very effective, is it?

Working as a product manager the past few months, I’ve had countless opportunities to lead meetings, share information between people/teams/departments, present during all hands, interview customers, attending conferences speaking to hundreds of attendees about the product, and more. What I am most proud of so far is speaking to over 500+ industry people on how to build an analytic application using MemSQL and Looker.

4. Practice Servant Leadership

This is a concept I learned from my former manager at Looker, Roland Blanton.

Your job as a PM often times is doing things that no one else wants to do. That can include writing docs, testing new product integrations, QAing the product (relentlessly), going into the code to understand a system to write product specifications, doing support, be the pain-in-the-ass when it comes to the quality of a product, spend hours poring over analytics to derive insight, talking to an unhappy customer, and more. When people ask me what I do as a product manager, I typically answer — I’m a janitor. Which is generally true. You need to do all of those things above to deliver a great product.

Being a servant leader also means you are serving your team, product, and organization. Are you helping your engineers, designers, sales people, etc, do the best work? How can you better facilitate them to succeed? Are they getting the credit they deserve, because they too are doing work that no one wants to do? Are you taking responsibility for your decision-making, or are you blaming someone else? Have you checked your ego at the door?

5. Where Technical Skills Come In Handy

I would not survive a day as a PM at MemSQL if I didn’t have an engineering background.

I work daily with ACM, IMO, and IOI medalists. Our CEO, Nikita, is a world medalist in ACM programming contests. Our engineering interviews are consistently rated one of the hardest by those that have come in.

And why is this necessary?

MemSQL is in the path to become the next great database, and this requires incredible engineering talent.

Having an engineering background helps me understand technical complexity of a project, the complex MemSQL architecture, write good bug reports, use development tools, understand why allocating time to write tests or clean code is necessary (this comes in handy with time estimation of tasks), ask good questions for spec writing, going into the code to understand a system, and just in general, empathize with how tough software engineering can be. The last point builds empathy.

I can also easily write scripts for data analysis or SQL statements to query my data. I also know how to ask a good technical question.

All of this technical knowledge also allows me to communicate with the less technically-inclined members of the MemSQL teams in ways they can understand.

6. Always Ask Why

As a product manager, you’re going to be asking “why” a lot. A whole lot more than when you were an engineer. This can be “why” to a customer request, prospect asking for suggestions, coworker suggesting an idea, executive/CEO making a comment, and even to your own ideas.

Coming from software engineering, there may be an impulse to think of how to implement a solution (on a process or technical level). But your job as a PM is to fully understand the scope of a problem and why it may be important. Asking good questions to fully understand the problem is crucial.

The best product managers practice active listening. Very often, they listen more than they talk.

7. Be Ruthless In Your Time Management

If you’re reading this, you know how important prioritization as a product manager is. It’s quite literally your job to assess how important a task or project by assessing estimated ROI, level of effort, resources required, impact, company mission, and more.

However, the skill of personal prioritization is just as important, if not more. We are bombarded daily by requests, ideas, questions, feedback, and tasks. It is quite easy to become overwhelmed and get lost in all these things. From the wise words of Rick, “be ruthless in your time management”. This means to:

• say no to people and suggestions.. in a thoughtful way!
• attend only important meetings (and say no to the rest). It’s very easy to fall into the trap of being in meetings all day. Don’t do that.
• document, categorize, and prioritize your tasks. Almost on a daily basis.
• block out time in your schedule to do meaningful work. Working from home once a week is ridiculously underrated.
• identify your most productive time of day, and do your most important work during that. For me, that’s in the morning.
• when doing personal prioritization, write down why a task is important, and why a task is not important. Ignore tasks that aren’t important, and focus on what is important.

Be ruthless in your time management!

8. Be Customer Obsessed

Customer obsession is part art and part science. It’s a mix of empathy for customer pain, to prioritizing what’s most important, to evangelizing them, to simply lending an ear. Aside from field sales (like sales engineering) and support, a PM has the most exposure to how customers use the product and their sentiment towards it.

One of my prouder achievements so far is starting the MemSQL Love initiative. MemSQL Love is the belief that if we can help our customers succeed, we will succeed. It also means, going above and beyond for customers — whether that’s helping them solve a problem, debug an issue, escalating an issue on the forums to the engineering team, or sending them swag to show genuine appreciation. I also started the #memsql-love Slack channel that lets everyone in the company to share the customer love we get, be it from social media, word of mouth, support tickets, etc. Over 80% of the company is in this channel, and lets everyone truly feel the impact our product has on customers!

The intent of #memsql-love is also to evangelize MemSQL within the organization. Many people aren’t exposed to customers at all (especially engineering), but they are the ones single-handedly creating the product that customers use. See the disconnect here? This channel gives them visibility to the impact that their work is making on people that use our product.

As a product manager, you’re the voice of the customer to the company. You are their biggest advocate.

9. Don’t Underestimate Stakeholders

This was one thing I wish I knew earlier before I became a PM — how important relationships with stakeholders are. A stakeholder has the power to veto your decision or project at any time. Since stakeholders are often more senior than you, this can be quite a stressful thing. Here’s something I learned about managing this crucial relationship:

• Identify who stakeholders are — this may be engineering managers, executives, sales leaders, etc. Sometimes you may get this wrong — it’s okay.
• Involve them early on in a project. No one likes surprises.
• Keep communicating with them throughout a project life cycle
• Understand a stakeholder can veto your project or decision at anytime. Don’t take it personally. Use empathy to understand why they may say no.

I would argue the most important relationship you need to have in any organization as a product manager is with your stakeholders. Don’t overlook this.

10. Drive Data Culture In The Organization

Data is hard, let’s throw that out of the way. There is also quantitative and qualitative data. Both are incredibly important in making product decisions.

Shortly after I joined MemSQL, I immediately came up with a plan to deploy an analytics solution to the product team to understand how users are using our product on a quantitative level. This has been and will continue to be an incredibly hard task, and is a full-time job in itself.

Deploying analytics across an organization involves:

1. Understanding the various different data sources in your organization — databases where user data lives (both on-prem and on the cloud), SaaS products (like Google Analytics, Segment, forum analytics, etc), and more.
2. Tying those data sources together into a data warehouse — your ETL scripts become your friend and worst nightmare. Both at the same time. Thanks Rick and Dave for lending a hand in this. These scripts are brittle, and require lots of manual work. Any new data source added now is another level of complexity which compounds. Don’t let anyone tell you data engineering is easy. It’s really really hard.
3. Hooking up an analytic tool, like Looker, on top. Funny enough, this is the easiest part of the whole analytics process. This also is a strength of Looker where once you write the business logic called LookML, performing analytics on your data becomes exponentially easier. It’s a true game changer.
   Disclaimer: I previously worked for Looker and is a stockholder
4. Analyzing what’s important to the product/business and coming up with key metrics to track. Doing this is also part art and part science. For sales, this could be tracking the goals for the month and progress of each sales person. For marketing, this could be tracking the entire marketing funnel. For product, this could be North Star metrics like monthly active users, retention, or amount of time the user has spent in your product. For support, this could be customer satisfaction over time.
5. Evangelize the data culture. This can be as simple as letting people know there is analytics available to be looked over. Or just sharing cool insight. Get people excited, get people asking questions, and get people requesting new data sources!

Within three months, the user adoption of Looker within MemSQL exploded and spread virally from product, to sales (SDRs, AEs, and SEs), to marketing, and the alliances team. Our CEO Nikita Shamgunov actually spends the most time in Looker behind me.

At MemSQL, product uses analytics to track our North Star metric (and much more, of course). Sales uses analytics to identify active free tier users and see who are most qualified to initiative the sales conversation with. Marketing uses analytics to identify active users so they can tell their story of how they use MemSQL. Alliances uses analytics to identify partners, both existing and prospective ones, that are trying out MemSQL.

MemSQLers from every department went from making guesses about the product, to actively asking why user’s behavior may be such a way. In ways, this has actually created more work for me, but when people start going from intuition(which is often wrong!), to asking why, this signaled a cultural shift. No competent organization in Silicon Valley should stop asking why.

However, quantitative data isn’t the only important data to track.

Always take time to talk to customers/prospects — this could be at conferences (in my space, these are enterprise data conference such as Strata or Gartner), conducting customer interviews (I try to do at least 5 a quarter), or just conducting user testing for the product. One thing I like to participate in is observing how new users install MemSQL. Installation is the first experience a new user has with your product. If it’s hard, well, that directly affects your North Star of monthly active user, for example.

11. Relationships matter

As a product manager, your relationships with people matter a whole lot, whether this is in the organization or outside. These relationships can be with your partners (in my case, my relationship with former coworkers at Looker), customers, coworkers, stakeholders, executives, CEO, and even yourself.

Learn how to effectively build relationships and maintain them. There are countless articles and books on this topic, so I won’t go too deep on this one.

Be kind. Be humble. Actively listen. Communicate effectively. And always be empathetic.

12. True exposure to how an organization is run

Product management truly gives you maximum exposure to how an organization is run. Your role involves working with people in all departments — sales, engineering, support, marketing, design, legal, and more. You’re invited to many of the executive-level meetings, and so all the good things and not-so-good things happening in the organization are all visible to you. You start developing context for not just the product you manage, but also how the product fits in within the organization. This can also mean the organization may succeed or fail on your managing of the product.

The responsibility you hold can be both exhilarating and anxiety-inducing.

13. Get things started

Getting things started can be in the form of identifying problems and building process. As mentioned in the previous point, a product manager has a lot of context to the organization, and thus have the ability to identify operational inefficiencies. You can take take advantage of this visibility by taking initiative and build processes that can make the organization run more efficiently or effectively.

You don’t have to be a product manager just for your product. You can be a manager for the organization too.

This can be in the form of attending conferences and getting ideas on how to improve the product, conference booth, the company’s pitch, etc. Or becoming the evangelist of the product and company, which in return inspires others within the organization to do the same. Or starting a data culture initiative. Or using your connections in other companies to improve alliances. Or just simply speaking up for a problem you see that needs fixing.

There are countless ways to “get things started” — use your acumen and visibility to the organization to do it.

15. Know when to take a break

Finally.. A very most important thing I learned after a few months on the job.

“What we do is a marathon, not a sprint. We will not get it right the first time or all the time and that is okay. There are no clear answers.” — Rick

Product management is a pretty damn stressful career. Especially as a young ambitious person, you want to pick all the low hanging fruits, make an impact immediately, push yourself forward, and more. But doing so too quickly can easily lead to burn out. Admittedly, when I first joined, I saw this job as a sprint. I must put in my 150% every single day to push the company forward. I think any ambitious person may have this attitude.

But what’s been told of me is — product management is a marathon, not a sprint.

Think of it this way.

If you are running a 10K, and you use up all your energy in the first 1K, but you still have 9K to go, is that an effective use of energy? Not really, right? So treat product management as a marathon, not a sprint. Save your energy over time so you can complete the marathon.

Learn how to identify burn out, and take adequate breaks or vacation time when necessary. Try to take walks after lunch to get some fresh air and just to clear your mind. Practice mindfulness. Share work stress with friends or mentors.

Thank you for reading!

If you are a product manager, what were some things you learned in the first 90 days?

If you liked reading this article, please give it a little support by holding the Like button, or sharing it with people in your network! I would deeply appreciate your gesture.