Alex spent 7 years of his career in building products for start-ups that eventually failed but at the same time he learnt a lot from that experience. He worked as a Growth Product Manager helping in referral programs for 30+ global e-commerce brands and finally switched to Mozilla, where he used to manage application services and working with sync team, getting people to sync their devices, data storage, cloud encryption, push services eventually he got the opportunity to evolve and learn the differences between Product Management and Growth Product Management.
We invited Alex for a Product Talk with Pragmatic Leaders to understand the actual difference between a Product Manager and Growth Product Manager
We started with a question”What is a growth team?”
According to Alex, a growth team is a cross-functional team that focuses on growth pirate metrics which are: Acquisition, Activation, Retention, Referral, and Revenue. He says a growth team focuses on scientific methods that follow a process starting from making an observation, doing user research, formulating the hypothesis, running tests and experiments, analyzing results and with every conclusion we make help us create a new hypothesis.
Further moving on to the specific role of the growth product manager, Alex says, he is the one who prioritizes the experiment backlog. (ICE or RICE scores), document the hypothesis and experiment details before and after and is the one who reports results so that everyone in the company can learn from them. He adds a growth product manager must create a playbook of all the learning he acquires. This will become an asset for the company in the long run. Alex believes, that it is not the experiments in which he failed but the one which he didn’t which led him to deploy something bad for the users.
We then asked, how is a Growth Product Manager’s role differs from that of a Traditional Product Manager?
Alex says, Traditional Product Managers do idea management, where product road-mapping can go from 6 months to 2 years or more, prioritization has been done and they focus on delivering and capturing user feedback. However, he says that these roadmaps are not free of presumptions and biases. The role of a growth product manager is to minimize these biases to ensure sustained growth of the product in the long term. To read more about how a Growth Product Manager’s role differs from that of a Traditional Product Manager read Alex’s blog- Product Management 2.0: A growth strategy but he was wrong…
In the initial years, Alex believed that roadmapping was a waste of time and didn’t provide a lot of flexibility. “PMs don’t care about metrics enough, users opinions are too important when considering priorities, PMs always think they know exactly what to make (20 page PRD) and in the process end up making many assumptions!”
But he proved himself wrong. He says it’s not that simple too. it’s more complicated than that as both have their own strengths and weaknesses. He realized over a time that not every feature or improvement that you are shipping can easily be measured (e.g. security). and lack of roadmaps makes it difficult to communicate and to align multiple teams.
He says growth product management has it’s own shortcomings as they focus on short-term projects of less than 2-3 months duration which is generally not enough time to bring a product back from a slump. There are many things that need to be given due consideration while building a product such as what your business strategy is going to look like, how should you position your product in the market as compared to your competitors, how do you differentiate your product, should you going to compete on price or on functionality, etc.
Check out our video of this exclusive AMA for more
Some of the key Takeaways from Alex:
- Great reminder of why companies split product management and growth.
- Smaller features can leverage growth process more.
- Large features / enhancements
- Always show regular progress with milestones.
- All good product managers are obsessed with data / KPIs.
- You should always define success metrics beforehand.
- Continuously validate what you are working on. (e.g. POC, milestones, etc)
- Security should never be treated lightly even if it’s hard to measure.
