Ok, so today I want to mix things up a little. I know this newsletter has some value to you because each edition is almost always a follow-up from a conversation I had with one of you and consistent open rates of 44-58% show you look forward to each edition (or that I only nail subject lines, but let’s go with the former). On the other hand, it gets a bit boring and limited to only write from my own experience. I know I’m not that good to keep things interesting every time.
So, I though about this: I do a lot of research for my job. It’s one of the three meetings I have with myself every single day. And I have to summarize the learnings to share internally and drive new projects. What if I polish my notes a little bit to share them here with you? Maybe a stupid idea. Or not. You let me know.
So, to kick this off…
Here’s what I’ve got this week:
Personal perspectives: Hiring for CS, when to do it and what to look for
Recent research:
QBRs for busy people
Mixing product-led growth with product-led sales
Don’t overlook retention anti-patterns
Identify and fix your product’s knowledge gap
Small ask: I write for you, otherwise this would just be a private journal. If you enjoy today’s edition, let me know. Can be as quick as hitting the like button or leaving a comment. Your feedback is the only way to make it better.
Alright, let’s get to it.
Hiring for CS: when to do it and what to look for
After building customer success teams at Typeform, Belvo, and now Claap, one thing became clear: each startup is unique, and you can't simply plug and play what you've learned from one company into another. To help you navigate this journey, I’m sharing some guiding principles to help you decide when to hire for CS*, how senior that person should be, and what to prioritize initially.
When to bring on the first hire
I truly believe in founder-led customer success. Founders know their product better than anyone else and can provide personalized attention to early customers. This hands-on approach allows them to truly have a clear understanding of user’s needs, common use cases, and where people get stuck. This will help them know the right profile to hire: more or less technical? Someone to build self-serve or someone really good with 1/1 interactions and driving strategic conversations?
Guiding principle: do it for as long as you can and hire a dedicated person when you realize you won’t be able to handle the work and keep the same level of service quality.
Striking the right balance of seniority
The second question I get often is how senior the first CS person should be. While an experienced professional can bring valuable insights and strategic thinking, it's not always necessary to hire at a senior level. And sometimes you really shouldn’t. Especially if they haven’t held an individual contributor role in some capacity for a while and show no interest in doing it again.
These are some of questions you have to answer before deciding on the seniority:
What do you need to delegate? A huge volume of support tickets? Custom implementations? Or big picture planning and strategy? Focus on what you need, not want.
How complex is your product? Is it a plug-and-play solution optimized for self-serve? Or do you need be hands-on to help customers understand the value and activate?
What’s your top priority? Reduce the need to contact support and improve self-serve programs? Or have strategic conversations with key customers and drive feature adoption and expansion?
To understand who to hire, it’s essential to consider the type of product you’re building and the specific needs your customers have.
Guiding principle: look for a generalist with 2-3 years of experience in a company similar to yours in size, product complexity, and price point. And above all, bring on someone who has the capacity for both systems-thinking and hands-on work, is autonomous and driven, and wants to grow with you. The last one is hard to measure, but look for high energy and passion for the role during the interview.
The continuous prioritization process
Identifying priorities in the early stages is essential and should not be a one-time exercise. Customer needs and market dynamics evolve over time, as your product will, especially before you hit product-market-fit. This requires ongoing evaluation and adaptation.
For founders and CS leaders, I can’t emphasize enough the danger of trying to scale too soon. Yes, self-serve should be the end-goal. But not your first priority when you’re just starting out.
Doing things that don’t scale really is a good mantra. Scaling too soon is a sure way to optimize processes based on the wrong assumptions. Ruthlessly prioritize 1/1 conversations with your power users and customers. This is what will inform your scaled programs and self-serve motions.
Guiding principle: look at the data, speak with customers and front-line teams. It will give you qualitative knowledge to better grasp the most critical areas you need to address. It's certainly easier said than done, but knowing what needs immediate fixing and what's a long-term goal for the business is how we prioritize everything.
More about this in this edition.
*CS here in a broader term, including customer support, customer education, account management and all. As your startup matures, you want to specialize the team, but this article is about your very first hire.
QBRs for busy people
We know this from our own experience of being at the both ends of the table: most QBRs meetings are a wasted opportunity. And most of the times, the decision maker — the person actually holding the budget — is not even present. Kevin Chiu, COO & Founder at Catalyst, shares a practical way to solve for this: right after the QBR meeting, send an email to the decision maker with the key takeaways from that meeting and how your product is helping them meet their OKRs/KPIs.
My two cents: in CS we obsess about how our solution directly impacts business outcomes. Truth is, this is very hard to do. On the opposite end, we almost despise focusing on usage metrics instead (think Spotify’s Your Year in Review or Grammarly’s monthly usage report). But similar to what Kevin said, most of the time the decision maker is not a user of your product. And believe me that in times like this when every Executive is looking for ways to cut tools and reduce costs, guess what’s the first question they’ll ask: who’s using this? Followed by: how often?
So yes, it’s crucial to give Executives visibility on overall usage in your product. Sending a monthly report to decision makers with key stats will ensure your product is top of mind and has the added benefit to arm your champions and power users with data when renewal time comes.
Adding product-led sales in a product-led growth model
I’ve been reading a lot how to incorporate PLS into PLG products. You might think: that’s way to soon for an early-stage company. Well, yes and no: you definitely shouldn’t go overboard with a full blown PLS playbook, but there are some tactics anyone can implement almost from day one. Here are the best resources I found on the topic and snippets of wisdom:
Qualify your customers: segment customers in a quadrant that measures customer happiness with growth potential. For this, pick a few metrics you are already tracking either way: NPS score, activity on key features, clicks on billing page, and so on. Create alerts if you can, if not do it manually for your Tier 1 accounts.
PLS starts with segmentation: you can’t possibly go after all accounts with a sales-led approach. So which ones should you prioritize? Define what ready for Sales means to your product. This article, similar with the first one, gives some ideas. For example, look for multiple free accounts with the same domain as a paid one, so you can reach out to propose a workspace consolidation.
5 Common PLS Playbooks: I won’t do you any service by trying to summarize this. This is hands-on one of the best articles I found on the topic. No fluff, just practical stuff you can implement right away.
The role of Customer Success within self-serve models: the one and only Allison Pickens (ex-Gainsight) joined the Pocus team for a must watch podcast episode. What I loved the most is the insights she gives from products she experienced as a user and the tactics they used to activate her. I have no idea why this only has 37 views.
Product-Led Sales at Retool: Pocus podcast twice today, but this is another must watch. I have a blown-up whiteboard where I documented the key takeaways. I will need to adapt it a bit to share externally, but will probably incorporate the takeaways from Allison Pickens and share it the next newsletter.
Don’t overlook retention anti-patterns
Really insightful article that dives into retention anti-patterns — features that can hurt user retention if they are introduced too early in their journey. They give a very detailed framework on how to identify retention roadblocks and build stronger products.
Identify and fix your product’s knowledge gap
Enzo Avigo (June.so) wrote a super hands-on (and viral) Linkedin post on how to find and fix your product’s knowledge gap. It reminds me of the idea of SaaS consumption gap. I first heard it from David Apple, my former manager at Typeform, but Userpilot has a good article about this too and looks like this white paper is the source of it.
TL:DR: Both ideas, the knowledge gap and the consumption gap, highlight the number of features available in a product and the customer’s ability (aka knowledge) to consume those features. Two ways to solve for this: increase the user knowledge and lower knowledge needed. Get the details here.
And that’s all for today.
If you enjoyed today’s edition, let me know. Can be as quick as hitting the like button or leaving a comment. Your feedback is the only way to make it better 🙏
See you next time. Until then, keep build amazing products and service experiences. We need you.
— Angela 🫡