AMA session on Product Led Growth with Rory - Head of Growth at Supabase ⚡️

@nkosanamabuza Ant and Copple, our co-founders, deserve credit for our earliest users, and they played a significant role in discovering what developers want by engaging with our existing network. Our early team (myself included) all have a technical background, which gave us a deep understanding of our users' needs. This has really influenced part of our core philosophy around dog fooding features based on knowing our needs as developers. In the early days, there is no substitute for speaking to as many users as possible. I recall spending a weekend going through over 3,000 developer profiles on Github after had a sign up spike, reaching out to as many as possible to chat with them about their Supabase likes and dislikes. I have found that taking a 'mom test' [1] approach to understanding what users value and the 'jobs to be done' [2 ]framework are both valuable resources when engaging with users, particularly when trying to comprehend what developers are attempting to achieve. Moving from users to first paying customers involved a lot of calls with users to get feedback and start to segment our users and build out ideal customer profiles before landing on initial pricing and opening up basic self serve billing. [1] https://www.momtestbook.com/ [2]https://jobs-to-be-done.com/what...

@nkosanamabuza @rors great story! > In the early days, there is no substitute for speaking to as many users as possible. to quote @paulg: "do things that don't scale."

@edworking This is a great question, we actually don't use any paid ads at all. We have several things that we have found to be effective. 1. Our "launch week" strategy [1] has really been essential as we scaled up. Once every 3-4 months we spend a week shipping a new feature every day. This has been great for both internally to align the team and getting traction within the community. 2. Post launch week, we have a pretty amazing community who make content around these new features for their own audiences. We try and amplify their content within the community. We have a truly amazing devrel team who help enable and engage with the community as much as possible. This is also a huge source of product feedback which helps shape future launch week features. 3. Our monthly email newsletter. We try and send as few emails as possible because we are keen not to spam folks. Our monthly community email newsletter has strong engagement and showcases all the big monthly updates from the team and the community. 4. The less visible / internal operational side of growth which means we can stay aligned as a team and know how to engage with our users. This really comes down to good internal tooling, data pipelines and processes. [1] https://supabase.com/blog/supaba...

@gikashin1973 PLG is an evolving discipline - Kyle Poyars blog [1] is a really good resource and a shout out to the folks at Toplyne [2] too Pocus have put together an amazing slack community too for product led sales minded folks [3] [1] https://kylepoyar.substack.com/ [2] https://www.toplyne.io/blog [3] https://www.pocus.com/community

@rahulkrishnan_tl Growth at Supabase is definitely a team sport - and it's not just constrained to the "growth team".....Engineering are heavily involved with all things related to growth. Without a solid product that solves a need for people it's pretty hard to grow anything. A lot of this comes back to iterating based on good feedback loops with our community. My role in Supabase has definitely changed since the early days. Initially I started by needing to wear a lot of different hats depending on the challenge at hand. Today i'm spending more time thinking about how to keep the team aligned and co-ordinated so our users benefit from a more joined up experience. This is usually a combination of tooling, processes, people and data. We usually hire based on problems that we need to solve for and i'm incredibly lucky to work with a whole bunch of folks who are exceptionally good at what they do. We definitely have processes and playbooks to templatize this but like all things in a startup, its a work in progress. Another thing to shout out would be sequencing on picking which things to templatize. There are a lot of things we know we need to standardise but there might be something else that needs to be tackled first. This really just comes back to effective internal communication between teams to set priorities. Codifying a brand.....that's a tough question. I think the brand has really been more of an emergent property which again came as a result of looking at our marketing as a bunch of little experiments based on interactions with the community. There are some things we do at a brand level which I think are well known with developers - don't pester them with spammy emails, give them useful content, be transparent etc. There is some other more off the cuff stuff around community interactions which is where meme master Ant comes in and that is definitely harder to codify.

@rahulkrishnan_tl @rors > Without a solid product that solves a need for people it's pretty hard to grow anything. all starts with a great product. QED. thanks, Rory!

@arjun_rakesh_k_o Copple and Ant do a great job on the leadership front to communicate priorities across the company. The teams are themselves usually figure out the actual solutions to some of the challenges and feature priorities that we focus on. Usually a few weeks out from launch week we will look at how the teams are progressing on the major things we have identified as priorities and make a judgment call on how shippable they are. This isn't just "does the feature work" - we think about documentation here because without good documentation it's harder to use the product. We also ship things every month so we don't necessarily hold features back for launch week - we just try and ship and shout as much as possible. Being async really helps a lot here as it's quite easy to facilitate the movement of information around the company (slack, github, notion, a lot of RFCs, and video recordings). When it comes to the content side of things things are currently a bit more fluid. I would love to say we have all of this ready ahead of time but it wouldn't be unusual for a blog post to be finished an hour before a feature goes live. This has been happening less and less as we get more experience around launch weeks.

@aquibbaig This one is a bit harder for me to answer compared to others in the team as it sits a bit more inside engineering. Inian and Copple have some "product principles" that the team use as a guiding light when making decisions that are geared towards enabling the team to move as autonomously as possible.

@gayatri_gaidhani 1. Tech twitter is pretty buzzing and it's amazing how willing folks are to engage on there. It's an extremely valuable source of feedback for us too. 2. IMO this comes back to building useful features (which are stable enough for release) and good documentation. Supabase is a developer tool first and foremost. If we get these things right folks want to build and showcase the problems they can solve. Also, because Supabase is Postgres under the hood, a lot of the time we are just helping folks get more out of a database which is already amazing. p.s obviously we are big fans of Toplyne too :D

@souvik2003 User onboarding and activation is definitely an interesting topic.....Wes Bush talks about "product bumpers", "conversational bumpers", and "empty states" [1] as a good starting point. I would say activation starts really before the users even start using Supabase and relates to the product decisions we make. Downstream from this, content and examples coming both from our own devrel team and the community are essential here. If a developer can clearly see how our developer experience can help their workflow then using Supabase becomes an obvious choice. Developers have a lot of different jobs to be done and at this point Supabase is a diverse tool that can be used to solve many problems for developers. Solid fundamentals are key here - content, examples, and solid documentation geared getting developers on a straight path to achieving their objective. Feedback for us comes from a whole bunch of sources: community (which includes twitter, github and other social sources), support tickets, calls with our users. We also have a feedback widget in our dashboard and occasionally run an exit survey if someone deletes a project. As our user base has grown exponentially, the feedback has too. We are still iterating around the best process to triage, prioritise and route it to the right team. We regularly review all the feedback that comes in and factor it into the decision making process for each of the feature teams. The product teams at Supabase take a lot of ownership over the features they are working on as experts in their own product and review feedback weekly during the team syncs. We also make a lot of use of notion to facilitate getting information moved around to the team. [1] https://productled.com/book