👋 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:

• Amsterdam. April 9th. Thanks to Laura, @Niek van der Zwaag, @Adriana Mosnoi, @Catherine Tang & @Ruslan Doronichev!

• Ann Arbor. April 18th. Thanks to @Kayla Mandel!

• Austin. April 16th. Thanks to @Andy Keil - Austin!

• Barcelona. April 8th. Thanks to @Marc Bisbal!

• Berlin. April 7th. Thanks to @Özge Yıldız!

• Budapest. April 9th. Thanks to @tamas!

• Chicago. April 17th. Thanks to @Shivam Malhotra!

• Denver. April 22nd. Thanks to @Prachi Jhala!

• Dubai. April 9th. Thanks to @Ane!

• Kansas City. April 22nd. Thanks to @Richard Enlow!

• London. April 23rd. Thanks to @Anna Popova!

• Los Angeles. April 10th. Thanks to @Laide!

• Madrid. April 29th. Thanks to @Giulia Camargo!

• Mexico City. April 9th. Thanks to @Chris Stanislawek!

• Munich. April 22nd. Thanks to @Lukas Gerhardt!

• New York. April 16th. Thanks to @kaila & @Ryan Schwary!

• Philadelphia. April 8th. Thanks to @Keriann Sabatini & @Kamilla Yunusova!

• Sacramento. April 30th. Thanks to @Michelle C!

• San Francisco - Side bar Summit. April 23rd. Thanks to @Schaeffer!

• Seattle. April 15th. Thanks to @Rawi Nanakul & @Joshua Debner!

• Singapore. April 9th. Thanks to @Shuhang!

• Toronto. April 23rd. Thanks to @Raf V.!

• Washington, D.C. April 18th. Thanks to @Anurag!

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 episode this week

A better way to plan, build, and ship products | Ryan Singer (creator of “Shape Up,” early employee at 37signals): YouTube / Apple / Spotify

💥 Top threads this week

1. Prototyping vs. writing PRDs

Q: In Mihika’s guest newsletter, she recommends prototyping over PRDs. Does anyone have practical tips on how to actually do this? Examples and what you used (Cursor, v0, Lovable, Base44, etc.)? ↗️

—Amir Klein

German Retamosa: In my case, I love Perplexity Deep Research > UX Pilot > Lovable > [Supabase] > Cursor. That can mainly be for websites, but there are also alternatives for mobile apps.

Nan: I often use spreadsheets for prototypes. You can draw boxes, manipulate text, write scripts and formulae using data, etc.

Ala Stolpnik: Prototyping is great, but I don’t think it replaces PRDs, because they serve different goals. Prototyping helps the PM to experiment and validate ideas. A PRD helps them communicate these ideas to engineers and others. While a prototype can help communicate functionality and it can replace UX designs to some degree, there are things that it can’t communicate: the why behind the feature, the constraints, non-obvious edge cases, the non-functional requirements. These are all things engineers need to know to be able to build the real product. If you have a prototype, the format and comment of the PRD might be different, but I don’t think it replaces PRDs entirely.

Shivam Malhotra: I agree PRD and prototyping serve different purposes, and they complement each other well. I love prototyping because it helps visualize the idea and uncover details or edge cases that can be missed with just words. Regardless of the tool, it’s a very effective exercise.

• For 0-to-1, I have used wireframes in Lucidchart and Miro, as well as hand-drawn sketches.

• To redesign a customer journey, I would take screenshots and text overlay.

While I’m a fan of AI tools like Lovable and Replit, especially for seeing ideas in action, I haven’t been able to use them at work due to restrictions.

Jarrett Blankenship: I don’t like to be too dogmatic about it. It depends on the individuals in your organization and what you’re trying to communicate. Sometimes it’s much easier to communicate through visuals and interactive prototypes. Sometimes it’s easier to just write down a bullet list. I believe you should develop your skills with both tools but use good judgment on when to apply them.

Ben Erez: Shared some thoughts here recently on why I hold off on PRDs until the very last minute and start with designs as early as possible to get the right conversations going.

Joshua Herzig-Marx: I think the thing to remember is that your job, as a product manager, isn’t writing PRDs. Of course, it’s not building prototypes either. Your job is to make sure the company creates as much value as possible with the limited resources it has: limited time, limited budget, and limited people. Over the years we’ve come to realize that our products tend to be better if:

1. We talk to customers and users to make sure we’re solving real problems for them, and that the solutions we build will actually work.

2. We engage the entire cross-functional team, but especially engineers, so that they understand our users and their needs and the business and its needs and have a real role in selecting and designing the solutions that they build.

Said differently: You can be an outstanding product manager even if your PRDs suck. Even if you don’t write PRDs at all. The value of a PRD is just to have better conversations with your engineers (I think I did a decent job explaining why and how on this podcast). But a prototype can serve that need as well as be something you can share with your customers/users.

Christoph Steinlehner: Adding it here because you mentioned AI code-generating tools for prototyping. There are many other ways to prototype. Start with what factor you want to de-risk, and then think about the prototype. Your prototype can also be a one-pager you discuss with a customer, a role-play, a concierge service, etc. The book Testing Business Ideas is a great resource for a wide range of prototypes.

2. Managing the emotional aspects of a career change

Q: I’m transitioning from my role as the first PM at an early-stage startup, now a series B startup (worked there almost 3 years), to a more mature competitor, and I’m looking for advice on managing the emotional aspects of this change. The move makes sense professionally:

• The new company offers better growth opportunities and mentorship. I had stopped learning and growing in my current role over a year ago, and having never received structured mentorship, it was something I deeply wanted

• More experienced team and mature product with x12 more users. I’ve rarely worked with PMs more experienced than I, so I am looking forward to learning from them

• Better compensation

However, I’m struggling with:

• The emotional challenge of working on a competing product that could impact my previous company’s success

• A difficult departure—the founders attempted to enforce a non-compete clause and abruptly cut off access without a proper goodbye despite all the time I spent there. To be fair to them, they were good leaders and I do understand their emotional reaction, but still . . . it stinks

• Guilt about leaving, despite this being a positive career move

In retrospect, when accepting this offer, I underestimated how important these emotional factors would be. Has anyone navigated a similar situation? How did you handle the emotional transition and start fresh at the new company while honoring your past contributions? ↗️

Dustin Coates: “The thing about the old days: they the old days.” First off, congratulations on your new role! You were hired to do a job, and you did that job. The company grew during your three years there, and that’s all that your now-former coworkers can truly expect. This company that you’re leaving—did they ever fire anyone while you were there? I’m guessing they probably did. They did what was right for the company, and you’re doing what’s right for yourself. So long as you didn’t lie about where you were going or steal sensitive information on the way out, then you’re in the clear. You have a long career ahead of you, and anyone who is expecting you not to continue with that is being selfish. (Indeed, in many industries, this is even expected.) As for what you can do: enjoy the new role and stay in touch with people from the previous role whose company you enjoyed. Who knows where the paths will overlap again.

Matt Gonzales: Adding to this and because I think this is important, overall, for the PM profession: ask yourself what you do and don’t control in this whole situation. My perception here is you have a lot of empathy. In my opinion, this is such an important skill or quality for PMs to have. Part of having empathy is being able to understand someone else’s perspective. You’ve seen the “negative” perspective here (trying to enforce non-compete, negatively impacting former company, guilt about leaving). So then what are the neutral or positive takeaways? One “neutral” take here is that your leadership seems to feel strongly about you leaving. Why? Maybe they are afraid of how effective you’ll be, maybe they hate losing you, maybe they aren’t processing their own emotions well. Maybe all of these. I’m calling this out because I think in this situation, and generally in PM, I think we necessarily need to be super-intentional about defining the things we do and don’t control and empathizing with why people say specific things or behave in specific ways. And the brass tacks of it all:

1. Why do you want to stay at an org that handles a departure in this way?

2. Why is it your responsibility to sacrifice personal/professional growth to compensate for another team or company’s performance?

3. What does and doesn’t happen if you change your mind and stay with this current company?

Joni Hoadley: Thank you for sharing this—it really brought me back to a similar emotional transition I went through when I left Sonos after several impactful years. What helped me navigate the complex mix of pride, grief, and uncertainty was a quote I leaned on heavily: “Don’t cry because it’s over. Smile because it happened.”

Dr. Seuss might not be a career coach, but that perspective helped me honor what I’d built without being paralyzed by the ending. I really appreciated what @Matt Gonzales pointed out about empathy and control. It’s easy to internalize others’ reactions—especially when they’re intense—but sometimes that’s just a reflection of how deeply your presence mattered. The discomfort doesn’t mean you made the wrong call; it means you were all-in. And that’s something to be proud of. Your past contributions don’t disappear just because you’re moving forward—they’re part of the foundation you now get to build on. Rooting for you as you start this next chapter!

James Conway: I experienced an emotional transition as part of a career move from Civil Engineering to Management Consultancy. When I took the role I didn’t realise that I would have to leave behind my identity and path to becoming a Chartered Civil Engineer (I think the US equivalent is Professional Engineer). It took me months to realise that the reasons that I had changed industries and roles were similar to you—growth, compensation—and in my case a new, intellectually stimulating challenge. Those reasons hadn’t changed either side of the physical transition period, but I wasn’t prepared for the emotional transition. It felt like shedding my identity as a Civil Engineer. It took a few more career transitions before I truly internalised that my identity is not my job (Civil Engineer) or the company I work for (IBMer, Comalatechie, Firefly. . .). I’m lucky that the company I currently work for doesn’t have a demonym, but also note that I say “the company I currently work for,” not my company. Sometimes as individuals these lessons don’t really make sense or resonate until you have walked the path. You will likely have more career transitions in the future, and what you are learning right now will help you be more ready in the future and also able to support others going through their own transitions.

3. How people react to AI art

Q: Interesting thought experiment: Why do people say “generate image ‘in the style of Studio Ghibli’” but don’t say “generate code ‘in the style of Apple/Google’”?

Follow-up question: Why do people get offended when AI is trained on artworks but not by code (both done by real people)? Yes, coding is way more objective in nature. But this is for the people who believe “coding has art to it.” ↗️

—Rajesh Raghavan

Daniel Bartholomae: People are offended when AI is trained on code, but similar to arts, the people who just use it are typically less offended than those who created it in the first place. In case of code, that’s mainly open source maintainers: see here. Btw. also related to “in the style of Apple/Google”: these companies are big enough to prevent people from training their AI on their code. And open source contributors don’t have strong brands like this.

Miroslav Pavelek: Do you know what the Google style looks like? And if it is pretty? That will be the main reason for this.

Also, as told above, all “artists” have issues there. And there is also one big difference —art creators are already directly threatened by AI—instead of earning $50+ for a commission “draw me in cute anime style,” everyone can use ChatGPT now. So AI may have direct negative business impact. But engineers believe AI won’t have a negative impact on them.

Ashley Rolfmore: Apple doesn’t contribute to much OSS compared to Google—much of what they do is behind closed doors. So there is very little to go on, would be my guess.

My (anecdote not data), standard dev employment contracts include an IP element—mine all have. Even my contractor contracts have statements on who owns what and, if there is something patentable, what happens. When I leave a company, normally any materials I made specifically for them, including code, belongs to them. I usually have to negotiate to be able to contribute to OSS. Artists and writers typically also negotiate this sort of thing per client. AI accidentally barges into the middle of something that is considered a contract issue between an employer and employee, or freelancer and client, and goes “nope, that’s mine no matter what your countries’ laws said about it and what you two entities signed on a contract.” I suspect coders are less offended because they’re used to giving their IP away, artists/writers less so—in fact, copyright law exists to protect IP.

A similar sort of thing happened in the ebook world—lots of writers authed book rights with publishers and didn’t have ebook rights negotiated alongside, meaning a lot lost out.

Daniel Bartholomae: May be a bit of a tangent, but that’s, e.g., one of the interesting differences between German and US law: in Germany, there is “Urheberrecht,” which means that it is impossible to sign over rights for a channel that doesn’t exist. So when ebooks came up, publishers needed to negotiate again with authors to get the rights to publish. This also has the downside that some books most likely will never be published in an electronic form, as they require permission from a lot of authors and it is just too hard to find all authors and get their approval for ebooks. Coming back to AI, this also might be a reason for the bigger skepticism in Germany.

Ashley Rolfmore: I’d argue it’s not a tangent—see this thread. This is UK-specific, but it mentions muting some aspects of existing IP law to facilitate training datasets.

4. How to navigate feature requests in a fragmented industry

Q: I was talking with a startup founder in the construction industry today, and he highlighted several difficulties during the conversation:

Targeting specific user types: Targeting one particular user type is challenging due to varied feature requests and requirements across different projects and geographies.

Managing feature requests: There is a temptation to either build very specific features for a small audience or constantly add new features, which can lead to losing the product’s main direction.

Expanding product scope: Starting with a niche product and then expanding to a more generic tool has led to numerous feature requests from different user profiles, making maintaining a clear product vision challenging.

Adoption challenges: The fragmented nature of the construction industry and the diverse needs of different user profiles make widespread adoption of the product difficult.

The construction industry is a very interesting space, but how could you tackle these challenges? ↗️

—Mirco Bianchini

Marc Dupuis: Perhaps too generic of a response, but the more you talk to buyers and customers, the stronger your POV will be and the more conviction you’ll get in your vision. When you have that, you’ll understand if requests fall on the path to that vision or if they’re a detour. You want to lean in on the features and requests that your users are pulling you towards as long as it’s aligned with your vision. If you have a weak vision and a weak understanding of the problem, a lot of these questions will plant seeds of doubt and confusion. Clarity of vision isn’t fixed, it ebbs and flows, but the sharper it is, the easier these questions become.

Mirco Bianchini: Agree! It sounds like these guys started by getting a feature for a product and then attaching a vision that it should be helpful in every project. However, because the underlying technologies (LLMs) can be used in different ways, they are now looking at many other features and requests.

Joshua Herzig-Marx: One challenge as a startup founder is focusing on your ideal customer . . . at the moment. There’s always this (reasonable!) fear that if you don’t target a sufficiently broad set of users (or customers), you’ll miss out on a big opportunity. It’s really hard to get them to change this view, but one thing to try is to help them develop a strategy with a set of milestones, and that those milestones let them unlock new users. You can point to a set of feedback from a user like a surveyor and say, “Good news! We’ll deal with that in phase three, because right now we’re in phase one and focused on the foreman and we want to make sure we do a great job for them!”

Mirco Bianchini: Which sounds like focusing on a strategy based on the vision they have and sticking to that.

Joshua Herzig-Marx: Right. You can also set a cadence for reexamining that strategy. Because business context does change! You can say, “Hey—it seems like maybe we want to shift around which persona we focus on next. I’ve added that to the agenda for next month’s strategy meeting.”

Mirco Bianchini: I told him that the construction market is big and fragmented. You enter the market with a very specific product and grow your capability around that, so you are in a vertical phase! In this phase, you listen to feedback and start to evaluate little things. Once you grow your skills and understand your clients, you start to grow horizontally. This process could be very iterative.

Joshua Herzig-Marx: That’s a good way to approach it. I’ll often say something like “We’re a company of x engineers and limited capacity. I don’t want to lie to you about what we can accomplish. Let’s establish some principles and set a direction, make sure we’re always honest about how much we can actually build, and focus on using our scarce resources to create as much value as possible.”

Nan: Something that we often do is build targeted solutions and then market those solutions to broader audiences. Instead of “we solved your problem” . . . “Here’s a problem you didn’t know you had, and we have the answer.”

Mirco Bianchini: Interesting!! Sounds similar to Gaurav’s points.

1. Why the “ship a marketable feature every week” approach helps his team stay focused and the product stay top of mind for users amid constant AI breakthroughs

2. How to balance rapid shipping with maintaining quality by cutting scope rather than compromising on timelines

Bernard Desarnauts: Oldie but goodie on this topic: 1,000 true fans

🤓 Top finds

1. The case against conversational interfaces via Rishi

   “The future isn’t about replacing existing computing paradigms with chat interfaces, but about enhancing them to make human-computer interaction feel effortless—like the silent exchange of butter at a well-worn breakfast table.” A good post arguing that conversational interfaces may not be the lasting form factor for many use cases.

2. 44 Harsh Truths About Human Nature—Naval Ravikant via Martin Bavio

3. SaaS isn’t going to die. SaaS is just going through puberty via Guy Peled

4. Bubble Trouble via Anuj Adhiya

5. What to do via Kiyani

😂 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​ ​g​i​f​t subscription 💞 There are group discounts, gift options, and referral bonuses available.

Give a gift subscription

Sincerely,

Kiyani 👋