Lessons from Tara Seshan

Lessons from Tara Seshan

Tara Seshan helped build embedded finance at Stripe as the product lead for Treasury and Billing, later heading product at Watershed before joining OpenAI. This collection breaks down her frameworks for going from zero to one, managing multi-product transitions, and explaining product tradeoffs to leadership.

Part 1: Scaling From Zero to One

1. On early product velocity: "Moving from concept to a launched product requires prioritizing speed and decisive execution over early perfection." — Source: [First Round Review]
2. On finding initial users: "The first users of a zero-to-one product are often internal teams or highly motivated early adopters who share your pain points." — Source: [First Round Review]
3. On problem validation: "Before writing code, teams must deeply validate whether the problem they are solving is an acute pain point for a specific subset of users." — Source: [Lenny's Podcast]
4. On scoping the MVP: "A successful minimum viable product is narrower in scope than most founders initially want, but much deeper in solving the core use case." — Source: [First Round Review]
5. On iterating past version one: "The launch is just the starting line; the real work of a zero-to-one product is iterating based on how early customers actually break the system." — Source: [Lenny's Podcast]
6. On building conviction: "You have to maintain strong conviction in the vision while remaining entirely flexible on the specific product mechanics to get there." — Source: [First Round Review]
7. On resource allocation: "Zero-to-one teams should be kept intentionally small to avoid coordination overhead and force ruthless prioritization." — Source: [Lenny's Podcast]
8. On avoiding early scale issues: "Do not optimize for scale when you are still trying to find product-market fit; do things that don't scale until they break." — Source: [First Round Review]
9. On defining success: "Early success isn't about revenue; it's about finding a small group of users who would be genuinely upset if your product disappeared." — Source: [First Round Review]

Part 2: Multi-Product Strategy

1. On the multi-product transition: "Transitioning from a single flagship product to a multi-product portfolio is one of the most perilous phases for a growing company." — Source: [First Round Review]
2. On avoiding distraction: "New products should not distract the core team from maintaining the momentum of the primary revenue-generating flagship." — Source: [Lenny's Podcast]
3. On autonomous teams: "Successful multi-product expansion requires treating the new product team like an internal startup with its own distinct culture and metrics." — Source: [First Round Review]
4. On cross-selling: "The easiest path to a successful second product is solving an adjacent problem for the exact same buyer who already trusts your first product." — Source: [Lenny's Podcast]
5. On resource cannibalization: "Leaders must be careful not to starve the core business of engineering resources to fund speculative new bets." — Source: [First Round Review]
6. On go-to-market friction: "Adding a second product often breaks the existing sales motion, requiring a complete redesign of how the sales team is incentivized." — Source: [First Round Review]
7. On shared infrastructure: "Whenever possible, new products should leverage the underlying infrastructure of the flagship to accelerate development without reinventing the wheel." — Source: [Lenny's Podcast]
8. On brand permission: "A company must earn the right to launch a second product by executing flawlessly on the first; brand trust is the bridge to multi-product success." — Source: [First Round Review]
9. On knowing when to expand: "The best time to start building a second product is right when the first product's growth engine is fully predictable and self-sustaining." — Source: [First Round Review]
10. On the fledgling phase: "You have to treat a new product like a fledgling bird; it needs protection from the rigid processes of the mature organization until it can fly." — Source: [First Round Review]

Part 3: Communicating Tradeoffs

1. On the pros and cons trap: "Presenting a simple list of pros and cons often backfires, as leaders will simply ask you to figure out a way to do both." — Source: [Lenny's Newsletter]
2. On articulating consequences: "Effective communication requires moving away from listing options and toward clearly articulating the tangible consequences of shifting priorities." — Source: [Lenny's Newsletter]
3. On protecting the team: "A product manager's primary job in stakeholder meetings is to protect the team from burnout caused by taking on un-resourced mandates." — Source: [Lenny's Newsletter]
4. On saying no: "The best way to say no to an executive is to say 'yes, but here is exactly what we will have to drop to make that happen'." — Source: [Lenny's Newsletter]
5. On the Operating System Review: "Use a living document, like an OSR, where every project is sequenced by priority so the tradeoffs of adding new work are instantly visible." — Source: [Lenny's Newsletter]
6. On repetition: "You cannot over-communicate your team's strategy; consistently reinforcing your priorities is necessary for leaders to truly internalize them." — Source: [Lenny's Newsletter]
7. On executive alignment: "Leaders don't want to break your roadmap, but they lack your ground-level context; it is your job to bridge that gap with clear tradeoff frameworks." — Source: [Lenny's Newsletter]
8. On capacity limits: "Treat engineering capacity as a strict physical limit rather than a flexible concept; if something goes in, something of equal size must come out." — Source: [Lenny's Newsletter]
9. On narrative control: "Control the narrative of your team's output by proactively defining what success looks like, rather than letting stakeholders define it for you." — Source: [Lenny's Newsletter]

Part 4: Managing Product Reviews

1. On rigorous frameworks: "Product reviews should not be status updates; they should be rigorous sessions dedicated to unblocking the team and pressure-testing core assumptions." — Source: [Hustle Badger]
2. On answering core questions: "Every product team should be able to answer a set of fundamental questions about the user, the problem, and the mechanics before writing any code." — Source: [Hustle Badger]
3. On evidence-based decisions: "Debates in product reviews should be settled by customer evidence and data, not by the loudest voice or the highest title in the room." — Source: [Lenny's Newsletter]
4. On defining the user: "The most common failure mode in product development is building for a vague, generalized user rather than a specific, well-understood persona." — Source: [Hustle Badger]
5. On the role of leadership in reviews: "Leaders should use product reviews to ask clarifying questions that the team might have missed, rather than dictating specific feature designs." — Source: [First Round Review]
6. On identifying risks: "A good product review actively surfaces the biggest risks to the project, whether they are technical, go-to-market, or related to user adoption." — Source: [Lenny's Newsletter]
7. On the pre-read document: "The effectiveness of a product review is directly proportional to the quality of the written pre-read document provided to stakeholders beforehand." — Source: [Hustle Badger]
8. On focusing on the problem: "Spend disproportionate time in product reviews ensuring everyone agrees on the exact problem being solved before debating the proposed solution." — Source: [Lenny's Newsletter]
9. On clear next steps: "No product review should end without explicitly documented next steps, clear owners, and a shared understanding of what needs to happen by the next check-in." — Source: [Hustle Badger]

Part 5: Hiring and Talent

1. On evaluating potential: "When hiring for early-stage teams, index heavily on raw intelligence and high potential rather than a long resume of specific past experiences." — Source: [Working Assumptions]
2. On the generalist advantage: "Generalists are incredibly valuable in the zero-to-one phase because they can comfortably navigate ambiguity and wear whatever hat is required." — Source: [Working Assumptions]
3. On interview signaling: "Look for candidates who demonstrate extreme curiosity and a track record of rapidly teaching themselves new, complex domains." — Source: [First Round Review]
4. On low experience hires: "Hiring 'low experience, high potential' talent often yields the most dedicated and adaptable team members who are eager to prove themselves." — Source: [Working Assumptions]
5. On assessing grit: "Building zero-to-one products is painful; you must interview for resilience and the ability to push through inevitable product failures." — Source: [First Round Review]
6. On the limits of specialists: "Over-indexing on deep specialists too early can create rigid silos in a team that needs fluid, fast-paced collaboration." — Source: [Working Assumptions]
7. On culture fit vs. culture add: "Don't hire people who just fit the existing culture; hire individuals who add a new dimension or perspective that the team currently lacks." — Source: [First Round Review]
8. On rapid onboarding: "High-potential hires don't need a month to onboard; give them real, low-risk problems to solve in their first week to accelerate their learning." — Source: [Working Assumptions]
9. On building trust: "The fastest way to build a high-functioning team is to hire smart people and immediately trust them with significant responsibility." — Source: [Lenny's Newsletter]

Part 6: Building Climate Software

1. On climate data complexity: "The core challenge of climate software is taking messy, fragmented business activity data and transforming it into rigorous, audit-ready emissions reporting." — Source: [Watershed Blog]
2. On the role of software in climate: "Software alone won't solve climate change, but it provides the essential infrastructure and visibility companies need to actually take targeted action." — Source: [Watershed Blog]
3. On Scope 3 emissions: "Measuring Scope 3 emissions is incredibly difficult because it requires looking deep into a company's upstream supply chain where data visibility is poor." — Source: [Watershed Blog]
4. On actionable insights: "Climate software must move beyond simply calculating a carbon footprint; it has to provide specific, actionable scenarios for how a business can decarbonize." — Source: [Watershed Blog]
5. On regulatory compliance: "As climate disclosures move from voluntary to mandatory, enterprise climate platforms must offer the same level of rigor as financial accounting software." — Source: [Watershed Blog]
6. On the climate economy: "Every major enterprise is eventually going to have to transition their operations to align with the realities of the new climate economy." — Source: [Watershed Blog]
7. On AI in sustainability: "AI agents have a massive role to play in climate tech, specifically in automating the tedious work of cleaning data and mapping emissions factors." — Source: [Watershed Blog]
8. On product-level footprints: "Understanding the carbon impact at the granular level of an individual product or material is critical for making sustainable supply chain decisions." — Source: [Watershed Blog]
9. On enterprise adoption: "To get enterprises to adopt climate software, the platform must integrate seamlessly into the financial and operational systems they already use." — Source: [Watershed Blog]

Part 7: Financial Infrastructure

1. On embedded finance: "Embedded finance allows platforms to turn their existing customer relationships into entirely new revenue streams by offering contextual financial services." — Source: [Stripe Blog]
2. On the complexity of banking APIs: "The value of a product like Treasury isn't just moving money; it's abstracting away the immense regulatory and compliance burden of banking infrastructure." — Source: [First Round Review]
3. On API design: "When building financial infrastructure, the APIs must be exceptionally clean and intuitive, because the underlying reality of the banking system is incredibly messy." — Source: [Stripe Blog]
4. On user trust in fintech: "When you are handling a user's money, there is absolutely zero margin for error; reliability and trust are the product." — Source: [First Round Review]
5. On B2B financial tools: "B2B financial software has historically been clunky and painful to use; there is a massive opportunity in bringing consumer-grade design to enterprise finance." — Source: [Stripe Blog]
6. On scaling billing systems: "A robust billing system has to elegantly handle a million edge cases, from prorations to failed payments, without breaking the user experience." — Source: [First Round Review]
7. On platform empowerment: "By providing card issuing and accounts through APIs, we empower platforms to build customized financial experiences that were previously impossible for non-banks." — Source: [Stripe Blog]
8. On managing risk: "In any financial product, building the features that move money is only half the battle; the other half is building the systems that prevent fraud and manage risk." — Source: [First Round Review]
9. On the future of payments: "The future of payments is invisible; financial transactions will increasingly happen seamlessly in the background of the software tools businesses already use." — Source: [Stripe Blog]
10. On iterative finance: "You cannot 'move fast and break things' with financial infrastructure; iteration must happen safely within strict compliance boundaries." — Source: [First Round Review]

Part 8: The Friction of Work and Self

1. On the identity of work: "We often blend our professional output with our personal identity, making the inevitable frictions of the workplace feel like personal failings." — Source: [Working Assumptions]
2. On writing to clarify thought: "Publishing writing is a forcing function to clarify your own scattered thoughts and systematically document your professional evolution." — Source: [Working Assumptions]
3. On career non-linearities: "A fulfilling career rarely looks like a straight ladder; it looks like a series of unexpected lateral moves and deep dives into new domains." — Source: [Working Assumptions]
4. On managing burnout: "Burnout doesn't always come from working too many hours; it frequently comes from a prolonged misalignment between your values and your daily tasks." — Source: [Working Assumptions]
5. On the value of reflection: "Taking the time to write about work provides a necessary distance, turning stressful operational challenges into valuable, generalized lessons." — Source: [Working Assumptions]
6. On imposter syndrome: "Even highly successful product leaders grapple with the friction of feeling unqualified; the key is acting decisively despite the internal doubt." — Source: [Working Assumptions]
7. On organizational empathy: "Understanding the human friction within a team—why people are resistant to change—is just as critical as understanding the technical architecture." — Source: [Working Assumptions]
8. On embracing ambiguity: "The most interesting professional growth happens in the spaces of highest ambiguity, where there is no existing playbook to follow." — Source: [Working Assumptions]
9. On the reality of leadership: "Leadership is rarely about making glamorous strategic choices; it is mostly about continually managing the interpersonal frictions that slow down execution." — Source: [Working Assumptions]
10. On defining your own success: "Ultimately, you have to write your own definition of professional success, rather than passively accepting the default metrics offered by your industry." — Source: [Working Assumptions]