Exciting news!I am going full-time on Product Growth at the end of this month. Why did I do it?
What does this mean for you? Even better - and more - content. The 50+ hours a week I was spending on Apollo are now yours. Today’s PostOne of the most exciting parts of the Product Growth subscription is our paid Slack community. I’m really excited to be even more invested in this community now that I’m going full-time! Here’s 7 highlights of wisdom from the community already:
The community is the place for you to send me get resume reviews, cover letter advice, and cold e-mail advice: 1. How to pitch a growth role to senior leadershipCommunity member Jan Bisaga asked:
Here’s how community-member Stads suggested to respond: If I were pitching a growth role, I think I’d assume that’s already a given, and I’d focus on what’s distinct about growth vs. core product. I’d explain that whereas core product work is focused on creating new value, growth is focused on unlocking value you’ve already created but haven’t been able to capture. Often, growth is easier to experiment with and easier to measure, and therefore delivers more frequent successful outcomes that are small but compound quickly. You wouldn’t want to focus on growth if you haven’t yet achieved product-market fit, but once you have, it would be a shame not to leverage growth to squeeze the most out of everything you’ve built. Here’s what I would add: I +1 everything Stads said, and share my own structure for answering this question:
It sounds like this:
2. Does Apple show that A/B tests are overrated?Yes. I know that may surprise you. Let me explain… 80% of A/B tests are not successful, per experts like Ronny Kohavi. Given that, A/B tests do three destructive things: 1. They slow down ship rates by a factor of 5 You go from 100 to 20 ship announcements. This makes the team feel like it's not shipping a lot, because most companies graduate more than 20% of features they work on. Most companies do more like 90%. 2. They make it harder to plan beyond the next test You don't know which features aren't going to work, but you know it's most. So you don't build for 5-6 year visions for a feature. By then, you know many turns will have been taken that change your plans. Heck, that happens even when you plan quarterly 3. They add a latency to graduation A/B tests inherently mean you need to wait till key metrics get to stat sig. This adds a lot of latency to the overall process of moving towards a product vision. This is a subtle but very real cost I've come to appreciate more the more senior I've gotten. What's the antidote to this? Make PMs responsible for the bottom-line metrics, not the A/B test results. When you do this, you align incentives away from proving impact with A/B tests and actually moving metrics. Nevertheless, I still recommend you A/B test most things! I recommend you eat problem 3 for the sake of learning. But - you be generous with graduating things so that you can keep moving the vision forward. Don't have counter metrics that are too strict... Keep reading with a 7-day free trialSubscribe to Product Growth to keep reading this post and get 7 days of free access to the full post archives. A subscription gets you:
|
This week’s system design refresher: Top 9 Most Popular API Protocols (Youtube video) What is a deadlock? What’s the difference between Session-based authentication and JWTs? Top 6 ElasticSearch Use Cases Top 9 Cases Behind 100% CPU Usage SPONSOR US ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ͏ ...
Comments
Post a Comment