Lessons from my first Product Manager role

What I learned in my 3 years at Clio

I recently left my job at Clio, where I was a Product Manager for 3 years. I joined Clio in July 2018, at a time when there were only 5 PMs and 225 employees, and today there are over 25 PMs and 575 employees. Clio also recently became Canada’s next unicorn, with a $1.6 billion USD valuation.

During my time there, I worked on our flagship mobile app, our first-party email integrations, and our first consumer-facing product.

Needless to say, it was an exciting 3 years with lots of learning — especially since it was my first PM job.

In this post, I’m going to share what I learned as a first-time Product Manager. If you’re a budding, new, or even seasoned PM, hopefully there are some key takeaways for you.

Here they are:👇

Of course, this is the most important. But don’t just understand your customers — obsess over them. Consume every touchpoint you can find about them.

Read Support tickets. Listen to Sales calls. Analyze NPS comments. Find the places on the internet where your customers are talking about your product; whether that’s on Twitter, Facebook groups, or Reddit threads.

Talk to your Customer Support and Sales teams. Ask them what pain-points (or deal breakers) come up most frequently. The insight you’ll gather from them is 100x more valuable than reading some random blog post about product management (yes, I recognize the irony).

An analogy often used is that PMs are the “CEO” of their product area.

This means you should obsess over everything to do with your product and the market, and always be on the prowl. Here are some tips:

  • Set up Google Alerts for mentions of your product online.
  • Scour Twitter/Reddit for product feedback.
  • Use tools like VisualPing to track your competitors’ launches / announcements.
  • Follow your competitors on social media to keep an eye on their progress.
  • Identify opportunities for partnerships, integrations, or acquisitions.

As a PM, you'll need to work cross-functionally with various departments and stakeholders. But that doesn’t mean you should only engage with them when you need something from them. You need to develop rapport and camaraderie with them, so that working together comes naturally. Take the time to get to know them personally: message them periodically, catch up over coffee, or grab lunch with them. It goes a long way.

Use quantitative data (e.g. metrics, data) to tell you what is happening, and qualitative data (e.g. feedback, interviews) to find out the why. Never make a decision without having both. You can only paint a proper picture when you have both. And knowing the right blend of the two is an art, not a science.

It can be tempting to get wowed by vanity metrics, AKA cumulative or ‘absolute’ metrics. For example, say I told you 200 customers used the feature you built — that might sound impressive, but what if 200 is only 1% of your customer base of 20,000? Or, what if I said 1000 messages had been sent on your platform? That sounds like a lot, but that’s an average of 0.05 messages per user…

Generally speaking, it’s better to use relative metrics, e.g. “% of customers who performed X action within Y timeframe.”

There are certain things the data won’t tell you, or that you won’t hear from a customer… but you just know that it’s the right thing to do. This is called product sense, or intuition. Remember: data doesn’t know where you want to go; it only knows where you’ve been.

As a PM, you are accountable for the success of your product; the experience users have with it. However, you and your product team only actually control a fraction of that experience… there are ads, emails, signup/login, customer support, feedback channels, etc. Don’t think of these as ‘not your job’; find ways to continuously be improving these processes, by working with the right cross-functional teams.

A few examples from my time at Clio:

  • We implemented an automated follow-up when customers left positive NPS comments about our mobile app, encouraging them to leave an App Store review.
  • We added App Store download buttons into the footers of our marketing emails.
  • We built a direct feedback channel into our mobile apps during our beta program, and included a link to my Calendly for scheduling feedback calls.

In order for a product to be successful externally, it needs to have momentum internally, so that the company as a whole is excited to launch and scale it. The best way to do this is to evangelize your product inside your organization. Present demos of it, set up feedback channels, create an internal beta program… the list goes on. Basically, be the internal hype captain!

Say what you’re going to do, then do what you said you’d do. It sounds simple, yet it’s not as common in the workplace as you’d think. To stand out as a PM, always follow up or loop back on things you committed to, even if it feels redundant or repetitive.

The worst thing you can do is treat your engineers like ‘mercenaries’; people you simply give orders to. Instead, get to know all your engineers on a personal level — they are some of your most important teammates. Then, get them bought into the broader product vision. This creates a team of ‘missionaries’, inspired by a greater purpose.

As a PM, when working on user-facing features, it can be tempting to want to ‘design’ a solution yourself, rather than letting your designer handle that. But your job is to frame the user, the problem, and the goals. When giving feedback to your designer, frame them as problems or challenges, rather than solutioning it.

It sounds laborious, but always take meeting notes. Delegate action items. Capture key decisions, and communicate them as they’re made. This all feeds into ensuring your team is aligned, which is part of your job.

Rather, they’re a learning opportunity. When you launch, you get an endless stream of feedback & data. It can cause you to iterate on the feature that launched, or even alter your upcoming roadmap. And that’s a good thing; it means you learned something new.

Yes, you should celebrate launches — but treat them as a means, not an end.

Over time, you’ll likely communicate with a familiar set of customers — often your most passionate ones. As you’re going through the product development cycle, take them on the ride with you; involve them in discovery, testing, betas, and launches. They love feeling like they’re part of the process.

And once you’ve shipped a feature request of theirs, make sure you personally reach out to those customers, letting them know it’s now live. The responses I got to those emails were always precious.

Thanks for reading! If you enjoyed this post, feel free to follow me here + on Twitter @samir_javer.

Product @Grammarly. Ex: @GoClio, @Thumbtack, @DoMeetings.