Does your tech startup aspire to be a product-led organization? If so, you need to know this.
Press enter or click to view image in full size
I believe product-led growth starts with the way that you build your software and engineering teams.
Before I go any further, let me pause right here to explain what I mean.
What is Product-Led Growth?
According to OpenView Partners, product-led growth is a strategy that focuses on the value that end users find with your product to drive acquisitions, conversions, and expansion. The product itself is at the core of all organizational decisions, and the goal is to design it so it answers all of your users questions and needs.
As this Pendo blog post puts it: “The product is not just one part of the customer experience; it is the experience.”
Examples of companies that employ a product-led growth strategy include:
Currently, I’m a senior software engineer for Gearflow.com, which is the first transparent parts marketplace designed specifically for the construction industry. As a seed-funded startup that is assembling its engineering team and its operational culture, this is the strategy we are framing our business around.
And its foundation lies with the software development team.
So how are we doing this?
Thankfully, there are many resources out there to help us learn from the examples of others.
If you’re also looking to create a product-focused startup, here are the top four resources that helped me shape my views on how to get started. Hopefully you’ll find them as valuable as I did.
Zach’s Engineering Handbook
Zach Lloyd is the former principal engineer at Google. He has written extensively about his experience as a leader in the tech industry.
His blog documents the processes he’s used throughout his engineering career.
Lloyd’s thoughts on the two types of engineers have helped us frame the hiring process to identify which candidates would fit well within a product-led organization.
This is how he describes these two engineer categories:
“There are programmers who care more about code, and there are programmers who care more about product. The former — I’ll call them “code-first” programmers — are obsessed with how code is architected, what tools, libraries and languages are used, how much test coverage there is — stuff like that. … The product-first programmer cares about that stuff too, kind of, but only as a means to an end. For product-first programmers, the code is the scaffolding, the support, the steel beams in the building, but not the end product. The end product is, well, the product, not the code, and what matters to them is how well that product actually solves the underlying problem.”
Product-first engineers place more value on the function of the product than on the pieces (i.e., code) that create the product. According to Lloyd, they care about answering questions like:
“Does the building stay upright? Do the elevators work? Is the A/C functioning? Do people like being there? Product-first programmers love building and launching and seeing users use what they’ve built. The product is the thing.”
It’s a privilege to be able to get paid to write code, but if you are pursuing product-led growth, your engineers should not merely exist to play with all of the newest tech toys or flex their coding muscles by spending days in search of the perfect abstraction. Their objectives should focus on creating answers for their users’ problems and to build a business around those solutions.
If you want to foster an engineering culture that puts the emphasis there, you need to hire software developers that are passionate about whether what they’re producing truly meets the needs of your users.
Basecamp’s Shape Up
Basecamp has lifted the lid on their product development process, basically making it open source for organizations to implement for themselves.
Their book “Shape Up: Stop Running in Circles and Ship Work that Matters,” by Ryan Singer has been instrumental in how our startup organizes and prioritizes our roadmap. I highly recommend that aspiring product-led software teams read it.
For example, this book inspired us to introduce biweekly product-planning meetings and sprints.
In these meetings, the engineering and product teams discuss where engineering should spend their time that would have the biggest impact in the upcoming sprint. Everyone’s voice holds equal weight.
We’ve seen an increase in deliberate focus as a result of moving to these two-week sprints. Previously, the engineering team would be tasked with a nebulous feature request, then would work day after day until the feature was done. With such unclear acceptance criteria, this meant that on occasion, features were getting either over- or under-engineered.
Now, the entire team scopes out just enough work for the next two weeks, so at the end of the sprint we can measure what we set out to accomplish. Shifting our process this way has allowed our team to remain focused and act on the most important business outcomes first, rather than overengineering a solution that might not even be useful to our customers.
Silicon Valley Product Group
SVPG offers advice and insights from top Silicon Valley senior executives. They have a blog and workshops, but their book Empowered: Ordinary People, Extraordinary Products is particularly helpful in creating a product-led engineering team.
Their thesis is that it doesn’t matter how good your engineering team is if they are not given something worthwhile to build. Engineers will fail to thrive if they are given a meaningless list of features to build. They need to be included in the entire process — from planning to product strategy to implementation.
You want your engineers to be collaborating and coming up with ideas. This is how you build a product-minded org.
In a successful product team, all roles — including PMs, design, and engineering — contribute to deciding what to build. Not only does this increase the amount of valuable ideas that emerge, but it develops buy-in from everyone on the team. It lets your teammates hold themselves accountable to what they are building and gets them fired up about the solutions they are coming up with to solve the business problems.
In a product-led team, everyone needs to understand the business goals and their context. They are given clear objectives, and they own the delivery of these objectives. In turn, they feel responsible for their outcome.
Contrast this with the old project-oriented model, which is all about getting something pushed through the process and out the door.
Product-led teams are not off the hook just because something launches. They don’t rest until it’s working for the users and for the business.
The Mom Test
As we learned from SVPG, an empowered team that creates product-led growth involves not only PMs but also engineers to question product decisions and get involved in customer research.
The Mom Test is a short, insight-packed book detailing how to effectively garner user feedback when your users are usually (intentionally!) lying to you. It’s an important read for both PMs and engineers alike.
Everyone knows that talking to customers is important, but oftentimes we aren’t asking the right questions. A common mistake is asking leading questions that narrow the customer into a particular answer that they expect you want to hear. Not wanting to disappoint you, they will give you the answer you want, rather than the answer that is true to their actual actions.
The Mom Test taught us how to reframe the questions we are asking our customers to help gather actual insight, rather than fluff that falls victim to confirmation bias.
Additional Resources
These are not the only resources that have influenced my perspective on building product-led teams.
Others include:
- Jeff Patton & Associates
- Melissa Perri’s blog and her book Escaping the Build Trap
- Teresa Torres’ blog and her book Continuous Discovery Habits
What resources have you come across that are particularly helpful in shaping a product-led culture? I’d love to hear. Please comment below.