Category Archives: Product Strategy

“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?

 # # #


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

Join us for Tomorrow’s SaaS Product Power Breakfast with Skilljar Co-founder and CEO, Sandi Lin

Please join us tomorrow morning at 8:00 AM Pacific for the (final in this form — see below) SaaS Product Power Breakfast with Skilljar cofounder and CEO, Sandi Lin, discussing why product managers make great founders and the potential pitfalls they should look out for along the way.

Skilljar, founded in Seattle in 2013, is a fully distributed, ~150-person company that provides a customer education platform to over 400 customers that’s raised $50M+ in venture capital from top investors including Techstars Seattle, Trilogy, Mayfield, Shasta, and Insight Partners.

Sandi is well, a dynamo, with an impressive academic background (two engineering degrees from MIT and a Stanford MBA) matched by equally impressive work experience (~4 years in consulting followed by ~4 years at Amazon in product management followed by co-founding and leading Skilljar).  Our prep call was a whirlwind; it should be a great episode.

Among others, we’ll address these five questions with Sandi:

  • Why do product managers make great founders?
  • How has your product planning process evolved from founder to startup to scaleup stages?
  • As CEO with a product background, how do you interact with your product team now? Has it been challenging to pull back?
  • You used to work at Amazon. What are key similarities and differences in product management from a large company to a startup?
  • What have you found as your blind spots as a former Product Manager?

Thomas and I hope to see you there!

The End of This Format; The Start of a New One
I should note that this will be our last episode in this current form.  While we are pleased with the success of the podcast version of the SaaS Product Power Breakfast, the live rooms have several drawbacks we’d like to address:

  • The platform.  While we started the series on Clubhouse as a deliberate way to participate in the evolution of a new app, I believe the platform has technical limitations for what we’re doing and, moreover, is in general trouble.  We’d like to try something else.
  • The name.  While Thomas is in Germany and I am in Silicon Valley, we nevertheless decided to call the series a “power breakfast.”  That instantly posed timezone challenges for the live events (e.g., Thomas has a “power breakfast” over a beer at 5:00 pm) and didn’t translate well into the podcast.  Moreover, we have strong international audience that should only grow with the recent announcement that I’m joining Balderton Capital as an EIR.  So the name was a fail and that’s on me.  We need a new one.
  • The timing.  I’m not sure how to fix this one, but 8:00 AM Pacific isn’t a great time for a live event.  The West Coast is just starting work, the East Coast in their last meetings before  lunch, the UK is getting ready for a pint, and continental Europe finishing up before heading home for dinner.  With Thomas and I separated by 9 time zones, maybe the best answer is no live event at all.  Just a podcast.  We’re deliberating.
  • The duration.  While an hour is a relatively short Clubhouse room, it’s a relatively long podcast.  We should take a lesson from Harry Stebbings of The 20 Minute VC and work towards a shorter format.  Who knows, maybe it will be The 21 Minute Product Leader.  (Think:  ours goes up to 11)

To those who’ve attended the live rooms and/or listened to the podcast, we thank you.  Thomas and I will be back in several weeks with a new name, a new platform, and a new format.

Join us for Tomorrow’s SaaS Product Power Breakfast with Dan Faulkner of Plannuh on Building Great Product Teams

Please join us for tomorrow’s SaaS Product Power Breakfast where we’ll speak with Dan Faulkner, CTO of Plannuh, about building great product teams.  I serve as an advisor to Plannuh and I wrote the foreword for their book, The Next CMO, which Dan co-authored with Plannuh founder and CEO Peter Mahoney.

After getting a master’s in speech and language processing, Dan worked for speech recognition powerhouse Nuance for well over a decade, first as a researcher and later moving product and business unit management.

Our topic will be how to build great product teams.  Among other questions, we’ll ask Dan:

  • What makes a great product team?
  • What is his four-part framework for thinking about product teams (e.g., context, talent, change, and location)?
  • Why context matters so much?
  • How to deal with the army you have vs. the army you want?
  • How to think about change and risk?
  • The tradeoffs in location strategy and colocation of PM and ENG?
  • How to think about and drive diversity across a number of dimensions?

Hope to see you there!

Join us for Tomorrow’s SaaS Product Power Breakfast with Alation Cofounder Aaron Kalb on Design, Data, and Disagreement in PM

I’m delighted to say that tomorrow’s SaaS Product Power Breakfast will feature one of my favorite people to riff with, Alation cofounder Aaron Kalb.  Our topic will be on design, data, and disagreement in the context of product and product management.

In addition to cofounding Alation, the inventors of the data catalog, the category leader in data intelligence, and a high-growth company that recently raised a $110M Series D (placing the company squarely in unicorn territory), Aaron serves as Alation’s chief data & analytics officer (CDAO) and before that worked as a designer and researcher in Apple’s Siri advanced development group after graduating from Stanford with a master’s in symbolic systems.

We’ll speak to Aaron both as a product-oriented cofounder of a highly successful company and as a design-oriented product leader.  (We may get a little data-oriented decision-maker mixed in as well.)  Questions we’ll address include:

  • How do you synthesize data-led and design-led product management?
  • How did your psychology and software engineering background help you as a product leader?
  • How do you hire strong product leaders?
  • What was like for a product-oriented cofounder to hand-off the reins to an “outsider” (i.e., newly hired outside expert) product leader?

And, with a little luck, he’ll tell us what the heck symbolic systems is anyway.  See you there.  It should be a great episode.

Thomas will be joining us from a trip to Paris and says he won’t be asking too many questions, but I’m thinking this subject matter will inevitably draw him in.  On verra.

As always, the session will be recorded and made available on the SaaS Product Power Breakfast podcast.

# # #

(Disclaimer:  per my bio and FAQ, I’m both an angel investor in and director of Alation.)



Join Us for Tomorrow’s SaaS Product Power Breakfast with Andy MacMillan, CEO of UserTesting

We’re back this week with SaaS Product Power Breakfast and tomorrow’s guest is Andy MacMillan, CEO of UserTesting, and our topic is a framework for hiring product teams.

Andy started his career building web applications at EDS (so he presumably has lots of old white shirts somewhere in his closet), was VP of product marketing at content management vendor Stellent, was acquired into Oracle where he spent nearly 5 years in product management before serving as COO of Products at Salesforce (where we crossed trails), then CEO of marketing automation system Act-On, and now CEO at UserTesting, a human insight platform that helps companies get feedback on user experiences — so he’s definitely at the right place at the right time as the whole world starts to value design, user experience, and product-led growth strategies.

Net:  Andy’s got a great background, some real product chops, and can simultaneously give us both the Product and the CEO perspective on product issues.  Our topic is Andy’s framework for hiring product managers and product management teams.  My five key questions for this episode will be:

  • Why do I need a framework for hiring PM teams?
  • What is your framework for hiring PM teams?
  • What goes wrong in hiring PM teams?
  • What do you think of the PM as GM or mini-CEO concept?
  • When should an early-stage company start using such a hiring framework?

Thomas Otter, my co-host, and I look forward to seeing you at our chat with Andy tomorrow at 8am Pacific time.   The session will be recorded and released subsequently as an episode of the SaaS Product Power Breakfast Podcast.  See you there!