Practical Product Volume II

Hi Reader-

As the old saying goes, “In theory there is no difference between theory and practice. In practice there is.”

My goal with this newsletter is to dive into the nuance of product management and give you practical help, so you can actually go apply what I write about to your job.

If you enjoy this newsletter, or think I can improve it, reply and let me know!

This week, we pick up where we left off last week, with a medley of product tactics and ideas to consider.

Let’s dive in…

Table of contents:

• 🥘 Food for Thought on AI replacing PMs?
• ⚙️ What Grinds my Gears on Feature-first PMs
• 💡 What I Learned from Building half a product, not a Half-a**ed product
• ❓ Practical Q&A on Working collaboratively with your Sales team

🥘 Food for Thought on AIs replacing PMs?

I think this tweet captures well the two sides of the AI debate:

Alex Sharp @ajsharp Within 2 years, product management as a function (ideation, coordinator, general middle management) will either become completely obsolete or more necessary than ever as a result of AI. I can’t decide which. 12:11 PM • Mar 11, 2024 0 Retweets 1 Likes Read 2 replies

​

​
Last week I shared the Lenny & Marty Cagan podcast, and I think this captures well what I think the reality is:

• If you work on a team where most of your job is order taking and project management, AI is a big risk for you. These tasks could easily be done by AI in the next few years.
  ​
• If you talk to customers regularly, source and synthesize data to make better decisions, and are a proven problem identifier and problem solver, then AI is far away from being able to do any of that.

The good news is, if you're in the first camp, you have some time.

Start developing your skills now.

Start consistently talking to customers, seeking data, and taking initiative. And if you're at a company that balks at you doing that, it might be time to look for opportunities to get away from being what Marty Cagan calls, "Feature Teams" and start working on a "Product Team."

⚙️ What Grinds My Gears: Feature-first PMs

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

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

And today, I'm talking about Feature-focused PMs.

Today's Grind: Product Managers who jump straight to feature design

It can be so tempting. You get an inspiring idea, a great suggestion, or your CEO comes to with a feature request.

You then jump straight to designing it.

Whether you sketch it out yourself, or go to your designer, you're off to the races figuring out what you'll make, how it will work, and when you can squeeze it into an upcoming sprint.

This is an all too common mistake I see my clients make early on, and we work hard to chart a better course.

There are a myriad of problems with following this approach to product development, including:

• Building a lot of half-a**ed features: It leads to rapidly building, then neglecting, features you add. We'll talk more about this in the next section.
• Your customers get confused: When you launch an idea-a-minute, it's hard to have a cohesive product that people understand what all you do and why.
• You can't improve your most important features: Every time you build something new, you're not making something you already have better. It's a tradeoff.
• Your success rate plummets 📉: Most importantly, when you shoot from the hip on ideas like this, for every major hit you have, there will be many orphaned failures.

So if just designing the next cool idea you, or someone else on your team, has is a bad idea, what should you do instead?

The better way? Focus on problems, opportunities, and data

Bold ideas are great. They're how a company stuck can break out, but you shouldn't just build randomly.

Instead, as a product manager, you should always know your customer and your data well.

You need to constantly be looking for sources of data and problems. That means:

1. Know your customers: Survey them regularly, interview them, bring them in for usability studies, listen to their feedback, form customer advisory boards for key deals, etc.
2. Make it easy for problems to find you: When support, sales, account managers, and others customer facing roles hear customer issues, how hard is it for that to get passed to you and your fellow PMs? Done well, this is an easy, constant stream of data.
3. Measure, measure, measure: Good product analytics is now 15+ years old with options like MixPanel and Amplitude readily available. There's no excuse not to measure the impact of every feature you launch, as well as critical funnels, workflows and features. These are your canaries in the coal mine for problems.

Now, doing 1-3 will help you make better product decisions, because you can triangulate the highest impact areas to work on, and know what key problems to make sure you solve.

Even better, when that next big idea comes along, you then have a framework to test it against:

1. What would have to be true for this idea to outperform what you've already prioritized? This helps you decide if it's worth doing now, or to save for another time.
2. What part of your customer base would this appeal to? If you know your demographics well, you can tell if this idea is promising for enough of your user base to be a good investment.
3. How can we quickly test this idea? If you regularly talk to and survey your customers, it should be relatively easy to quickly test if you really should re-prioritize your upcoming sprints to fit it in.

Yes, this is more work than jumping straight to building every new idea, but your success rate will go up significantly, and you avoid becoming this meme:

​

💡 What I Learned... on Building half a Product, not a half-a**ed Product

An important lesson I see over and over with PMs I coach is the tension between building lots of features and going deep on a few features.

Whether you have a CEO who is an idea-a-minute, let's-try-this-new-thing kind of leader, or you and your product team have tons of ideas on your own, it can be tempting to add that N+1th feature to your product.

Yet, that's not how you build lasting value.

The 37 Signals folks (makers of Basecamp, and other products) are particularly vocal about this and capture it well in their brief podcast episode here (~25 minutes)

That sounds nice, but what about in practice?

As usual, there's more nuance to this than we'd all like to admit, so let's explore it for a moment, because there's two sides to the coin with times for each to matter:

Side 1: You must provide value each step of the way

I love this image to explain what you should strive for in building good products from scratch:

Notice how in the second row, a customer gets value at each step, versus the top row is basically not helpful until the end.

In product at startups, I see many PMs rush to build features as fast as they can jumping from one feature to the next.

Unfortunately, that often fails for a variety of reasons:

• Poor adoption: When you throw a ton of features at people, they're unlikely to use them all. If you build *a lot* of features fast, it's hard to even educate people about all of them effectively (no one wants a 35 step product tour!).
• Lack of interest: The more features you add, the less likely every signup wants all of those things. Chances are they came for 1-2 key reasons.
• Poor execution: If you rush from feature to feature, it's very hard to get them right. All great features require iteration and a deep understanding of your customer.
• Diluted brand: When you do 8 things, but none of them particularly well, you won't be known for anything in your market. Your customers will also be much less inspired to share and evangelize what you do.

Side 2: Bigger deals necessitate many features

There are many markets, especially in SaaS, where feature wars are a fact of life.

I will never forget a walk I took with an early employee of a recruiting software company lamenting how they struggled with deals against a competitor for silly reasons like they had 15 features and the competitor had 16.

Yet, that was literally the feedback the marketing and sales team were getting. Ugh. 🤦‍♂️

And they're not the only case of this. In fact, it's common.

So what does this mean in practice?

• Some features block deals: Whether it's administrator tools, something IT or compliance needs, or just a buyer request (remember last week?), to get that exciting big deal, you do sometimes have to drop everything and build something for them.
• Some features are just for demos: I didn't believe this until I saw it first hand in the HR tech space. Watching Lighthouse lose deals for features I knew no one used, and that the buyer was pretty sure they wouldn't use, was an eye opener. The art of PM is recognizing what these features are, so you build them to sizzle in the demo and don't worry about depth in them vs. what really matters.
• APIs, Import/Exports, and integrations: Some features don't have to be features at all. You'd be amazed the effort you can save if you take the time to truly understand what the customer is trying to accomplish and do that and only that.

​

The truth: It's about finding balance, and truly understanding your customer.

I know. Not as catchy as "build half a product, not a half-a**ed product", but it's the truth.

You need to take the time on each feature and understand:

• Is this a central activity for your customer? Spend a lot more time iterating, measuring, and improving this.
• Is this a feature more about demo'ing than usage? Build it fast and make it sizzle, but don't worry about depth.
• Does this feature block a deal from closing? Get on the phone or go meet the customer to find out exactly what they need, so you can figure out how to build it best and how much it really has to do.

Then you should always look back and check:

• Was I right? Is a feature for demo or heavy usage? Did the buyer get what they needed?
• What does our data tell us? If a feature is not used much, should you kill it, or fix it?
• Did the deal close, and are there more like it coming? Sometimes sales exaggerates. This is how you tell if you need to call them out, or you can trust their advocacy.

This is how you tune your instincts, and can improve your relationship with sales.

But this (and everything we discussed in the prior section) takes time to master and set up, which is why we spend a lot of time on this with my coaching clients.

If you're struggling with this and want help, sign up to talk more about your situation here.​

❓ Practical Q&A on Dealing with a hostile Sales Team...

I saw this question on Twitter, and having seen this problem first-hand, knew I wanted to weigh in:

When product and sales aren't getting along, these are the kinds of tensions that can happen. Unfortunately, you can sometimes join companies where this has existed long before you joined, so you have overcome resistance caused by prior PMs.

To start to improve your relationship with sales and convince them to let you talk to customers, you can:

1. Talk to users after they've closed. Sales won't know and can't argue you're hurting their deals, but you'll gather insights that show why you want to talk to them.
2. When Sales wants a new feature, explain that to build it well you need to go talk to customers to get it right. Don't take no for an answer.
3. When you talk to customers, share insights back to key Sales team members showing when you learn things you can help Sales.

In the end, you're all on the same team. You should be winning together.

Bring that mindset to every interaction.

Then, whomever is most resistant in sales, try to meet with them to find out why they're concerned. They probably have bad experiences with prior PMs and you need to show them how you're different and assuage their concerns.

How was the second edition of this newsletter? What should I change, add, remove, or improve?

I appreciate ALL of your feedback, so whether it's fonts, colors, and design, or a section topic you'd love to see, or something else that inspires you, please reply and share.

My goal is to make this a newsletter you always want to open and that you find yourself sharing with fellow product people.

And if you enjoyed this newsletter, please share it with a friend, or to your network by clicking here.​

Thanks,
Jason
​
Jason Evanish
Fractional Head of Product, Coach & Consultant
How I can Help You: https://www.becustomerdriven.com/
​More Product Advice: https://jasonevanish.com/​
​

​​​​​