I’ve been advised to hone my ‘product intuition’. How do I do that?
Answer by Merci Victoria Grace, former Director of Growth Product at Slack
Product people are obsessed with product intuition, and we’ve ceded it to the small group of people who’ve been anointed as product visionaries. This is evident in how we speak about product intuition — as if it’s an innate trait that people either “have” or “don’t have” rather than something that anyone can develop. I rarely hear from PMs or founders about the steps they’re taking to build their product intuition in the way that people build technical or design skills. Anxiety about whether we have it is rampant.
Let me help you find you a different approach.
Product intuition is a skill: it is the observation of human behavior, trained by data, and applied to software.
Yes, product intuition is necessary to find product/market fit in early-stage companies and to develop successful product-led growth teams at expansion-stage companies. But before I expand on this further, I want to establish the table stakes for developing product intuition: the product hierarchy.
The Product Hierarchy
The process of building product intuition starts with filling in your product hierarchy. I chose a hierarchy because you need the widest and deepest base of knowledge where it matters most: your customer. The behavior we associate with great product intuition is quickly intuiting how customers will react to software — you need to know a lot about how your customer thinks and their real life concerns to get there.
Your customer is the foundation of the product hierarchy because this is where gravity needs to take you when you’re tired or lost. If something isn’t working, go back to the assumptions you’ve made about who your customer is first.
For startups grinding out 0–1, this person is your early core customer. This is not everyone — even if you aspire to create the next Facebook or another product that eventually, yes, everyone will use. Facebook started with college students and didn’t expand past that until they had product/market fit.
Slack started with knowledge workers at small startups and later expanded to knowledge workers at large enterprises. We never built features to support the social use case, despite clear emergent behavior showing that knowledge workers also use Slack for interest and friend groups. Knowledge workers engaged in work are Slack’s customers; moreover, it’s really knowledge workers pursuing a shared goal at work with others who are the customer. Be that specific. You can expand your Total Addressable Market (TAM) organically later, but if you never find your initial product/market fit, you’ll never have the opportunity to do so.
The next stages unfold from knowing your customer: choose the problems or opportunities you’ve identified that you want to solve; understand their use cases and the environments in which they’re encountering these problems or opportunities; then develop features or products to meet those needs and test test test. Try to prove yourself wrong rather than right.
I’m starting here because this process is often the opposite of what we do when we’re developing product. We tend to start with an idea for a product or feature, then try to find use cases for it, then from those use cases, we intuit which problems we’re really solving, and finally, who may want to use or buy this product.
The Product Upside Down
Does this feel familiar? This is how you get to market with a solution almost no one was looking for.
This approach isn’t wholly bad: you’re often starting with a product idea because you have some product intuition already. You may be your own customer or have worked at your company for a long time. But you are not everyone, are you? Begin by understanding your customer first and you’ll keep an open mind rather than jumping to a solution or using data to justify ideas you already have. You’ll also figure out how you’re different from your customer and let their reactions (rather than your opinions) train your product thinking.
In order to learn, you need quick feedback when you’re wrong. Feedback comes faster by understanding your customer and testing your assumptions than by launching a product no one wanted and blaming it on the marketing team. 🤷
Methods for Building Product Intuition
You’ll apply different methods for training your product intuition depending on what stage of product/market fit your product or feature has reached. A growth-stage company likely has enough volume to run multi-variant tests; a small pre-launch startup won’t.
This framework can be applied whether you’re creating your first product team, starting a company, figuring out a new feature, or starting a product-led growth team at an expansion-stage company. Great companies are always focused on understanding their customers and serving their needs. (In that order.)
At an early-stage company, some combination of a Product Manager or CEO, engineer, and designer will be responsible for developing your company’s shared product intuition. I also recommend hiring a contract user researcher to help you run unbiased user interviews and usability tests. It’s too easy to ask leading questions when you want to be right.
At growth-stage companies, data science, user research, product marketing, and product management are the specialists who are responsible for this. But at all stages, you need a product development process that supports coming back to the first principle: What do we know about our customer?
Learning about your customer
Define who your customer is and be specific. Where do they live? Find and interview them, ideally in places outside the SF Bay Area. Read books about the demographic — social scientists and researchers like danah boyd, Sherry Turkle, and Rachel Sherman are your friends. Listen in on sales calls. Listen in on conversations in cafes. Watch youths on their phones or dig through YouTube. Buy or conduct market research. Run surveys. Write down the assumptions you’re making and try to disprove those. Above all else: keep an open mind.
Understanding their problems
Watch your customer using other software in the same space. Throw together quick mockups or low-res prototypes and show them to people who fit your customer constraints. Interview those people about their lives, even if they’re not customers yet… especially if they’re not customers yet. If you already have an existing product, how are people patching the holes in your functionality? Give your data science team time to find correlated behaviors.
Articulating a use case
Implement analytics software to understand how people are using your product. Develop situational hypotheses and test them. Make device-specific guesses and try to test those, e.g., how does this behavior change when it’s on a mobile device? Again, if you don’t have volume, put together a prototype or low-res mocks and show them to people. Surprisingly strong themes emerge from low fidelity testing.
Developing a solution
Scope down your solution so that you’re only testing the hypothesis you mean to test. Constrain your solution to just satisfy the needs or solve the problems of your customer, or you’ll muddy the waters.
Rinse and repeat
This process can take place week over week or even in the course of one day. Moving quickly at every stage is vital. Your company’s funding is not your runway or salary: funding represents the number of learning cycles you have time to execute. Make the most of it.
Some other resources
Amy Jo Kim’s new book Game Thinking is insanely good. It’s my new answer to product people who want to learn to build engaging products. If you want to get deeper into the principles of game design and how they apply to products, Dan Cook’s Lost Garden blog is also awesome.
I send Social Capital’s accounting for growth series to founders on a weekly basis. This series is described in terms of the diligence SC does before investing, but it’s also an incredible primer on understanding engagement and retention.
I hope this was helpful. Feel free to direct message me on Twitter with thoughts, or if you’d like help thinking through a specific problem.