Product and growth principles.
Things I carry between businesses: from product growth at Meta and product leadership at Contentsquare to building independently. The context changes; these are useful questions to keep asking.
Understand what is happening before choosing a solution.
A request for more acquisition, a new feature or another dashboard is a starting point, not a diagnosis. Look at behaviour, customer value and business economics together. Find the constraint worth changing, then compare the possible ways to change it.
How I approach a growth diagnosis ↗Prioritise opportunities and potential solutions, not just a backlog.
A well-ordered list can still contain the wrong work. Compare the scale of the opportunity, the plausible impact, the cost and what remains uncertain. Planning should result in choices about investment, resources and goals, not simply a more polished roadmap.
Connecting evidence to strategy and investment ↗Judge the work by its impact on the outcome.
Releases, dashboards and experiment counts are activities. Define the outcome and the evidence needed to establish whether the work improved it. Use properly designed experiments where they can answer the question, and other evidence where they cannot.
Why more experiments do not always mean more growth ↗Give people ownership, not just requests.
Good people need to understand what they are working towards and have the ability to act. Develop their judgement, connect disciplines and make dependencies explicit. Reviews should help teams make decisions and change the work, rather than turn them into a reporting service.
What I learned in Facebook’s cross-functional teams ↗A working product is evidence, not proof of a business.
Building directly with AI makes it possible to test ideas quickly. It does not remove the need to understand adoption, trust, distribution and economics. A useful prototype helps expose those assumptions; technical capability alone does not settle them.
What building a dispute-resolution product taught me ↗