Early Lessons in Product Management — Part I
I have this problem of tying everything with a higher cause, to feel a sense of purpose in whatever I do. And working in Product, I kept on contemplating on how this role would suit this mindset the most, until I landed on the one of the most beautiful definitions of a Product Manager. Christian Idiodi, partner at Silicon Valley Product Group, defines the job of a PM as to wake up on behalf of someone else and solve their problems for them. And that you solve it so beautifully that they give you something back in return — be it engagement, conversion or loyalty.
I’m sharing 5 lessons I have learnt as an early Product Manager, with customer app in focus.
1. Prioritisation is key
Not everyday is about strategy and brainstorming, but everyday is about prioritisation. And I say this because its necessary to know that everyday is chaotic, more often than not, you’ll find yourself spending time firefighting, making SoPs for internal stakeholders, documenting your findings and extracting data. Every hour you spend on a problem comes at an opportunity cost of you solving another problem; so choose wisely, your time is actually precious.
2. Keep Big Numbers for All-Hands — focus on solving for smaller cohorts
We have a habit of looking at the big picture, at aggregate numbers, our DAU/MAU ratios, month-on-month retention and the overall conversion funnel; and while that is good for periodic reviews, it shouldn’t be our go-to deck. I learnt this early on by reading The Cold Start Problem by Andrew Chen. While working at Uber, Andrew talks about how all metrics were focused on hyperlocal “networks”, that could steer decisions on where interventions were needed: marketing budgets, incentive structures for ground teams, product enhancements or core operations. These networks can be defined as cities, segments/personas or a mix of both. So whatever problem you’re solving, always know which cohort it is being solved for, and why, so that it is easier to strategize for where the feature does not work.
3. Don’t be too rigidly data-driven
Perhaps one of the best soruces of great product stories are those that stem from the COVID-19 era, when alot of companies had to face a setback due to the very nature of business they were running. One such example is that of Airbnb, which was in an existential crisis as travel was banned, and living in a strangers’ house during covid was next to impossible, leading to a decline of 72% in Y-oY revenues compared to 2019.
At this crucial stage, Airbnb took 2 pivotal decisions:
a) Curated and pushed people towards local stays that were great bunker locations for the pandemic
b) Initiated their Online Experiences segment, offering experiences to their users from their very homes
My point here is, more often than not, a PM is navigating through ambiguity, not strategy. There are situations that don’t have any answers, let alone the right answers. If these situations demand urgent decisions, focus more on what the core of your business is, what the customers truly want from you and how can be delivered timely.
When a decision is urgent, data should almost always take a backseat to intuition. When the decision is extremely important, data should be used more diligently to validate assumptions and keep intuition in check. — Robert Yi, CEO of Hyperquery
4. It’s ok if your feature doesn’t work! Dont be too risk averse
With every feature you build, there are four apparent risks involved:
- Value risk: Will users find value in this feature?
- Usability risk: Is this feature user-friendly? Is there a better alternative that can solve for its usability?
- Viability risk: Is it viable for the business? Can better alternatives be explored that are more suited to the company’s business model?
- Feasibility risk: Is it feasible to build it in the way it has been technically conceptualised?
As a PM, two of these risks should be catered to at the very core of problem solving — value and viability. Value risk is the most important and often the most overlooked, because we tend to assume our solution will solve the problem without asking whether it actually generates the value our users truly want. Second is the vaibility risk; for you may create value generating solutions, but they may not yield long-term benefit to the business model.
5. Pro tip: become full stack
One philosophy I hold dear is always asking why. As a PM, this enables you to learn deeply about the business model, its main functions (operations, sales, supply chain), the current limitations the system has, how it impacts your customers as well as internal teams to run their daily processes. Moreover, it empowers you to question your own assumptions, forcing you to think deeper and devise in-depth answers. Just be wary of not being stuck in the analysis loop, rather knowing when to stop questioning and start building!
Sources: