🧠 Community Wisdom: Recommendations for feel-good content, measuring success of a PM, how to start your entrepren…
- Lenny's Newsletter <lenny+community-wisdom@substack.com>
- Hidden Recipient <hidden@emailshot.io>
👋 Hello and welcome to this week’s edition of ✨ Community Wisdom ✨ a subscriber-only email, delivered every Saturday, highlighting the most helpful conversations in our members-only Slack community.
A big thank-you to this month’s community sponsor, Merge! Merge makes integrating with your customers’ software vendors easy. Add hundreds of integrations to your B2B SaaS products, with unified APIs for file storage, ticketing, CRM, ATS, HRIS, and accounting. AI companies love Merge because it delivers instant, secure access to clean customer data that powers their solutions. Stop wasting countless engineering hours staying ahead of breaking API changes and digging through a backlog of integration support tickets. Merge handles the full integration lifecycle so you can focus on what matters most: building your core product! ✨ Upcoming community meetups ✨Upcoming community-organized meetups—click the city name to RSVP:
Can’t find your city and want to host one? Just DM @Riya in our Slack. It takes 10 minutes (i.e. pick a date and location), and you get to meet awesome people from our community. Learn more here. 🎙️ New podcast episodes this weekThe rise of Cursor: The $300M ARR AI tool that engineers can’t stop using | Michael Truell (co-founder and CEO): YouTube // Apple // Spotify  How this former NYT columnist uses ChatGPT to brainstorm ideas, do research, and find the perfect metaphor | Farhad Manjoo: YouTube // Spotify // Apple  Inside monday.com’s transformation: radical transparency, impact over output, and their path to $1B ARR | Daniel Lereya (Chief Product and Technology Officer): YouTube // Apple // Spotify  💥 Top threads this week1. Measuring success for a product manager
Balaji: Mostly B2B-focused ... think big ideas, backlog curation/prioritization, product/feature adoption, early customer references. Justin Goff: I have strong and often impractical opinions about this. I think product managers should ideally be judged (1) on business outcomes (sometimes in the form of KPIs that contribute to business outcomes) and (2) using timelines and expectations that line up with the product’s business cycle. For (1), of course, there needs to be some kind of product strategy, plus some measurable outcome the product manager and their team are trying to achieve. At many companies, this isn’t the case. For (2) ... well, I’ve been in a situation where we had (1) but not (2) and it sucked lol. All the other products at the company measured their business cycle in days; my product’s business cycle was a full year. When consistent improvement in KPIs for several quarters in a row is a prerequisite for promotion but your product grows in step functions every Q2 ... oof. Also, to address your question more directly—in theory, a product manager should be working to increase revenue. But in practice, a product manager is more likely to be responsible for leading indicators of revenue, like activation, engagement, retention, etc. Ritesh: Thank you, @Balaji and @Justin Goff. I have been thinking of a value + velocity score (VVS). Now, how to build this practically—this is where I struggle. Eric Metelka: There are input metrics and output metrics. For inputs, it should be about learning and opportunities identified—things like number of customers talked to per month that lead to good hygiene in the product org. Outputs are impact, which differs by B2B and B2C. In B2C, a team usually “owns” a number, such as conversion to purchase. In B2B, it’s more around adoption but can also be win rate versus competitors. As you get more customer-facing in that metric, yes, it is conflated with things like sales execution, but that doesn’t mean it’s not worthwhile. Joshua Herzig-Marx: This is such an interesting question to me, and I think @Eric Metelka nailed it. In a healthy organization, the product team should be responsible for outcome metrics. But “healthy” implies that there’s a robust strategy, that we can tie the group goals to that strategy, and that the group has the resources to succeed. That last one is especially tricky—what does it mean to be able to succeed? Think of a team that works for Quibi, the ill-fated short form video app. There was a team in charge of handling subscriptions. They had all sorts of requirements from across the org (compliance, privacy, security, performance), they tested flows and prototypes to ensure they worked, didn’t error out, and converted well. But they hit exactly zero of their numbers, because the company went out of business. Were they high-performing or not? As an aside, I have a strong hypothesis weakly held that the ceiling of a company’s success is almost always set at the first successful investor pitch meeting. It’s the rare company that exceeds its initial strategy. Great company outcomes are almost certainly driven by great PMF. We’ve all had the experience of using a product from a wildly successful company and realizing it kinda sucks. Contrast that with products from tier 2 companies—they’re often amazing! Amplitude and Posthog are awesome, but many aspects of what they’re giving you are clearly half-baked and hard to use. Contrast that with LogRocket—definitely in 3rd or 4th place, but they have everything dialed in. Why? Because when you don’t have extreme PMF, you can’t afford to be less than stellar. Which company has the best PMs? Finally, the nice thing about managing people on inputs is that you can coach on them. You can help someone have more customer conversations, you can improve the quality of their PRDs, and you help them run better meetings with stakeholders. But if the goal is a better conversion rate, how do you coach for that? “Maybe next time try to be luckier at picking what solutions to test”? 2. How to start your entrepreneurial journey
Mayank: These notions are fine, but they will be needed at different stages of your journey. As you said, you want to “validate” your ideas: focus on your first point and nothing else: 1. Write down who else has/could have this problem (apart from you), a rough draft of potential ICP. 2. Now make a list of 10 companies or folks in your network who fit that profile. 3. Reach out to them and ask how they are solving this problem. How critical is it for them? Are they already paying for such a tool? If they are not using any tool, why are they not using such a tool? Do not talk about your solution or idea at this point. Document words they use to describe their problem. 4. Go back and refine your idea based on your understanding of the problem. 5. Prepare a prototype (no code) and reach out again and take feedback on your idea/solution. Identify 1-2 key features which are compelling enough for them to try it out at their org. 6. Find at least 5 such orgs. 7. Then begin the code. Feel free to DM if you need to discuss more. Peter Berg: I think the problem with generic advice/guidance is that advice independent of context is not super-valuable, e.g. what makes sense in terms of a starting point for a solo founder attempting to bootstrap a SaaS product might not be the same as what makes sense for a pair of co-founders working together in an incubator to start a DTC e-commerce company. I think because of this, it’s important to attempt to assess whether individual pieces of guidance/“wisdom” apply to you/your particular situation/where you’re at in your process currently. Seeking out a trusted advisor/mentor-type folks to bounce ideas off of could be helpful, and there’ll for sure be other people out there who have more experience than you. But there’s not gonna be anyone who has more context than you on your particular situation, and ultimately as a solo founder, everything comes down to you and is up to you, and it’s hard but it’s also a great way to learn. There are always multiple, valid paths forward. Lots of ways to skin the cat with this stuff, lots of ways to start. I’m always skeptical when I talk to folks and they tell me there’s only one path forward and nothing else will work. More than anything, I think the most important thing is a bias for action. If you feel like something makes sense, trust yourself and do that thing. Keep doing that and keep moving forward. You’ll make mistakes, but you’ll learn. There’s no better way to kill something than endless deliberating. David Jorjani: Welcome to entrepreneurship! At times it is slow, stressful, anxiety-inducing, and leading to self-doubt, but I think overall it’s worth it. Others said this. How does one give the right advice starting fresh? I don’t think it’s possible, or at least I can’t. What I’ve learned over a decade of mentoring and years of coaching is to know the person, know the goal, and help them address the biggest risk or obstacle to their goal one at a time. Based on what you said, you are new, don’t have your support community or leaders to follow and learn from. I could give you a hundred names and resources, but seems like you don’t know what you don’t know. You are starting from what you know. So the question is, how do you define success for yourself and this venture? Why are you doing this? Feel free to DM more context, and I’m happy to share specifics. Short answer to your question is that you are more likely to fail because you can’t sell, or get tired, burnt-out, or run out of money than pretty much any other reason you know. So optimize for those and not building the best product. If you want to do B2B, look up Rob Snyder or Sahil Lavingia, but most importantly, find your community. Zain: +1 If you’re looking to build B2B, look at the deck prepared by Rob Snyder. While everyone talks about validating before build (and I agree with that), I will also say, sometimes it takes time to find the right idea and also your own interests. In those cases it’s ok to experiment and build some things and give your permission to fail on a few things before landing on the right idea. As you build, you can also pay attention to what was hard and get firsthand insights on what worked and didn’t work. Very much also depends on your personal runway and how much time you have to start bringing in cash flow. There’s no one right path, but the general themes are around selling before building, learning by doing, and talking to people regularly. Wilson: Thank you all for your input. It’s very helpful to read through all of it and I believe the common thread is the importance of starting, whether it is by building or by preparing myself to be a better seller/networker/builder. I’ll read through your comments often while I soul-search and define what success would be like for me. Thank you for taking some of your time to help me with your insights, I couldn’t have asked for anything better! Side note: About 20 minutes after I posted this and said this week was the one I’d start doing this, my country suffered a 10-hour-long nationwide power outage and everyone was offline. I’ll interpret it as a sign that I just needed a day’s-long detox from the internet to start with a clearer mind. Marc Dupuis: All great points above that I agree with. In case a bit of extra is helpful: “Solve a real problem, ideally one that I have myself, so that I keep motivation and understanding at the top of my prios” -> My hot take is that I think this is overused. This is the reason every novice founder builds a to-do app, an email client etc. Not saying it’s categorically bad advice, but it doesn’t mean that all pains you feel have a market. I also strongly believe that distribution and marketing is actually 80% of the challenge nowadays. I think that for every app and platform I see out there that are attacking a real problem, there are 20 competitors, and what makes or breaks them is marketing. Understanding how you’re going to approach this is just as critical as the problem itself. As for mentor network and early feedback, if this is B2B, I can do a quick recording of my LinkedIn outreach setup which can probably get you your first 50 conversations. Christina Pawlikowski: Lots of good advice here! I’m an early-stage founder now, and here are a few thoughts from my experience:
I would definitely echo the advice above to just start. Pick something to do and get going. You’ll learn quickly whether that something is yielding fruit. If not, pick something else. A lot of what my co-founders and I did during our very earliest days was just heading down a path and then reporting back something like “I thought there might be something in this idea, but then I chatted with folks at X, Y, and Z, or I tried prototyping this feature and learned these new things. Based on that, I’m going to explore this other idea.” It’s fine! It’s great! I loved those very early days. Wilson: This is fantastic, thank you for giving such a deep dive into your experiences! I’ll try to keep your DMs free and post any particular questions I may have here, as your insights might be helpful to anyone else reading. Thank you all! Ian Brand: Just start! Build, and talk to users, is the most important thing in the beginning. 3. Cultivating solution-oriented engineers
Eric Metelka: Was the lead engineer receptive to the idea? Do they have a manager and are they receptive to it? Sachin: In my experience, three things worked very well for my team:
Scott Breudecheck: My recent experience has been on a devX tool. So when the devs have asked for more details, I usually turn it around on them: “You’re a developer who cares about [this abstracted problem], what sort of tools and techniques do you find helps in this situation?” And then I just screenshare + write it up live. If it sounds off-track, I’ll nudge with questions or point out use cases. After doing this reliably, I found most devs started to write up their own first drafts. Ymmv if you’re building B2B for non-dev users. David Jorjani: Seems tricky. I’d involve the lead to get their input. Sometimes it’s a much harder battle to get engineers to care about something and leads to them doing meh work and also holding them from doing things they are great at and interested in. I’ve always made sure I had a balance so didn’t need all engineers to chip in in these areas. Miroslav Pavelek: You’ll definitely need support from the lead engineer—or their supervisor—for this. That said, it’s understandable that the team expects user stories to be already defined, especially if that’s been the norm. One possible solution is to run separate sessions specifically for brainstorming and shaping the solution. Călin: Sounds like a mindset issue. You can’t blame devs to care most about coding. They might also be reluctant because it sounds like more work for them—do all the coding + some PM-ish work. Few care about the overall product experience and finding ways to improve the UX. Try to stimulate them by sharing bits of recordings showing users struggling with a feature or flow. Invite them to shadow customer interviews. Help them see the effects of their work and where it falls short. However, have reasonable expectations. Dustin Coates: What’s the problem you’re encountering? Engineers not wanting to be more in the product discovery isn’t, itself, a problem. It’s best to start with understanding why (or even if) this is really an issue. Not only because it can help you understand if it’s worth pursuing, but if you do, it will help you help them come to your side. Otherwise it might sound like “I want you to be more involved.” “Why?” “Because.” John Conneely: Love this question! And I have a good solution for you—I call them epic champions. All the engineers, QA and analysts on my team have different epics that they will champion (and be the assignee). Other engineers might share some of the work in the epic, but they are the ones making sure their epics are progressing well, and anything that is required of me or needed in general is raised promptly in order to avoid their epics from being blocked. Makes it really valuable for them from a career progression POV as well, as they can point to complete epics when dictating their impact in reviews and they get practise on presenting the completed work via the epic demos (champions will demo with support once an epic is complete). It’s a win-win for everyone on the team. There is more shared ownership, delegation of work becomes a lot easier for the lead, and the rest of the team get involved in the reporting structure with more responsibilities or exposure than they usually would have. Scott Breudecheck: @John Conneely: just a note that I read that when it first came out, brought it to our head of eng. We’ve since implemented it, and it’s been a huge unlock (not without growing pains). While PMs are kicking off the framing, the tech leads quickly ramp up to make the 1,000 microdecisions and ship a rewarding experience. Big force multiplier as a PM. 4. Taking a day off to upskill
Adam Green: I haven’t regretted skipping the Lovable/Bolt/v0 solutions and going straight to a Cursor tutorial. Joni Hoadley: What a great question! Without knowing more about your background and current focus, it’s hard to give targeted advice—but anything you can do to deepen your T-shaped skill set as a product manager is a smart investment. I just dropped a blog post on this very topic: Hybrid Product Managers 2025. One practical starting point: do a personal SWOT analysis. It’s something I often do with my clients to help identify growth areas. From there, you can choose hands-on activities that directly address those gaps. Also, check out courses on Maven—there are great ones that can give your upskilling day some structure. Enjoy your “day off” to level up—sounds like it’s going to be a valuable one! Miroslav Pavelek: I’d skip Lovable, Bolt, and v0 solutions, as well as the Cursor tutorial. Instead, jump straight into building something in Cursor—set a clear goal, like a PoC for a game, your product, or an isolated feature. Open Cursor and learn as you go. Avoid all tutorials—just start building. Kevin Holland: Cursor tutorial + n8n tutorial coding + automation = building powerful products and getting hands-on with what agents are becoming. Build something that helps you out personally—super-fun! Adam Green: Partial disagree, @Miroslav Pavelek—for a non-technical, a brief tutorial saved tons of time and tokens. Not saying you need to go nuts, but get the basics. Do agree—actually build something! Joni Hoadley: I’m assuming you are thinking about Figma for prototyping. If so, it seems like Proto.io and Bubble are gaining in popularity. One other thing to consider is, rather than specific tools, think about your workflows and perhaps spend time experimenting and developing automations and agents that can help streamline, optimize, and ultimately improve how you work as a PM. Faye Zheng: Re: Figma—this is primarily because our existing design teams (and other PMs) use Figma and I need to be able to work my way around it in a minimal way. I actually don’t intend to use it myself necessarily. Scott Breudecheck: What a great idea! I think @Joni Hoadley nails it: it depends where you need to level up. Go technical with Python + SQL (+Windsurf) and build a simple API. Go UX-heavy and use Bolt + Figma to get a clickable prototype live. Go marketing-heavy and stand up a landing page (Carrd) and run some ads (I found it fun using ChatGPT to help me do LinkedIn campaigns). Go research-heavy and do prep work to set up dream interviews with leaders in your subject area. Go process-heavy and play with Asana’s MCP to automate creating/status updates of projects. David Jorjani: Ask yourself: what could I have that’ll add more free time during the day? What job do I not want to do that I could have someone else do? Then go to Gemini to work it out, how you’d build it with Cursor/Windsurf + n8n or similar alternatives. Then use the free time gained to build more free time. Then only spend time doing what you want (only partly joking). Miroslav Pavelek: @Adam Green, I agree that some intro is nice (or even a prompting guide, like make it prepare architecture + PRD and save it as separate files), just it is easy to get into “tutorial hell” and not actually build anything, so the correct approach is actually something in the middle, I guess. Adam Green: Totally + so many of those tutorials get outdated pretty quickly with the rate of product improvements. Faye Zheng: @Miroslav Pavelek, “tutorial hell” is such a spot-on phrasing. Rachel Hechter: What about running through the exercises in Lenny’s Make product management fun again newsletter from yesterday? Abhishek Katiyar: Something I did a few weeks ago and found very valuable. I have a complex AI agent project in the works. I took a full day to evaluate/score the outputs across different models and different eval metrics and prompts. Really valuable exercise to understand all the blind spots in AI products. Myles Sutholt: What I usually do is look at my biggest challenge that I am facing in my job right now. And then I prepare upskilling tailored to that problem. So I would ask myself: “What am I struggling with the most?” and then ask people for advice how to upskill against that. Alex Tran: I’m starting to learn Subframe --> Cursor. I’m a designer, maybe I can report my findings back. 5. Managing unlimited PTO
Dustin Coates: If deadlines are being broken, that’s the problem, not the PTO. So if you communicate with this person that it’s a problem, stick to the downstream effects. Whitney Gibbs: Follow-up questions:
Matt Gonzales: “We’ve worked together for 3 years and they’ve never been great about deadlines.” This, to me, is the bigger problem. I’m a huge proponent of “measure results, not hours worked,” which I think this PTO/notice topic falls under. If they’re (consistently) not delivering the expected results, that’s probably the conversation I’d have. Last-minute/uncommunicated PTO seems like maybe a contributing factor to the missed deadlines but may also be a more systemic issue around communication, discipline, efficacy, etc. Joshua Herzig-Marx: Similar to everyone else, my big question is “Why is this a problem?” I’m not saying it isn’t, I’m just encouraging you to clearly articulate what’s going wrong.
If there is a clear problem, then you have a performance issue. You can decide how important it is, but you should treat it like any other underperformance problem. Ilya Subkhankulov: My guess is that this person may be actively interviewing, which could mean they’ve already made the decision to leave. Anji (Pranjali D): I would be careful about assuming they are interviewing. Interviews do not get scheduled last-minute (i.e. day-of) but can get scheduled with a 24- or 48-hour notice. I wouldn’t speculate that they are interviewing and, like others have said, determine if the issue is a performance issue or a non-compliance to your rules. Even if they are interviewing, the right thing to do is not to fish for that information but see what can make a good employee stay. Rachel Hechter: This is a performance issue, and they need to go on a PIP. Lenny’s conversation with Alisa Cohn is an excellent resource for scripts on the best way to frame this type of discussion. I know it’s hard, but if this person is not performing, it’s worth the pain of parting ways and hiring someone else. There’s a lot of talented people looking for work right now who would jump at the chance to hit your deadlines. Joshua Herzig-Marx: (Or alternatively, you decide that this behavior isn’t considered underperformance and you realize you need to redo your policies.) Anji (Pranjali D): Agree with @Joshua Herzig-Marx that there’s an alternative path forward here. 6. Recommendations for feel-good content
Annie Warner (Community Lead): Heavyweight is my favorite podcast. Alex Carrasco: I would recommend reading biographies. A good biography always gets under my skin in very powerful ways. One of my favourites (and one with a lot of powerful feelings) is “Educated” by Tara Westover. Zack: Thank you. Ooh, and it’s available in the Libby app. I’ll be starting this one tonight! Markham Nolan: Tomorrow, and Tomorrow, and Tomorrow is the last novel that really sucked me in emotionally—bonus points for being set in the world of games development. Greg Docter: These won’t scream “feelings,” but these Chernow biographies hit surprisingly hard for me:
As for non-biographies, picking different genres intentionally:
Joshua Herzig-Marx: Some of my top books of the past few years in helping me look at the world in a different way:
Z: I just finished The Ministry for the Future by Kim Stanley Robinson. Hard science fiction focused on the climate crisis. It was an amazing roller coaster of emotions that left me feeling hopeful and empowered. MarcM: Recently realized I was a sucker for history podcasts:
It’s a great escape, and it lets me learn about some fascinating events which my history classes never covered. Justin Goff: Great stuff in here. @Joshua Herzig-Marx, loved the Overstory. Bewilderment by Richard Powers is also very good. I’ll add Ted Chiang, Exhalation, and Station Eleven by Emily St. John Mandel. MarcM: Too many recommendations! Thankful for Raycast to let me quickly explore these! Whitney Gibbs:
Justin Goff: Oh man, The Book Thief will make you weep. I used to teach it in my classroom days, and I cried every time. Whitney Gibbs: Also! Shout-out to the great app StoryGraph. Really great interface, better community than Goodreads, and also the personalized recommendations using AI are fantastic. Joanita D: Strangers on a Bench is similar to Heavyweight in some ways. This graph is a cool resource too to find similar podcasts. Moth podcast is also great depending on the theme of the stories! Alex Carrasco: @Zack, Glad to help, let me know if you enjoy it. On my side, I have started listening to Heavyweight—I’m 4 episodes in and really loving the podcast!! I have also downloaded Tiny Beautiful Things—I’ll let you know when I get to it. Zack: @Joanita D, this is such a cool tool!! Thanks—I’ve never heard of StoryGraph! I’m setting it up now. Everyone else, holy shit! Some really great stuff here. Thank you!!!! Leticia Muñoz: +1 for “A Little Life” book. 🤓 Top finds
😂 Meme of the week
Have a fulfilling and productive week 🙏 If anyone in your life would benefit from this newsletter or community, consider giving them a gift subscription 💞 There are group discounts, gift options, and referral bonuses available. Sincerely, Kiyani 👋 Invite your friends and earn rewardsIf you enjoy Lenny's Newsletter, share it with your friends and earn rewards when they subscribe.
|
Similar newsletters
There are other similar shared emails that you might be interested in:
- 🧠 Community Wisdom: Essential reading for early-stage founders, balancing unlimited SaaS plans with profitability…
- 🧠 Community Wisdom: Finding your voice on established teams, focus tips for ADHD brains, how to best use Granola,…
- 🧠 Community Wisdom: Designing great performance review templates, balancing oversight and autonomy with junior te…