“Growth Hacking” is simply advanced Product Management
The phrase “growth hacking” is getting a lot of press in the startup community, including this recent post “What is Growth Hacking really?” by Josh Elman. The more I study the meaning of the term, the more convinced I am that growth hacking is a new role for what product management should already be doing. Product management has become a misunderstood role in many startups, where it is often miscast as a cross between a manager of the software development team and a traditional requirements analyst. If product management were achieving its own objectives, the “growth hacking” would already be happening.
Product management isn’t project management. The agile manifesto has helped software companies improve upon a historically lousy rate of success in building software, but one of the victims it has left on the side of the road is the established role of product management. As engineering teams have adopted agile processes, the product manager is often asked to simultaneously serve as product owner. Since agile teams want the product owner to be accessible at all times, it’s difficult to have that same person out in the market getting the voice of customer the product so desperately needs–hence, the product management suffers.
Startups often hire product managers to be product owners. Since the product owner is in the room helping engineers point user stories, they’ve identified that someone else needs to be performing the business side of product management that is missing. Hence, “growth hacking.”
What is “Growth hacking”?
Growth Hacking was coined by Sean Ellis as a term for driving product adoption through data-driven experiments. The core concept is once product-market fit is established, to identify the “must have experience” and drive the business around that. For an experience to be must-have, it must be different, and Ellis suggests that expanding upon that competitive strength is the way to drive market adoption of a growing startup.
Andrew Chen drew a lot of attention to the topic in a post in April of 2012 and defined the term as follows:
Growth hackers are a hybrid of marketer and coder, one who looks at the traditional question of “How do I get customers for my product?” and answers with A/B tests, landing pages, viral factor, email deliverability, and Open Graph. On top of this, they layer the discipline of direct marketing, with its emphasis on quantitative measurement, scenario modeling via spreadsheets, and a lot of database queries. If a startup is pre-product/market fit, growth hackers can make sure virality is embedded at the core of a product. After product/market fit, they can help run up the score on what’s already working.
This is a more technical toolset than many product managers employ. Product managers in enterprise B2B companies also have to think about requests coming in from current customers and sales, which contribute to voice of market but of course don’t fully define it. They often visit customers, prospects, nonbuyers and conferences to better represent the market. But many of them don’t “experiment.”
Why are many product managers NOT growth hackers?
Software companies often subscribe to a false set of beliefs:
- The product manager should know what to build before the team begins to execute, otherwise engineering time is wasted.
- It is possible to know what needs to be built next without gathering real experiential data.
- The solution itself does not influence the priority of what’s most important next.
- Prospects are more likely to buy if they think the vendor “knows what it’s doing,” and therefore a longer more detailed roadmap will help sell more product.
The idea that A/B tests or other experiments be built into a software product goes against the belief that product management can, and should, “know” what is the next most important thing. For product management to advocate experiments, or even the Lean Startup concept of “build-measure-learn,” means they must admit they don’t know everything. This becomes especially challenging with a sales organization culturally predisposed to “fulfilling promises” and avoiding “schedule slips.” Those concepts don’t fit well with business agility.
Time spend building data gathering capabilities is time not spent building features customers will pay for. Customers won’t buy your ability to A/B test, but they will buy a feature you optimize through data gathered from an A/B test. This delayed gratification isn’t easy for some companies to accept.
Once a product is used by customers, it influences their workflow. That influence may cause or emphasize new problems that weren’t recognized before the workflow was influenced by the new product. A company which proudly claims to know what it’ll be building a year or two from today is one that doesn’t recognize that the world changes faster than that.
Ideally, in a company where “not knowing” is culturally acceptable, a product manager should be advocating the inclusion of data-gathering techniques within the product development life cycle. When moving into greenspace, this may need to be at the very beginning of the effort. If moving into a known, competitive space, time-to-market may require reaching the market with MVP (key word “Viable”!) and then adding data-gathering capabilities at a later stage to drive the next phase of growth.
What is Product Management, then?
Product management is a business role in established companies which is measured by market success of a product or product line. It is the ownership of a product idea from inception to sunset, requiring among many other things an understanding of drivers of growth, profit margins, and the ability to document the case for investing in a new product idea.
Product management evolved from brand management at consumer product companies like P&G, and has market success of the product or brand as its KPI. It’s usually introduced into startups when the founder can no longer personally drive product development, because of commitments to fundraising and many other business building items. The role at its infancy may lean towards engineering management, but it’s a mistake to think of it is as simply a product development role.
Marty Cagan defines the product discovery team as the product manager, lead engineer and user experience designer. Product managers understand the business value of solving a particular market problem, interaction designers specialize in how to solve it, and engineers specialize in feasibility. Thos three people drive optimal solutions. For software companies of all ages and sizes, the shift in the role of product management is towards solving real market problems better through direct customer interaction and data gathering. Product managers need to keep pushing the envelope.
The product management role has traditionally included two roles:
- Product Management: The inbound marketing responsibilities to understand the problems being experienced by the customer base, down to the specific personas and market segments having the problems, and guiding the development of a solution to those problems.
- Product Marketing: The outbound marketing responsibilities to guide communication and messaging about those solutions and their benefits through the rest of the company, primarily through marketing and sales.
In recent years, a third role has become part of the family: User Experience Design. Interaction designers help refine understanding of the exact problems a user is facing, and excel at optimizing the solution to those problems to provide a market-leading solution. The trend for products with great user experience to overtake products with average UX was first seen in consumer products, and is now moving to enterprise products.
In the 21st century, product management is becoming a hybrid. Business and market success can be guaranteed not just through market research and checking the box on features, and not just through picking the right market segments and building features to address the personas in those segments, and not just through the right messaging. It requires delivery of a targeted solution that provides the optimal solution for the user. That targeting requires data.
Product Managers Need the Freedom to Experiment
Product management is focused on solving real problems that buyers will pay to solve, and ensuring profitable delivery of that solution. Success of late requires a captivating user experience. Web products will be captivating if concentrated attention is paid to the user experience, and thus by default will already be focusing on optimizing the “must have experience.”
Both product managers and user experience designers need to be thinking about the kind of usage data that will help with decision making, and built it into the product. They need to get the user to provide actionable data while using the product, not just from conversations around prototypes and vision statements, in order to move a solution from good to great.
Add on a layer of experimentation to what we already know as product management, and isn’t this the definition of growth hacking?
