
Lessons from Nickey Skarstad
Product leader Nickey Skarstad built consumer experiences at Duolingo, Airbnb, The Wing, and Etsy. She writes the newsletter Dear Builders and teaches product sense as a deliberate, learnable skill. This profile gathers her frameworks for consumer tech, decision-making, and the day-to-day work of product management.
Part 1: Developing Product Sense
- On defining product sense: "Product sense is often treated as a mysterious innate talent, but it is actually a learnable skill built through deliberate repetition." — Source: [Dear Builders]
- On immersive consumption: "The simplest task to level up your product sense is to consume products actively, noticing exactly what friction you experience and what brings you joy." — Source: [Maven]
- On studying teardowns: "Do not merely use apps; tear them down. Screenshot the onboarding flows, map the empty states, and ask yourself why the designers made those specific choices." — Source: [Dear Builders]
- On building intuition: "Intuition in product is crystallized experience. You have to put in the reps of seeing things fail and succeed before you can trust your gut." — Source: [Lenny's Podcast]
- On identifying edge cases: "Strong product sense means seeing the edge cases before they happen, because you understand how users behave when they are confused." — Source: [Dear Builders]
- On user empathy: "Empathy is a buzzword until you are actually sitting with a frustrated user. Product sense requires bridging the gap between how you think the product works and how it is actually used." — Source: [Maven]
- On market awareness: "You cannot build in a vacuum. Knowing what else your user is interacting with on their phone sets the baseline for the quality they expect from you." — Source: [Lenny's Podcast]
- On opinionated design: "The best products have a distinct point of view. If you try to accommodate every potential user request, you dilute the core value proposition." — Source: [Dear Builders]
- On rapid synthesis: "A key component of product sense is the ability to take three conflicting pieces of user feedback and synthesize them into one cohesive feature update." — Source: [Lenny's Podcast]
- On continuous learning: "Your product sense degrades if you stop paying attention to new paradigms. Stay curious about how new platforms are solving old interaction problems." — Source: [Dear Builders]
Part 2: Operationalizing Product Quality
- On defining quality: "Quality is a measurable set of standards that your team must agree upon before writing a single line of code." — Source: [Lenny's Podcast]
- On the cost of bugs: "Shipping a known bug to hit a deadline is a tax you force your users to pay. Eventually, they will stop paying it." — Source: [Dear Builders]
- On quality barometers: "Establish a quality barometer for your team. This means writing down the specific conditions under which a feature is considered too broken to ship." — Source: [Dear Builders]
- On design QA: "Engineering QA catches broken logic; design QA catches broken trust. Both are necessary to maintain a high-quality consumer experience." — Source: [Lenny's Podcast]
- On internal testing: "Dogfooding is only effective if your team is willing to log the minor annoyances, rather than only the critical crashes." — Source: [Dear Builders]
- On technical debt: "Technical debt is a reality of building software, but quality suffers when debt becomes the default state of your codebase rather than a conscious borrowing." — Source: [Lenny's Podcast]
- On post-launch monitoring: "Quality assurance does not end at launch. How quickly you detect and fix the first user-reported bug sets the tone for your product's reliability." — Source: [Dear Builders]
- On holding the line: "As a product leader, your job is often to be the person who says 'no' when the team wants to ship something that falls below the quality bar." — Source: [Lenny's Podcast]
- On copy and tone: "Typos and confusing error states degrade quality equally to slow loading times. Words are a core part of the interface." — Source: [Dear Builders]
- On performance: "Speed is a feature. A beautiful interface that takes three seconds to load will always feel lower quality than a simple interface that loads instantly." — Source: [Dear Builders]
Part 3: Translating Vision Into Goals
- On setting vision: "A product vision should be clear enough that any engineer on your team can explain what the company is trying to achieve without looking at a slide deck." — Source: [Lenny's Podcast]
- On actionable goals: "Vision is the destination, but goals are the milestones. If your goals do not dictate your daily priorities, they are decorations." — Source: [Dear Builders]
- On metric selection: "Choosing the right metric is hard because the easiest thing to measure is rarely the most important thing to move." — Source: [Lenny's Podcast]
- On avoiding vanity metrics: "Focus on metrics that reflect actual user value delivered, rather than the raw volume of user activity on your platform." — Source: [Dear Builders]
- On alignment: "Translating vision into goals requires forcing functions. You need mechanisms that force the team to check their work against the long-term objective." — Source: [Lenny's Podcast]
- On simplicity: "If a goal requires a complex dashboard to understand, it is too complicated for the team to rally around." — Source: [Dear Builders]
- On course correction: "Goals are hypotheses. If you learn new information that invalidates the goal, change the goal rather than blindly marching toward the wrong outcome." — Source: [Dear Builders]
- On communicating progress: "Celebrate the inputs and the learnings, rather than only the final output. This keeps the team motivated during long development cycles." — Source: [Lenny's Podcast]
- On balancing timelines: "You have to balance the long-term vision with short-term wins. If you only focus on the three-year plan, the team will lose momentum." — Source: [Dear Builders]
- On shared language: "Create a shared vocabulary for your goals. When everyone uses the same terms to describe success, you eliminate a massive source of friction." — Source: [Dear Builders]
Part 4: Second-Order Decision Making
- On unintended consequences: "First-order thinking solves the immediate problem. Second-order thinking asks what new problems that solution will create next month." — Source: [Lenny's Podcast]
- On system dynamics: "Consumer products are complex systems. Pushing a metric in one area almost always degrades a metric in another area. You must anticipate the trade-off." — Source: [Dear Builders]
- On scaling: "A feature that works perfectly for ten thousand users might completely break your community dynamics when ten million people use it." — Source: [Lenny's Podcast]
- On feature bloat: "The second-order effect of saying 'yes' to a small feature today is the maintenance burden your engineering team carries for the next three years." — Source: [Dear Builders]
- On incentive structures: "Whatever metric you incentivize, your users will optimize for it. Ensure you actually want the behavior that your incentives produce." — Source: [Lenny's Podcast]
- On reversibility: "Assess whether a decision is a one-way door or a two-way door. Spend your time deliberating the irreversible decisions and move quickly on the rest." — Source: [Dear Builders]
- On user habits: "Changing an interface breaks user habits. The second-order effect of a redesign is a temporary drop in engagement while users relearn your product." — Source: [Dear Builders]
- On documentation: "Write down the rationale for your decisions. Six months later, you will need to remember why you accepted a specific trade-off." — Source: [Dear Builders]
- On post-mortems: "Evaluate your decisions based on the information available at the time, rather than solely the outcome. Good decisions can still lead to bad outcomes." — Source: [Lenny's Podcast]
Part 5: Building Consumer Experiences
- On emotional resonance: "Consumer products win by making the user feel something. Functionality is baseline; emotional resonance drives retention." — Source: [Dear Builders]
- On onboarding: "The first five minutes of your product dictate the next five months of retention. Do not rush the onboarding design." — Source: [Dear Builders]
- On gamification: "Gamification works if the underlying action is inherently valuable to the user. You cannot add badges to a useless feature and expect engagement." — Source: [Lenny's Podcast]
- On user trust: "Trust is built in drops and lost in buckets. Every confusing error message or hidden setting slowly drains the user's trust." — Source: [Dear Builders]
- On empty states: "An empty state is an opportunity to educate the user. Never leave a screen blank; tell the user exactly what they need to do next." — Source: [Dear Builders]
- On consistency: "Consumer expectations are shaped by the apps they use most. Deviate from standard interaction patterns only when your new pattern is demonstrably better." — Source: [Lenny's Podcast]
- On delight: "Micro-interactions and small moments of delight are never frivolous. They signal to the user that the creators care about the details." — Source: [Dear Builders]
- On accessibility: "Building an accessible consumer product is a fundamental requirement of good design, never a checklist at the end of development." — Source: [Dear Builders]
- On personalization: "True personalization is showing the user what they need before they ask for it, without crossing the line into feeling invasive." — Source: [Lenny's Podcast]
Part 6: Leading Through Influence
- On informal authority: "As a product manager, you rarely have direct authority over the people building the product. Your primary tool is influence." — Source: [Dear Builders]
- On active listening: "Influence starts with understanding what the other person cares about. You cannot persuade an engineer with marketing metrics." — Source: [Lenny's Podcast]
- On storytelling: "Data rarely changes minds on its own. You have to wrap the data in a narrative that helps stakeholders understand the user's pain." — Source: [Dear Builders]
- On building capital: "You build political capital by helping other teams hit their goals. You spend that capital when you need them to prioritize your initiative." — Source: [Dear Builders]
- On transparent decision making: "People will accept a decision they disagree with if they believe the process was fair and their input was genuinely considered." — Source: [Lenny's Podcast]
- On vulnerability: "Admitting when you are wrong builds more credibility than stubbornly defending a failing strategy." — Source: [Dear Builders]
- On repetition: "You have to repeat the vision and the 'why' until you are sick of hearing yourself say it. That is usually when the team finally absorbs it." — Source: [Lenny's Podcast]
- On managing upwards: "Do not bring your manager a problem without at least two proposed solutions. It shifts the conversation from complaining to problem-solving." — Source: [Dear Builders]
- On protecting the team: "A strong product leader acts as a heat shield, absorbing executive pressure so the execution team can stay focused on the work." — Source: [Dear Builders]
Part 7: Cross-Functional Alignment
- On engineering partnerships: "The best product managers treat their engineering leads as co-founders of the feature, rather than a ticket-execution service." — Source: [Dear Builders]
- On design collaboration: "Bring designers into the problem space early. If you hand them a finalized wireframe and ask them to make it pretty, you are wasting their talent." — Source: [Lenny's Podcast]
- On asynchronous work: "Clear written communication scales better than meetings. Documenting decisions ensures that cross-functional partners stay aligned across time zones." — Source: [Dear Builders]
- On resolving conflict: "When cross-functional teams clash, it is usually because they have misaligned incentives. Fix the incentives to resolve the conflict." — Source: [Lenny's Podcast]
- On the role of data science: "Use data scientists to challenge your assumptions, rather than merely to validate the hypotheses you already believe are true." — Source: [Dear Builders]
- On marketing integration: "Product marketing should be involved during the discovery phase, rather than brought in two weeks before launch to write an email." — Source: [Dear Builders]
- On customer support: "Your support team knows exactly where your product is failing. Read their tickets weekly to ground your roadmap in reality." — Source: [Lenny's Podcast]
- On avoiding silos: "Create informal channels for cross-functional chatter. Silos form when teams only talk during formal status updates." — Source: [Dear Builders]
- On shared accountability: "When a launch fails, the entire cross-functional pod must own the failure. Blaming a specific discipline destroys future collaboration." — Source: [Dear Builders]
Part 8: The Craft of Product Management
- On managing time: "Your calendar reflects your true priorities. If you say user research is important but spend zero hours on it, you are lying to yourself." — Source: [Dear Builders]
- On saying no: "The hardest part of the job is saying 'no' to good ideas to leave room for the great ones." — Source: [Lenny's Podcast]
- On writing PRDs: "A Product Requirements Document is a living tool for alignment. Keep it concise and update it as you learn." — Source: [Dear Builders]
- On dealing with ambiguity: "Product managers must be comfortable operating in the gray. Your job is to create clarity where none exists." — Source: [Lenny's Podcast]
- On continuous discovery: "Do not treat research as a discrete phase that ends when development begins. Talk to users every single week." — Source: [Dear Builders]
- On imposter syndrome: "Imposter syndrome never fully goes away; you simply get better at recognizing it and acting despite it." — Source: [Dear Builders]
- On prioritization frameworks: "Frameworks like RICE are helpful starting points, but they should inform your judgment, never replace it." — Source: [Lenny's Podcast]
- On celebrating shipping: "Shipping is a feature. It is easy to get stuck in perfectionism, but you learn nothing until the product is in the hands of real users." — Source: [Dear Builders]
- On the PM mindset: "The core of the craft is remaining relentlessly optimistic about what can be built while being fiercely realistic about what it takes to build it." — Source: [Dear Builders]