Earlier this week I participated in a webinar with other product leaders. During this conversation, I shared a rough outline of how I think about product development - specifically, what inputs drive product development?
It's easy to build product for the sake of it. After all, shipping code is fun. With that being said, you need sources of truth that drive the process.
What are your sources of truth as you build product? My key inputs are:
- Customer feedback
- Product Metrics
- Gut Feel
Let me explain how I think about these inputs below.
1. User Feedback (Unstructured, Anecdotal)
The first input for product development is user feedback, typically from two groups of people:
- Unpaid users (oftentimes new to the product)
- Paid customers (regular users who experience value on a regular basis)
The feedback that is delivered from these two groups is anecdotal and arrives in a variety of ways, like customer support (email), customer development calls (Zoom), and other ad-hoc mechanisms.
This channel drives a wide range of feedback. It's unstructured, messy, and can oftentimes be a source of rich insight. If you want to improve the core product, I recommend spending more time with paid customers. If you want to improve onboarding, spend more time with new/unpaid users.
I always say, "if we hear something once, it's an anecdote, if we hear it more than three times, it's a trend and we really need to start paying attention."
2. Surveys (Structured, Anecdotal)
If we move up the ladder of abstraction, the next type of feedback that drives product development is survey data. It's a mixture of quantitative and qualitative data.
Surveys can be a nice way to leverage your time and discover consensus from your users, but there's not as much richness compared to Zoom discovery sessions or ad-hoc emails.
I like using surveys to confirm or deny a collection of anecdotes I hear when chatting IRL with customers & users.
3.) Product Metrics (Structured, Evidence-based)
The next input is product analytics data. If you spend time digging into a tool like Mixpanel or Amplitude, you will see raw data for how users actually engaged with your product.
Unlike survey data or customer discovery sessions, you can see how people actually used your stuff. It's easy to say you will use a product in a particular way on a Zoom call, only to behave very differently after the fact.
Product analytics is a way to "trust, but verify" that what users told you is real.
4.) Gut Feel
The last input to product development is gut feel. There is a place for "gut feel" in product development, but I'd argue that this should be the earliest step in the product development process and you should try to prove your gut wrong.
For example, if you hear feedback from one customer, and you hear similar feedback from two more customers...should you pay attention?
In this scenario, you don't have material quantitative data to back up your position, but you have a collection of anecdotes. Should you proceed?
I would argue that you should seek to de-risk the process. Take your gut opinion and start digging around in the data. Schedule calls with customers and seek to understand their behavior. Show them screenshots and get feedback. Then build!
Startups vs. Big Companies
One final note - in an early stage startup with limited data (especially product analytics), you need to rely on qualitative sources of feedback more. This is why it's important to talk to users and customers.
As you grow, you can rely a bit more on the data, but you must always be ready to get on Zoom calls with customers. Because that's where you can find your next big break as a product leader :)