The following are my notes on some of Shreyas Doshi’s tweets. I’m not a fan of Twitter but I really enjoy reading his incisive content; hence these notes.
Why smart teams lead to products with mediocre/no impact
- Execution orientation fallacy:
- We make suboptimal decisions because we judge initiatives based off what we can easily execute today
- Eg: bias towards building small improvements over new products just because we can easily execute on small improvements
- Bias-for-building fallacy:
- Don’t take time to understand determinants of product success (eg. market, user needs, domain, competitors) because we bias for ‘action’
- IKEA effect for products
- Base current product execution on past product decisions, even though these decisions might be flawed
- Actual IKEA effect: people place more value on things which they built themselves
- Focusing illusion for products
- Any problem that you discuss with users feels more urgent than actuality
- You’re effectively ignoring other parts of person’s life, which are probably more important
- Maslow’s Hammer
- Use framework/skill/proxy in every situation, even though it might not have any utility
- ”When someone has a hammer, everything looks like a nail”
- Authority approval bias
- We devise plans/features/products based on expected approval from seniors
- Russian roulette for products
- Don’t account for situations which can have catastrophic consequences
- Onus on management to identify and correct
Good PMs, Great PMs
- Good PMs deliver quality products. Great PMs improve company trajectory via great products
- Good PMs take data-driven decisions. Great PMs take data-informed decisions
- Distinction? Great PMs will use qualitative data as well and will use either pieces of data when situation calls for a specific type
- Good PMs extensively research domain of product. Great PMs are world-class expert
- Great PMs, when bootstrapping product, will use counsel of world-class experts to become experts themselves
- Good PMs use user research for UI fixes. Great PMs use a variety of user research techniques for various different purposes. Most important: figuring out what to build
- Good PMs use data and logic to lay out their plan. Great PMs use people’s emotions as well, since emotions drive much of our daily decisions
- Good PMs know it’s important to talk to customers frequently. Great PMs know it’s important to listen to customers frequently
- They also know to listen what isn’t mentioned by customers and industry as well
- Good PMs inspire team with creative products. Great PMs encourages entire team to think of creative ideas, building passion and ownership within team to create excellent products
- Good PMs seek to validate idea with colleagues. Great PMs make it easy for colleagues to push back on idea
- Good PMs are detail-obsessed for product. Great PMs pays attention to entire customer experience, including support emails, docs, …
- Good PMs make convincing arguments for their view. Great PMs make convincing arguments for opposing views
- Good PMs write detailed PRDs, great PMs iterate on PRDs to prevent blocks
- Good PMs work hard but are overwhelmed. Great PMs work hard on high-leverage tasks, delegating everything else
- Good PMs converge on trusted set of tools to deal with any problem. Great PMs are more adaptive
- Good PMs sacrifice tech debt for customer features. Great PMs would advocate for reducing tech debt
- Good PMs provide thoughtful answers to execs in meetings. Great PMs would seek to reframe questions to undercover truth
- Good PMs deal with answers and data. Great PMs deal with questions and wisdom
- Good PMs are great problem solvers. Great PMs are great problem preventers and prioritizers
- Good PMs try to get optimal results for a strategy. Great PMs try to ensure they have an optimal strategy in the first place
- Good PMs can explain strategy in an elevator ride. Great PMs ensures entire team can explain strategy in an elevator ride
- Good PMs thank builders. Great PMs also thank enablers (marketing, sales, support…)
- Good PMs do retros. Great PMs do retros and shares lesson with other teams
- Good PMs get approval from all stakeholders. Great PMs get advice from all stakeholders as well
- Good PMs follow company product principles. Great PMs fix product principles before following
- Good PMs will do everything in power to meet team goals. Great PMs known when to sacrific team goals for company progress
- Good PMs are students of the PM career ladder. Great PMs care more about competence and impact
- Good PMs will deal with bad culture. Great PMs will leave
- Good PMs seek PM-driven cultures. Great PMs seek for product-obsessed cultures where all functions are treated relatively the same
- Good PMs learn about their craft through work. Great PMs will learn outside of work
- Good PMs achieve career success. Great PMs do this as well and get fulfillment by seeing success of team
- Take these as signposts rather than commands, as no-one can attempt all of this all at the same time.
Why Smart Organizations Make Stupid Mistakes
- Usually, dumb mistakes are not because of stupidity or malice
- Prevantable problem paradox: any complex organization over time will tend to incentive problem creation over problem prevention
- Why does this paradox occur?
- Saving the org after a problem occurs generates a lot more publicity and praise since it looks difficult
- Problem prevention looks easy, boring and get no acclaim at all
- Eg: would you rather watch a movie where captain hit iceberg and saved all passengers or captain moves around the iceberg, preventing the issue in the first place?
- How to prevent paradox:
- Create awareness of it’s existence
- Change team’s norms for recognizing impact to also take into account for problem prevention
- Embrace pre-mortems: https://coda.io/@shreyas/pre-mortems-how-a-stripe-product-manager-predicts-prevents-probl
- Advocate for changing reward systems
Clear Writing
- Answer the following questions
-
- What am I really trying to say?
- Why should people care?
- What is the most important point?
- What is the easiest way to understand the most important point?
- How do I want the reader to feel?
- What should the reader do next?
Skills for Success
- Talent stacking: collect more skills rather than always polishing one
- Much easier to learn skills and become top 25% performer than to master skill to become top 1% performer
- Combination of skills is rare and can give you ‘superpowers’
- High agency: finding a way to get what you want without waiting for perfect circumstances or complaining about bad circumstances
- Game changers are extraordinary and should be hired if possible
.png)
- Clear thinking
- Deep work:
- Transactional analysis
A B2B Product Story
- Story: new product idea that apparently solves user needs. Once built, adoption is anemic. Spent years of wasted efforts trying to improve and ultimately sunsetted
- Why did this happen:
- Product shouldn’t have been built in the first place
- Product was ill-conceived and original sin could not be removed afterwards
- For the first reason: this is purely because of focusing illusion
- If you force the customers to prioritize your product, you get whack results
- How to overcome?
- User interviews should be far more objective. This is not the time to confirm product ideas or exec mandate
- Stack rank problems to determine if this problem is even worth solving
Why B2B Is Tough
- Too many B2B products start with assumption that businesses badly need their product. PMs then think they need to prioritize requests, improve usability and build. Wrong
- Start from a null hypothesis that businesses don’t need your product and determine what needs to be true in order to reject the null hypothesis
- Questions to think about to avoid B2B failure:
- What acute customer problems does your product solve?
- Why would they pick your product over alternatives
- Why would they change ingrained habits to accomodate your product?
- Will these answers be true for enough customers?
- The alternative for your product is not another product; it is inaction or a spreadsheet
Tactics to Improve Products
- Talk to customers
- Use the product
- Understand the competition
- Browse support tickets
- Shadow a sales call
- Specify adoption metrics
- Write a user story
- List top user annoyances
- Read the website like a novice
- Go through the NUX (new user experience)
Growing as a product person
- Tips:
- Create a habit of deep work
- Build more user empathy
- Become a domain expert
- Understand good design
- Spec out your skill stack
- Get more even keeled
- Learn negotiation
- Know the basics of statistics
- Enhance listening
- Improve writing
- You shouldn’t spend 100% of your career time working on projects. Dedicate a significant portion (20%) on skill improvement so that the remaining part for project work becomes significantly more effective
Metrics primer
- Product metric categories:
- Health metrics: is the product available at performing at a level that users would expect?
- Eg: latency, load time, uptime, request errors
- Usage metrics: how are users using the product?
- Eg: time-of-day/week trends, top N actions, funnel metrics, help doc usage, retention, password reset rate
- Adoption metrics: is the product and key features as much as we hoped and in the ways that we like?
- Eg: DAU, MAU, DAU:MAU, N of M day usage, feature adoption trends, paid conversion
- Satisfaction metrics: what is the overall sentiment of users towards product?
- Eg: overall CSAT, new feature CSAT, support CSAT
- Ecosystem metrics: what is the macro state of your product in the domain?
- Eg: share of wallet, 3rd party integrations, industry rank, marketshare for target segments, % of TAM
- Outcome metrics: what overall results are we seeing from this product?
- Eg: revenue, margin, revenue/customer, active users, marketshare, transactions
- Health metrics: is the product available at performing at a level that users would expect?
- Be intentional of which categories you care about
- A metric can be in multiple categories for your product
- You want to keep track of multiple metrics (esp. usage metrics), but prioritize 3-5 for key metrics that serve as indicators if your product is meeting the proposed strategy & goals
- Rule of thumb: one metric for acquisition, retention, engagement and monetization
- Might not be able to move all metrics forward at once, so prioritize what is most important
- Criteria:
- Responsive to product changes
- Aggregate measure of product’s value to users
- Can be readily tied to business value
- Expected to be long-lasting
- Typically, you create your annual goals around your key metrics
- Sometimes your key metrics are lagging indicators of success. You want to also keep 3-5 metrics as leading metrics
- Might change far more frequently than key metrics
- Treat your dashboard as a product and keep track of its usage. Frequently check and can even set up email reports
- Remember to be data informed over data driven. Don’t let metrics decide everything for you
Product biases
- Learning and studying biases is important because they make or break decisions
- You do not rise to the level of your plan; you fall to the level of your decision-making
- You do not rise to the level of your OKRs; you fall to the level of your execution
- You do not rise to the level of your annual targets; you fall to the level of your strategy
- You do not rise to the level of your parallel processing; you fall to the level of your prioritization
- The best team is almost always the one that can make the most effective decisions
- To make good decisions, be clear on what success looks like, understand the inputs, evaluate the options and make a choice while also avoiding bad choices
- Biases to know about:
- Focusing illusion: when you focus on something, you elevate it’s importance
- This happens too many times during product building as you create a focusing illusion for your customers and they don’t convey that the problem isn’t important to them
- Then, we get surprised when customers don’t buy the product, because we overestimated the severity of the problem
- IKEA effect: we value the product too much due to past execution and sunk costs
- Bias-for-building fallacy: we don’t take the time to understand the problem, domain, competitors and other factors because we bias for action. We tell ourselves to iterate and build now
- Execution orientation fallacy: we create suboptimal decisions because we bias for easy execution, even though other choices might have huge positive impact despite challenges
- Maslow’s Hammer: use some process/metric/proxy over and over again even if the utility is limited in a particular situation
- Russian roulette for products: don’t properly consider scenarios that could lead to catastrophic product failures
- Use pre-mortems to prevent this
- Authority approval fallacy: we create strategies based on what would give us easier approval from higher-ups and confirm their understanding of the space (even if its flawed)
- Focusing illusion: when you focus on something, you elevate it’s importance
- How to prevent falling to these biases:
- Develop greater self-awareness
- Add these into your team’s shared vocabulary so they are aware of it at all times
- Remember, band-aids don’t fix bullet holes. The best fix is culture shifts, but that takes time. You should create operating principles & core values to counteract biases
- Deep customer empathy combats the focusing illusion
- Understand customer’s biggest problems and work towards solving them
- Velocity > speed combats bias for building
- Sheer speed doesn’t really help if it’s not in the right direction
- Cultivate high ambition and agency to avoid execution orientation fallacy
- Seek impact over convenience and don’t wait for things to fall in place
- Context combats Maslow’s Hammer
- The same tool can help or harm, depending on the context
- Preventing catastrophe is better than heroics; this principle avoid Russian Roulette
- To counterract authority approval fallacy, create culture of constructive dissonance
- Go after the right answer, not to prove yourself right
- Figure out where your team is going wrong and apply these principles and change according to your context
Product principles
- Before you get all excited about low-hanging fruit, make sure you’re standing underneath the right tree
- The “product” isn’t just the pixels and buttons on the screen. Treat everything that touches the user as a product and make sure there is cohesion
- Moving fast is important, but also move in the right direction. Avoid backtracking
- If you want to be opinionated, be opinionated on the target customer segment. It’s better to create something that is highly resonant for a few people than something for everyone but resonates with no-one
- The chief purpose of user research should be to uncover user motivations
- When evaluating UI/user-facing artifact, remove all context and approach as a beginner
- When a product problem is high-stakes, creative execution is really important
- Don’t just accept the first solution, which is often conventional and safe. Break down to the very essence and try to find more creative ways
- Don’t underestimate the value of delightful surprises
- The 3 most important product questions to always ask yourself:
- Is it serving an implicit/explicit user very well?
- Is it differentiated enough?
- Is the market large enough (or will it) to meet business goals?
- Strategy requires creativity as much as analytical chops. Do it with ⇐ 3 people (marketing person, creative product person, eng person)
- Don’t do strategy-by-committee
- Strategy isn’t super complicated. Read Porter’s 5 Forces, Porter’s 3 Generic Strategies and Helmer’s 7 Forces
- Everything else can be built on top of this
- Your product’s marketing must answer the following questions:
- What does it do?
- How good is it?
- Is it for me?
- Wherever your customer first interacts with your product, make sure it answers these questions
- Make sure to always have a floor budget for infra and tech debt
- Product work is both science and art. Use context to guide you
- Product work is all about creating a worthy vision, a shrewd strategy, wisely execute and meet user demands and business goals
Product prioritization
- Most prioritization problems are strategy problems:
- Acceptance problem: strategy is not important to teams
- Creation problem: strategy is important but don’t have one
- Substance problem: strategy is there but it’s flawed
- Communication problem: strategy is not well communicated
- If you think you’re working on something which makes no sense, go back to strategy and see if you have any of those problems
- If you solved these problems, use systematic planning:
- First clarify key themes across company and determine allocation of effort and time
- Or you can allocate time and effort for different aspects of one product (eg. customer specials, embarrasments, tech debt, ..)
- Requires intuition and user knowledge to know what should be prioritized for effort
- Questions to ask yourself:
- What do we need to do in the next N months to achieve our strategy?
- What key risks or liabilities do we need to eliminate?
- Do we need to play offense or defense in the next N months?
- Do we need immediate growth, future growth or guarding growth?
- Are we exploring or exploiting mode?
- What team processes can help us achieve our goals
- What key initiatives have the greatest expected value?
- What is in my control?
- Get feedback from stakeholders, iterate and present allocation of effort to team
- If ideally a bottoms-up team, team can propose features on what would lead to best impact
- As things come up, evaluate against allocation and can use ad-hoc prioritization techniques (like RICE)
On Listening
- Why is listening hard:
- Inability to be present
- Fear of being wrong
- A desire for validation
- A feeling of superiority
- A lack of curiosity
- Urge to impress
- To speak is craft; to listen is art
- When others are talking, we are constantly interrupting them with our thoughts
- To be a better listener, practice being present and establish a listening pattern
- To be present, train yourself to observe and meditate
- Listening pattern: mention you are open-minded, focus on the gaps between words (apparently very effective) and don’t intrepret beyond what is said, break for a few seconds to reflect and then summarize & respond