💡 There is no finished state to Product building. There is only one state - “Always be growing”

In Part 1: Fundamentals of Growth we covered some of the basic principles for growing your audience and in Part 2: Growth Platform we went over a collection of tangible foundational tools - Data Platform, Notification Platform, Experimentation Platform that can help grow your users in a sustainable fashion.

Hopefully so far you started to observe the ownership line between building and growing the product blur away and transform into an continuous iterative process owned by the same team.

In this part I deep dive into the iterative product lifecycle where the fundamentals of Growth are embedded from the outset to fuel the product as shown in Fig 3.

fig3-building_iteratively.png

Always be growing

Each feature release represented as a circle in the fig above is intended to acquire more users while continuing to retain existing users thereby growing your user reach. Feature release can comprise of smaller rollouts released as controlled experiments that help you know more about your users, reach new and existing users in a timely fashion and ultimately impacting the company bottom line metric.

This release process is standardized and consistent across the product teams and runs in cruise control through an efficient Growth Platform that underpins the fundamentals of Growth.

How does the company benefit from this?

Any motivated product team seeks for a high degree of autonomy to explore new ideas, be creative and push boundaries in their day to day operations and with autonomy also comes accountability to the company bottom line and demonstrate path to profitability. That’s the operating north star for the company to achieve - Autonomy with Accountability

Example: Zetanews

Rather than ramble on with more concepts to explain this let’s take an example of a fictitious company, Zetanews that lets users create a profile, discover and share news posts for free and a paid subscription to comment on news posts.

Bottom line metric

The only bottom line metric the entire Product team is ultimately responsible for is growing the gross margin, i.e. revenue after cost of production.

Product Organization structure

fig4-zetanews.png

Operating Model

Decentralized Product teams map to the core surface areas that user interact on the Product.

  • User Profiles: user sign up, profile, stats and settings.
  • Home feed: landing page when you login to the app.
  • Search and Discovery: search and discover new posts for logged in and out users.
  • Composer: The post composer flow for creating posts.
  • Engagement: Building engagement flows such as commenting and sharing.

Each of the product teams above are tasked with building a delightful user experience for their surface area - autonomy while ensuring that they are contributing to the company bottom line, gross margin - accountability

Centralized Growth Platform team team managing the core services that enables product teams to know their users (data platform), reach their users (notification platform) and do this in a sustainable manner (experimentation platform) and show sustainable positive impact to gross margins built on top of the core platform and infrastructure.

All teams are staffed with cross functional expertise containing Product Manager, Engineers, Marketing, Design, Research, Data Science.

In practice this is what the operating model should look like if done right. Each of these operating model principles can use a write up of their own which I’ll save for a later date

✅ Do’s

  • Individual product teams are constantly shipping new features by learning what is and not working not just for their surface area but also towards bottom line growth for the company.

  • Entire company rallies around a couple of tangible metrics that make a meaningful impact to user value and the business.

  • Data is truly democratized and there is transparency and quality controls on the entire ecosystem of metrics.

  • 80% of the time is spent on building the core product features and the remaining 20% is spent growing the users almost running in cruise control.

  • Experimentation and Learning is embedded in all product releases.

❌ Dont’s

  • Teams are not silo’ed working on specialized Growth areas like acquisition or retention but instead divided by Product surface area and responsibilities.

  • Teams are not growth hacking their way chasing niche metrics for their surface area.

  • Teams are not spending cycles asking - can I trust this data or where is this data?

  • Teams are not drowning in roadmap planning, creating OKRs and decision frameworks and adjusting to reorgs.

  • Experimentation is not just for the Growth team.

If at this point you are thinking all of this is a no-brainer and obvious then you’re right.. it is but somewhere along the course of traditional Product building we repackaged Growth as a special expertise that and split it up. It’s time to bring Product and Growth back together!

💡 and if you’re still considering spinning up a new Growth organization in your company ask yourself what and why is it that your Product team is unable to do that a new team can to scale the product.