{29} Product Led Growth Startup
{29} Product Led Growth Startup
Featuring Mari Luukkainen, Justin Dorfman, Vala Afshar, George Moller, and Christian Blavier
Subsribe to The Daily Subset and develop the skills needed to build a strong product led growth startup.
Product: PLG
Mari Luukkainen
I agree that product should be the hero. In fact, I’m restructuring my newsletter to lead with a product section. While product discussions are often nebulous and philosophical, I’ll share my take on what “product led growth” means more concretely.
Following the daily product discussion, I’ll cover 4 pragmatic skills and tools needed for startup generalists. Many skills will be user-centric, such as design, UX, and front-end development. But small teams have many needs. I’ll also cover backend, marketing, sales, fundraising, planning, and more. 💫
Sales: Outbound PLG
Justin Dorfman
I’ve been talking to Justin lately about product led growth and trying to understand how sales fits into a more sustainable PLG strategy. Freemium offerings are very appealing. I’ve always thought about it more as a marketing+product play. You start by building a self-serve freemium solution. Then use marketing to drive people to the top of the funnel. If the messaging resonates, they’ll sign up for a free trial and later upgrade if they get value.
Listening to Tito describe outbound PLG as a sales function makes me consider the importance of a sales/CS role in the process. Having a “product liaison” is particularly important when “inventing a new category”. When you invent a new category, it’s hard to drive inbound interest purely from marketing. People don’t realize a solution exists to a problem they face, so they are unlikely to search for it.
It’s often better to actively seek out the people who’d benefit. Talk to them about the problem to make them aware of the pain point. Then offer a free trial without any obligation. If they use the product, monitor their behavior and try to help them get more value. Then sell.
Design: Beauty & Utility
Vala Afshar
I often advocate for a function-first approach to design. Start with a scrappy solution that validates the utility, then iterate on the design and UX. This bridge is a good counter-example to show that utility-centric design is not always ideal, particularly in cases where you can’t easily retrofit a design.
The designers of this bridge didn’t have the option to start with a boring flat design, then add the waves in later. They had to take a risk. A much more complicated initial design that involved a more complicated engineering process requiring more material could easily backfire. Maybe this bridge required a 5x budget. The result could easily be unhappy users because it takes more effort to cross the bridge. But the upside is much higher than a boring bridge. This has the potential to be a tourist attraction.
I know nothing about the economics or decision-making that went into this design. But it’s a reminder not to be dogmatic in your approach to building things. Be flexible and willing to experiment and break the rules.
React: Project Structure
George Moller
I often use NextJS, which has an entirely different structure. But if I were to work on a React app with this structure, I’d feel reasonably confident that I could figure out what is going on without too much effort.
It might take a little time to get used to this structure if you come from an MVC (model view controller) background. It’s not immediately obvious where the views live, for example. But I’m personally not a fan of the MVC pattern. It’s just not intuitive to me where code should live. MVC proponents will say I’m wrong, and it is intuitive. I’ll save that rabbit hole for later.
What’s important when organizing anything is to name containers as unambiguously as possible. The fewer containers you have to open to find something, the better. I can imagine scenarios with this structure where I might need to open 3 folders to find a file. But I’d probably find what I’m looking for in the first folder 80% of the time. That would be a much better success rate than many codebases I’ve worked on.
Analytics: Vanity Metrics
Christian Blavier
First of all, congrats to Christian for setting a personal record! 🎉
Previously, I’ve been critical of vanity metrics. Sometimes it feels like ALL metrics are vanity and data-driven decision making is just a pipe dream. More recently, I’ve become a little more liberal in my view. It’s not a bad thing if a lot of data is used purely as a behavior-inspiring game mechanic.
Instead of being frustrated by vanity metrics on dashboards, we should appreciate that these numbers bring people to the data. It’s then our job to surround the flashy numbers with deeper insights.