Why Startups SHOULDN’T Have Growth Teams
Startups shouldn’t have growth teams. The whole company should be the growth team.
While Alex Schultz isn’t the first person to infer growth is everything when it comes to new products, I like how he goes one step further and says growth is the whole company’s responsibility (10 minutes into the video).
Currently, my team is working on growth for a new mobile app for a public company. We’re in the early days, so our North Star is retention. While we have $1M in the bank to spend, and while a lot of new companies would be envious of the cash position, the vast majority of that money will go untouched until we’re certain we’ve made something enough people want where users are happy.
While we’re making great progress, in the off chance we don’t get to REAL product-market fit, I’d much rather return the capital than spend it knowing acquisition without retention is no different than lighting money on fire.
From the outside, it probably looks like four different departments are building this product: engineering, design, marketing and customer service. But it’s exactly this line of thinking that smothers a product’s growth potential. Sure we all have different skill sets and experiences, but they’re all being applied to one thing — retention.
I could ramble on about how our whole team is responsible for growth vs. a select set of individuals who have outlandish LinkedIn titles like “growth master” or “marketing wizard”, but it’s easier to just tell you about what we all did yesterday.
Early Morning
Got into work and started the day catching up on customer support. Even though we’re still just a few thousand users, call-to-action requests around customer feedback are pervasive in-app. For this reason, it’s not uncommon to have hundreds of customers leaving us feedback daily.
As a team, we made the strategic decision of designing the user experience so it’s as simple as possible for customers to tell us what they think. Even though I’ve read plenty of stories about software companies hiding phone numbers or contact information to cut down on the amount of time spent reading, listening and responding to customers, I can’t think of a more dangerous way of cutting workload. Sure, not encouraging customers to contact you saves time on customer support. But then what’s this time spent doing? Likely speculating on what to build next in a conference room supported by little-to-no user feedback — another wonderful activity for lighting money on fire.
When some people think of customer support, they might think of a $10 an hour resource, or perhaps even an offshore solution. Nothing against affordable labor (we try to take advantage of it too), but I can’t think of someone I’d be more happy to pay handsomely in the early days than customer support. Here’s why —
Late Morning
In addition to reading and listening to customers and prompt response times, we take extra time “theming” all support responses. While the positive feedback is great for morale and momentum (and we quickly calculate “the share of customer feedback that’s positive” to have a rough pulse on how we’re doing), we spend very little time on what’s going well — mostly because it’s not actionable, unless “patting ourselves on the back” is considered actionable.
The theming comprises the foundation for our customer Pareto analysis — again, for actionable purposes, we leave out positive feedback. This analysis plots two things: (a) count of customer feedback by theme in descending order (primary vertical axis) and (b) the cumulative distribution function (CDF) of support requests (secondary vertical axis).
I’ve masked the themes, but you’ll get the idea. Despite twenty themes, the top three comprise 60% of all customer feedback and the top five, nearly 80%. If we can figure out ways to use our skills as designers, engineers, marketers, customer reps, etc., to resolve these top issues, there’s probably a pretty tight correlation to improving retention.
Early Afternoon
Now that we’ve quantified precisely what customers are telling us needs work, it’s time to call in the greater team, both other internal members as well as the client.
Another nice thing about the Pareto is it removes the bias of prioritizing work based on what customer is “screaming the loudest”. This way you’re not always calling “fire drills” having an engineer fix something solely because one customer dropped an f-bomb. While it might seem like an urgent issue if you’re the person having to deal with the feedback, the Pareto keeps us objective, especially given we’re still quite small with limited resources.
We present the findings and do a deeper dive into each specific theme. For example, let’s say one of the top themes had to do with “a poor onboarding experience”. What else can we conclude from the feedback? Using tactics such as word frequency and sentiment analysis, we can get a more granular view of the top issues specifically within onboarding.
Ultimately, the outcome of this exercise is a specific list of things to prioritize. Let’s say “improving onboarding” is one of those things. Intuitively, this might sound like an engineer or designer’s job. Sure it’s their job, but that’s shortsighted — if the goal is retention, and this is quantified as a top barrier to improving it, it’s everyone’s job. Every single person can do something to improve this.
If you’re customer support, perhaps you build a series of email onboarding templates to send the user immediately post-signup. Then you start testing the timing of this series (ideally using data to inform your hypothesis). If you can’t do this because you need someone technical to help with creating the templates, you just suck it up and do it manually.
If you’re a marketer, with a technical skill set, perhaps you figure out a way to help the person sending customer support emails to send them faster using automated tactics such as scripts to better sort through an inbox.
If you’re a designer, perhaps you go usability test around onboarding.
If you’re an engineer, perhaps you start mapping out the minimum viable way to test a design hypothesis while still getting a conclusive result.
If you’re none of these and think you’re off the hook, you better think again. You hop in customer support and you start lending a hand sending off onboarding emails manually.
Late Afternoon
With a list of priorities agreed upon and a list of tactics within these priorities outlined per team member, you create a shared document that notes precisely what time all of these things go live. Whenever anyone puts something into the world to help improve onboarding, they note the date, time and a brief description of the tactic — this way you have a much better shot at tying specific actions back to either increases or decreases in retention. Ideally, you already have a sprint cadence in place, and you establish consensus on all that’s to be done (and who’s responsible) in the next sprint in order to resolve this problem.
I mentioned that I’m happy to go on record saying whoever owns customer support in the early days should be one of the most well-paid people in your company. Sure, there’s the Steve Jobs rebuttal if you’re one of the few that’s able to offer products around a need people never realized they had, but for most of us, the customer has 95% of the answers. What the customer says should be the lifeblood of your roadmap and whoever is owning that holds the key to growth.
Mastering the stages of growth is hard (the first stage being product-market-fit), but the roadmap for getting there is simple. As with most things, it’s executing that’s the tough part. Steady growth comes down to commitment and discipline around focusing everyone’s time on improving your North Star metric — and that’s too lofty a goal to leave on one person or a few individuals. The truth is, establishing a way to (a) capture, quantify and prioritize customer feedback (b) socialize these insights to the greater team and (c) create and commit to a roadmap that resolves your customers’ most pressing needs isn’t a “one person” or “one department” job — it’s all our jobs.
If you’re still reading this, thanks a lot, but you should probably be responding to customer emails.
