Welcome to Carl’s Newsletter.

In today’s issue:

• Build powerful no-code AI tools (not GPTs!)

• What it really takes to beat incumbents

• 10 tips for creating helpful metrics

• A Good PM Bad PM guide to working with engineers

Forwarded this email? Sign up here.

TheyDo is the single best solution for PMs looking to create user journey maps. No other tool comes close.

Imagine having all your user research in one place, mapped directly to your product experience. Viewing your customers' pain points and moments of delight in a visual, holistic way helps you build, prioritize, and get buy-in for a roadmap based on the concrete user needs, not assumptions.

With TheyDo's real-time collaboration, your team will be blown away by the insights you uncover together, while saving countless hours and taking your user mapping to the next level.

From Across the Product-Verse 🕸️

1. There’s an AI for that: No, this is not about custom GPTs. This is about build real, tailored AI tools specifically for your needs. In this thread, Olivia Moore shows a simple process for building an AI tool that detects who has a birthday coming up, finds a flower shop local to them, and orders a gift for them – all with ZERO manual intervention. This is the next wave of no-code, and PMs should start learning it now.

2. Falling into the chasm: PMs trying to defeat an incumbent often think to themselves, “I know I can build a product 10x as good as what’s already out there, current products in this space suck!” But they fail to understand the deeper reasons incumbents are so hard to beat. This graphic by Anthony Pierri is the best visual of this concept I’ve ever seen. Full post.

   

3. Good Metric / Bad Metric: In this fantastic post, John Cutler gives a nuanced take on what makes a good metric and 10 tips for how to create them. Metrics are the guiding force for many product decisions, so it’s worth it to invest time in getting them right.

Good PM / Bad PM: Working with Engineers

What strategies have you found most effective for collaborating with engineers as a PM?

At the core of what makes a process or communication strategy “good” are the following traits: empathetic, positive, direct / clear, easy / intuitive, manageable, and flexible.

• Empathy: Does the process and communication strategy hold space for everyone to share their feelings and perspectives?

• Positivity: Is the style and content of communication fostering an environment of optimism and encouragement?

• Directness / Clarity: Is the process or communication straightforward and easily understood such that less assumptions are being made?

• Ease / intuitiveness: Is the strategy or process simple to follow and makes sense intuitively?

• Manageability: Is the process overwhelming or resource intensive? A good collaboration process is effective while protecting everyone’s time. 

• Flexible: Does the collaboration process allow room to adapt to changing circumstances or needs? This flexibility is crucial for dealing with unexpected situations or changes in the environment.

How can PMs best understand technical constraints and tradeoffs when prioritizing features or planning projects? What questions should they ask?

First, you should always include engineering early on when you’re planning projects. This gives engineers the opportunity to make risks, unknowns, and limitations known early on.

Second, to best understand technical constraints and trade-offs, you want to ask engineers questions that are well-informed and open-ended. Well-informed questions are questions that show you have a basic technical understanding, a sense of the availabilities and limitations of technology and understanding of technical trade-offs.

An example of an ill-informed and closed-ended question might be “What is an API?” This question shows you lack familiarity with a core technology and the answer to this question has a limited response doesn’t lead to any productive answers.

Here are some examples of good, open-ended questions:

1. Are there alternative technical solutions keeping in mind the timeline and business constraints?

2. What tradeoffs are necessary for each possible solution?

3. What is the long-term maintenance impact?

How much technical detail do you find helpful for PMs to understand vs leaving it to the engineers' discretion? Where's the line between useful context and micromanaging?

There’s a baseline technical understanding you need as PM in order to communicate with engineers. That includes familiarity with the tech stack, key technologies and concepts, common terminologies, understanding of technical trade-offs, and the process and tools involved in building software.

The line you want to draw is concentrating on understanding how technical decisions align with business goals and impact the overall product outcomes.

This strategic focus helps avoid unnecessary micromanagement. Essentially you want to stay high level in your technical detail and not dive deep into the weeds of technical implementation.

For example, you should be able to discuss architecture and debate the trade-offs of various system design solutions with your engineering team. But you don’t need to understand every detail when engineers discuss which database service to use or how to implement it.

What’s the best way for PMs to ask for estimates from engineers? And if an estimate seems too long, how can a PM work with an engineer to understand why?

It all comes down to having an open line of communication with engineers, and the earlier and more often you bring up estimates to engineers, the better.

You won’t need to convince engineers that time to build is important–we all want to deliver the most value in the least amount of time possible. But you can add urgency by having a clear and logical explanation for why completing a project within a certain time period is important. So as soon as you’re ideating on a new project, bring engineers into the project and discuss timeline estimates.

In scenarios where estimates are too long, first and foremost make sure your mindset is right. I’ve worked with too many product managers where the mindset is “just do it!” But that’s disempowering when in reality you are part of the solution.

You should see yourself as an extension of the engineering team that works right beside them. For example, you can de-prioritize tasks, take over tasks to free up dev time, challenge devs to get creative with solutions with faster build times, change or remove requirements, etc.

Further reading:

1. How to Work with Engineers: A Cheat Sheet for Designers: While this is aimed at designers, it’s all applicable to PMs. Lots of first principles things about what engineers really do.

2. The top 5 things PMs should know about engineering: This guest post on Lenny’s Newsletter by Justin Gage, writer of Technically and growth at Retool, is a great overview of some common questions not answered above.

3. What’s your best advice for working with engineers?: I asked my audience for their best advice on working with engineers. Tons of tactical, real suggestions in the comments.

That’s All For Today

Don’t forget that as a subscriber, you get free access to:

1. My massive database of resources

2. A huge list of ChatGPT megaprompts to help you with product work

3. A 60-day guided tour of the best product content ever written

Here’s where else you can find me:

1. Follow me on X, where I post the most content, including lots of memes.

2. Follow me on LinkedIn, where I post longer-form content.

3. Follow me on Instagram if you just want the memes.

Last things:

1. Upcoming AI course: I am getting close to finishing my first-ever paid course “AI for Product Managers” which goes in-depth with tactical ways PMs can leverage AI tools to save hundreds of hours at work. If that sounds interesting to you, drop your email in this 1-question form and I’ll send you updates, sneak previews, and a discount code when the course is launched.

2. Sponsors: Carl’s Newsletter has its first official sponsor starting in two weeks! But there is still room beyond February, so if you or your company is interested in sponsoring this newsletter, I’ve posted sponsorship information on this snazzy new sponsorship page.