7 things that will earn you hate as a PM

+ Why Product-led growth is much more than just a free trial

In this edition of Behind Product Lines, we’ll explore:

• 7 things Product Managers do that earn them hate

• Why Product-led growth is much more than just a free trial (+ a mini-checklist)

---

7 things that will earn you hate as a Product Manager

I call them "hate magnets". Here we go:

1. Altering the scope of the sprint all the time.

Every Product Manager misses a user story point here & there. However, if your sprint plan is notoriously fickle and you have a tendency of creating a moving target for your team, you won't be winning many fans.

If you find yourself doing too many last-minute revisions, take a step back on your solution design process. I’ve found it is useful to write the feature scope in a memo format (this usually surfaces gaps in the narrative), then involve your technical lead & designer to get feedback early on.

Needless to say, changes in “specs” are far cheaper than shifting in-flight development.

2. Preferring to deliver lengthy documents but not talk to the team.

The Product Manager's job is to create alignment via effective communication. Documentation is essential but if you're not finding time to talk to them and take questions, you'll find it hard to inspire the team.

Process lovers like to enforce documentation and opening JIRA tickets. That’s understandable, however, without effective verbal communication, the relationship will remain fragmented.

3. Never crediting the team after a successful sprint.

After a feature is lauded by customers, it's the Product Manager's job to praise the team and appreciate their efforts. They deserve that & you're the one that needs to take that lead. If you're not dropping a shout-out on Slack, email or townhalls, you're falling short. Taking things for granted makes the team feel as a cog in the wheel.

4. Wearing false charm when you need devs to work overtime.

Walking in an afternoon and engaging in small talk only to break news how you need an urgent user story added to the build tonight won't fly well. Be honest, transparent and genuine.

Work on building a relationship with development & design from day 1. Understand what drives them and create a bond. Earn sufficient trust that enables you to walk up to them to discuss what you need from them.

5. Claiming that a gap in the spec was too obvious to mention.

If a bug is introduced because the spec didn't specify an action on it, Product Managers should own that and head towards a fix. Blaming others to use their “common sense” will put a target on your back.

While it’s reasonable to expect certain level of expedience, a PM should seek to learn what kind of documentation model works best for the team at hand and adapt accordingly.

6. Being a "yes-man" to the manager and a grouch to the team.

The team notices how you act in front of your manager. Yes, they notice your unnatural high-pitched voice, your zestful nodding, your trembling hands and your subservient body language.

But if you channel pressure from up top into dictatorial authority towards your team, people won't respect you for that. Bifurcate those relationships & collaborate as equals.

7. Someone who trivializes changes without any estimation effort

Changes are inevitable but how you present them is extremely important. If you're unilaterally classifying your last-minute twists as "small" and "super easy" without listening to the developer's point of view, that won't sit well in the long run.

< Bonus Hate Magnet >

Eating away the allotted time quality assurance has to test the build to jam in another story...and then projecting blame at them when the build breaks on production.

---

Product-led growth ≠ just enabling a free trial.

Product teams that attempt weekend hackathons to adopt "product-led" underestimate what's really required.

First, PLG is paradigm shift at an organizational level. All departments are affected.

👉Marketing has to re-configure their messages and CTAs.
👉Sales needs to relearn a new lead process and understand how to deal with product-qualified leads.
👉CRM teams needs to be cater for free trial/freemium packages & update their lead flows.
👉Engineering & design now need to factor in a "self-serve" mentality in their experience-related decisions.
👉Support needs to retool their scripts.
👉Legal has to draft new compliance rules.
and so on.

Second, this isn't about slapping on an onboarding flow, rather, you need to rearchitect the end-to-end user journey. Figuring out how the product can independently acquire, activate and retain users takes time.

Third, there are several support mechanisms you need to cater for.

For example:
1- In sales-led models, sales & finance teams email invoices. Now, the product needs to be able to generate invoices on their own.

2- Similarly, previously, development would configure features during the "implementation" phase. Now, the product needs to be capable of gating/un-gating features based on the purchased tier automatically.

and so on.

Finally, product metrics won't track on their own.

By deploying a tool like Mixpanel, you'll have to set it up to measure acquisition, funnels & cohorts so that you can make informed decisions moving on.

The diagram above shows a basic checklist of things we had to cater for in our product-led experiments. This is NOT an exhaustive list though & you don’t need all those elements all at once. But they still need to be considered & you need to be ready to entertain several other nuances that show up during deeper planning.

One things for sure - without leadership buy-in and/or failing to set this as an organizational priority, traditional sales-led teams will inevitably struggle to reap the benefits PLG provides.

Moreover, you don't have to forego your sales-led channel when moving to PLG.

Elena Verna explains this point well by suggesting how you need to “layer on” a PLG motion on existing models. If you’re sales-led today, there will remain customer groups that prefer a human interface as their first touchpoint. Hubspot is a great example that deploys such hybrid models with remarkable success.

So, don't rush. Think before you PLG.

---