Practical Product Volume IV

Hi Reader-

What have you been learning from lately?

I've been reading Marty Cagan's new book "Transformed" and really enjoyed the refresher on essential product management tactics, as well as how it breaks down common problems in organizations that discount the value of product management.

This week we take a look at insights from a product leader who worked at both Atlassian and Shopify, the problem with many PM's specs, and some Pro Tips you can apply to your customer interview notes.

Let’s dive in…

Table of contents:

• 🥘 Food for Thought on the Value of Support Teams
• ⚙️ What Grinds my Gears on Product Specs/Reqs
• 🤫 Secrets of Product Pros on Customer Interview Notes
• 📊 Poll of the Week on How Frequently do You Ship?

Did a friend share this with you? Get this newsletter straight to your inbox every Friday by signing up here.

🥘 Food for Thought

I saw a clip from this interview and was curious to hear more; anyone who has helped build products at not one, but two, mega-successful SaaS businesses has my attention.

And Jean Michel did not disappoint.

He took the interview in a number of directions that the host didn't plan, but those were where many of the biggest gems came from, including the quote above.

Product & Support should be like Peanut Butter & Jelly

As Jean Michel highlights, he learned *a ton* by taking on support responsibilities when he started at Shopify.

It's hard to beat the experience of not just communicating with customers, but seeing where they struggle with your product. Those moments of frustration can often make or break your product:

• 😌 Make it: It's a huge relief to have your problem solved, shown that your product can do what they hoped, or feel heard and know that someone is going to help you.
• 😡 Break it: It's very frustrating, and might cause someone to churn, if they feel ignored, told they can't be helped, or feel like their request is going into a black hole.

And when Support and Product teams are disconnected, you create a lot more 😡 Break it scenarios than those product teams ever realize.

What is your relationship with Support like?

Take a minute and think about how you and your team interact with support:

• Is it frequent and highly collaborative, so that information flows both ways regularly, helping you build better products and the support team feels heard?
• Or is it rare, contentious, or even non-existent, leaving support unsupported and customers struggling?

For most of you, it's probably somewhere in between.

So how can you improve your relationship with support?

The good news is that regardless of your company's size, or your role in your organization, you can improve your relationship with support.

Here's some battle-tested tactics I've used over the years and seen my coaching clients implement to make a real difference:

• Make sure feature requests are getting to your team: This is the first and simplest one. Just making sure who requested what feature or improvement gets you started with building value. For bigger teams, it's important that the requests get to the right Product team.
  ​
• Teach your support team how to ask a followup question or two: Just getting what the customer says (and who said it) is a start, but the best insights come from understanding a little bit more. If support can ask them, "How would that help you?", "What problem does that solve for you?" or "How important is that problem to you?" will all get valuable context deeper than just a feature request message on its own.
  ​
• Have peer 1 on 1s with a key support leader: Being a PM means you're in the people business, and peer 1 on 1s are a great way to open lines of communication as well as iterate on processes so they're win-win all around. A monthly meeting with a support leader is a high impact peer 1 on 1 to add to your calendar.
  ​
• Get engineering to help out with support: This one can be harder to get buy-in for depending on your culture, but can have a great impact like Jean Michel described. I've seen this done a few different ways successfully. Try what works best for your org:
  • First week on the job: Some companies will start their engineers in support. Fixing bugs for customers is a great way to learn a code base, get a morale boost feeling like you did something good, and get to know your customers you're building for.
  • 1 day a month: Similar to the first week, this is a way to keep your engineers connected to customers without it feeling like it's taking away from their core duty of building.
  • For new features they help build and launch: If your company cares about craftsmanship, this one in particular is a great option. This puts your engineers (and perhaps you and design) on support for requests in your product area, making it easy to identify and fix issues post-launch.
• Try AI tools to help you: Tools like Viable AI, or if you dump a bunch of feedback into a spreadsheet and then upload it to Claude for analysis, can help you parse massive quantities of feedback, so this is a great idea if you're at a larger company.

These are just a few of the approaches you can try. If you have peer 1 on 1s with someone in support, they may have some great ideas, too.

The point is you should use trial and error plus experimentation to find what works best for you, your team, and your culture.

Are you tapping into the power of Support as a source of insights, problems, and opportunities?

If you have questions about your situation, reply and I'm happy to help you brainstorm what you can try in your situation.

⚙️ What Grinds My Gears

This section is for rants, complaints, and hard critiques I have about the product management industry.

If you remember Family Guy, this is inspired by Peter Griffin's rants:

Today's Grind: The Product Spec / Product Requirements document

Let's talk about product specs.

On one hand, these are the most important documents a product manager produces regularly.

And on the other hand, they're one of the most common mistakes product managers make.

So many poorly built features can be traced back to a poorly thought out, poorly planned, or bloated product specs.

Words matter.

Word choice can be really important. And in the case of product specs and product reqs, the word choice is part of the problem.

Let's look at these words:

• Specifications means "a set of documented requirements to be satisfied by a material, design, product, or service."
• Requirements means "a comprehensive technical document that precisely defines the requirements, characteristics, and expected performance of a product or service."

The problem with both of these words in this context is they are too prescriptive of solutions.

And that's exactly the mistake I see too many PMs make.

A good Product Spec should start a conversation, not give orders.

Unfortunately, a lot of product specs I've reviewed over the years (and even more I've heard engineers and designers complain about) are basically a dictated solution.

They spend all their time describing what they envision is the solution, even often including mockups and sketches.

This is a terrible way to build products.

It robs you of the ideas your designer and engineers could contribute, and it misses out on what really belongs in a product spec.

The Product Spec Thesis

To reinforce the idea of focusing on collaborating with other members of my product team, and make sure I'm laying information to spark great product conversation, I call my product specs a "Product Thesis".

The purpose of a thesis is "to present the author's research and findings and demonstrate their understanding and expertise in the subject matter."

Isn't that a lot closer to what your product spec is supposed to be?

A good spec thesis should include: (See all 9 categories here)​

• The problems you need to solve
• Why this is important to solve now
• Data and customer insights that support and give context
• Future considerations that could affect what you build
• How you'll measure success or failure

These things are a lot more about the research you've done than a list of requirements you prepared to order your engineers and designer to go create.

Does your Product Req/Spec/Thesis dictate to, or empower your team?

Whatever you decide to call it, the important message here is to stop thinking in solutions and start thinking about how you can present the research you've done in a way that sparks a collaborative discussion.

Because in the end, the ideas a single person comes up with will *NEVER* be as good as what you, a designer, and your engineers can come up with. And that's not just me saying that, it's how Steve Jobs did it.​

If your product specs are a little bit too solution-focused, and not enough problems/data/etc, then give them a tune up by learning more about the Product Thesis approach here.​

🤫 Secrets of Product Pros: Your customer interview notes

One of the first things I often do to help PMs I coach is to take a look at their customer interview process.

Now, they typically assume that it just means helping them ask some better questions and tune up their interview habits.

Yet, one of the highest leverage things I do is show them how to supercharge their notes.

Turbocharging your customer interview notes

There's a few things great PMs do differently with their notes. That includes:

1. Preparing consistent questions ahead of time: I'm amazed, and disappointed, how often people wing their discussions. Having a consistent script you follow (with deviations okay when customers are on a roll) ensures consistent, quality insights.
2. Researching the customer before the meeting: You shouldn't ask questions you can easily find the answer to on your own. Instead, look them up ahead of time by finding them on Linkedin or other social networks, checking your Admin panel, analytics data, etc.
3. Reviewing and organizing your notes after: Having customer interviews is great, but you need good notes to reference later. By reviewing them post-call you can add things you didn't have time to write in the moment, and organize anything that accidentally ended up disjointed.
4. Putting key takeaways at the top: Future you will be quite grateful if you put your 5-10 biggest takeaways at the top of your notes; this makes it easier to quickly review your notes later, and figure out which of your 7-10 interviews was a specific discussion without having to re-read everything.
5. Adding quotes and links from the interviews to your product thesis: A key job of great PMs is to curate information. A great way to show your engineers and designer that you've done your research for the new project is to include the voice of your customer in your thesis, and link back if they want to see more.

Taking these steps is what helps you maximize your time with customers and make the most of the insights you get from them.

Templates and shortcuts are your friend

Now, this may initially seem like a lot more work, but it's not as bad as you may think:

• With AI transcription tools, it's easy to have good notes that you then just need to mark key takeaways for.
• If you write up a script before your first call, you can copy that for all future calls.
• You can create bookmarks to make it faster to research your customers.

In the end, you get out what you put into your customer interviews. These 5 tactics can help you make the most of them.

📊 Poll of the Week on Shipping Rates

Each week, I post a poll on Linkedin. Here's this week's poll, (which you can vote for here):

In coming weeks, I'll share the results from prior polls with some commentary, and that week's poll for you to join.

So why don't you join us and take the poll here.

We covered a lot of ground today.

What did you think? How can I improve, or what would you like more of?

Reply and let me know.

And if you liked this edition, you can share this and my other editions with your fellow PMs here.

Thanks,
Jason
​
Jason Evanish

PS: Did a friend share this with you? Get this newsletter straight to your inbox every Friday by signing up here.​
​
Fractional Head of Product, Coach & Consultant
Get Product Help: https://www.becustomerdriven.com/
​More Product Advice: https://jasonevanish.com/​
Schedule one time coaching: https://intro.co/jasonevanish​
​

​​​​​