“You Don’t Want That!” — A Rant from Lance Walter on Product Management Communications

While I don’t normally entertain guest posts, once in a rare while I hear an old friend ranting about something and the rant’s so good that I offer up Kellblog to help share it.  Today’s rant comes from Lance Walter, who recently finished up a four-year gig as CMO of high-flying Neo4j, and who I know from previous stints working together at Host Analytics and Business Objects. Lance has run marketing at six startups (Pentaho, Aria, Host, Datameer, Capriza, and Neo4j) and led product (and/or product line) marketing at three before that (Hyperion, Siebel, Business Objects).  Trivia point:  like me, Lance started what would be a successful marketing career not in sales or marketing, but in technical support.  This might also explain why he, as we’ll see, gets so excited about a product FAQ.  

One day, not long ago, Lance was trying to send a scheduled email (i.e., send-later) from his preferred email service — which we’ll call CoolMail  — and he couldn’t do it.  Ever the former product manager, he endeavored to figure out why.  He found this in a FAQ. 

Q: Why Doesn’t CoolMail Offer Send-Later / Email Scheduling?

PM Answer:  A client-side Send-Later implementation does not work reliably since the device may not be powered on or have connectivity at the scheduled time, or the app may have been force-quit by the user.

As a result, most apps that offer Send-Later / Email Scheduling opt for a server-side implementation where the scheduled email is stored on a 3rd party server till it is sent at the scheduled time.

Obviously this has privacy / security implications since not only do scheduled emails need to be stored on the 3rd party server, but said server also needs to be able to access the user’s email server via SMTP in order to send the emails.

While similar security / privacy considerations also apply to Push vs Fetch notifications, in our view the need to be informed of new incoming emails promptly and reliably justifies a server-side implementation in that case, while email scheduling, although nice to have, is not as critical.

Let’s say this, for lack of a better word, triggered Lance.  Keep reading to learn why and learn how to avoid some undesirable patterns in technical, product-related communications.

Over to you, Lance → 

When I saw this in the FAQ, I had to stop and read it twice.  How did I, as a user, feel when I read this?

• I’ve annoyed them by asking for a feature.
• I don’t deserve a real explanation, or maybe they think I’m too dumb to understand it.
• I should be thankful they’re adding other features.

Basically, they’re telling me I’m wrong to want this feature because the scarlet widgetator can only do schmumble muck.  Not only did they tell me that I’m not getting the feature I wanted, but that I really shouldn’t have asked for it.

So do I think this is good product-oriented communications?  No.  In this post, we’ll analyze why and, more importantly, try to provide some tips for what to do instead.  

Let’s start with some empathy for the Product Managers (PMs) out there. It’s a hard, cross-functional job and situations like this, where you can’t give every user what they want are the norm, not the exception. Whether birthing new products or shepherding established ones, PMs never have enough time or resources to deliver what companies and customers ask of them.

A good PM has to be able to say “no” to their stakeholders while maintaining relationships.  That’s never easy, and sometimes PMs fall into one of three patterns that they really should avoid:

1) “Yeah, but if we implement this feature terribly, you won’t be happy.” The CoolMail PM makes this argument, in this case about implementing email scheduling as a client-side feature. Except that people don’t ask for client-side scheduling, which would be a dumb way to do it, as the PM explains. Note that the PM is also communicating like they’re in an internal meeting, presuming the requestor has an understanding of the meaning and implications of “client-side” and “server-side.”

2) “That would only work with an asynchronous widgetator and ours is synchronous.” The PM, going technical-ish, uses a few acronyms a user may or may not understand, but doesn’t provide a real technical explanation other than “this raises security issues.” The requestor likely hears something akin to, “this is complex, you wouldn’t understand it, and I don’t feel like actually explaining it.”  Dismissed.

3) “We didn’t put in a steering wheel because we care about safety and we view brakes as more important.”  Notice the not-so-subtle false choice here and at the end of the FAQ answer.  The PM explains why push notifications are more important, but the requester didn’t argue that email scheduling was more important.   All the requestor did was ask for something else.  And mentioning “other server-side features” isn’t relevant to this request.

So how can PMs communicate better than this, especially when dealing with skeptical prospects, stressed-out presales engineers, eager and urgent community leaders, or even angry customers?

1) Don’t just let them talk, listen. Nobody accepts a “no” when they don’t feel heard. Being fully-present, and paraphrasing back a feature request (in the requestor’s language, not your company’s feature-speak), will start to build trust and confidence before you’ve had to commit to anything. Bonus points if you can add/playback the context as well. “So Lance, you’re saying you want email scheduling so you can do emails at any time of day, but not bother your coworkers off-hours?” “YES!” says the I-just-felt-HEARD user!

2) Stay intellectually honest. The PM explains how a poor implementation of the feature would be bad. You’re the product manager.  You’re right, I wouldn’t be happy with a bad implementation — how about you make me a good one then?  PMs don’t have to unpack all their thinking for the audience, but they will lose the confidence of the audience (regarding potentially both their transparency and technical skills) if they throw out rhetorical strawmen like this.  The false dichotomy at the end is another example.  The user just asked for a feature, they didn’t argue its relative importance.  (Nor should the PM cherrypick sacred features against which to compare.)  A feature request can simultaneously be valid, valuable, and low-priority relative to others — all at the same time. 

3) Be transparent, even when it hurts. Just don’t surprise your partners or salespeople. Honesty is essential for trust in all relationships, and if you’re a PM and want stakeholders to trust you, be transparent about your constraints and high-level prioritization. Not, “they stole half my engineering team in Q2 to fix bugs in another product” transparent, but clear about having constraints. The answer to your customer is most-typically “not yet” at best, and “not ever” at worst, so make sure you’ve talked to whomever owns the relationship with that partner, customer, or prospect and is aligned (not just informed) on what you’re going to say. But once that’s done, it’s actually liberating to say things like:

• “We’re planning multiple upgrades to the Shmumble Console expected next Fall, so you won’t get this yet, but it’s on the list, targeted for late this year.” You’re telling the stakeholder that their request fits the strategy but isn’t coming yet.
• “Our strategy is horizontal for now, so I understand why this matters to regulated process manufacturers in Germany like you and I’ve documented it well, but for now it’s not making the cut for the next two releases and I can’t promise it will after that.”
• “This likely won’t be in our product roadmap because for now, this is a rare use-case, and rather than string you along waiting for this feature, I’d recommend you work with our services team, partner, open source community to create a manageable workaround.” In this and the prior comment, you’re telling your stakeholder that the request doesn’t fit the current, and likely future, strategy and that they need to take another approach. Granted, telling a customer “we’re not going to deliver that feature,” isn’t pleasant, but it’s more pleasant than if they feel like you’re telling them they shouldn’t want the feature in the first place. And it gives them productive options and a feeling of control since they now know that “saying nightly roadmap prayers” for another year won’t solve their problem.

4) Under-promise, over-deliver. If you didn’t already know this one, turn in your PM badge because you may not make it to the next GA.  ;-)

 Of course, there are also ways to be a much more collaborative and effective feature requestor. Maybe I’ll explore that in another post.

 What do other product leaders out there see that doesn’t and does work?

 # # #

Notes

• Thanks again to Lance for contributing this rant!
• I made a few edits to Lance’s portion of the post.  Mistakes are likely mine.