Category Archives: Product

PLG Resources and Wrap-Up

Posted on August 18, 2023 | 1 comment

I put blog ideas into a to-write folder which contains more than 300 files full of brain dumps, outlines, and rants, all in various forms of disrepair. It’s my process. In that folder, there are 21 posts with PLG (product-led growth) in the draft copy and 5 with PLG in the title. It’s a topic I’ve always been interested in, but two things have prevented me from attempting a seminal post on PLG.

  • There is so much great work out there already. Every time I start to write, I hear stand on the shoulders of giants ring through my head followed by, “Dave, stop. Stop, will you? Stop Dave.”
  • I still consider myself more student than master. I grew up in enterprise. I have experience with market-seeding strategies and open source. I work with some velocity SaaS businesses. I’ve debated founders and boards on how enterprise companies should think about a PLG motion. But I’ve never run a PLG company and I’ve never worked in-depth on a PLG process.

Thus the drafts remain unfinished. But after having learned a fair bit, met many interesting people, located some great resources, and developed some strong opinions, I didn’t want to just drop everything. So I decided to write this summary report to provide links to PLG resources and share a few PLG thoughts before moving on.

PLG Resources

Thoughts and Opinions

Here are some opinions forged by my PLG research and conversations.

  • Don’t do PLG just because a board member wants you to. Try introducing a PLG product or motion if and only if you (as CEO) want to. While we are past peak-hype on PLG, there can still be a lot of pressure to try it because everyone else is doing it. Resist.
  • Try PLG if you think it can help your business. There is a lot to learn from PLG companies so I don’t recommend resistance for its own sake. But, if you weren’t born PLG, the odds your enterprise product will be ready overnight for a PLG motion are low, so keep expectations in check. Here’s a great post to help you get started on the journey. Alternatively, you could run PLG motion on a teaser product to pull people into your overall offering (e.g., Clearbit’s de-anonymization can lead to a later purchase of enrichment, Moz’s online presence can lead to a later purchase of its SEO).
  • I like growth teams. In general, I like silo-busting where you take groups of experts in different functions and aim them at a business goal. ABM does this, uniting sales, marketing, and SDRs in the quest to crack target accounts. Pods do this, uniting different sales and marketing functions, typically within a geography or vertical. Growth teams do this, uniting product managers, designers, marketers, sellers, and analytics team members on maximizing PLG conversion rates. They’re a good idea.
  • The product doesn’t sell itself. Knowing how expensive sales and marketing people can be — with S&M expenses typically running at twice R&D in a typical software company — I think for some people the PLG dream was to elminate S&M with a product that sold itself. That didn’t happen. In PLG, most of the time, the product helps sell itself. That’s certainly a lot better than not helping (I’ve seen that too), but we’ll still need those pesky sellers and marketers after all. See the McKinsey paper.
  • PLG ain’t cheaper. While a few PLG companies end up ahead on the S&M vs. R&D expense trade-off, most end up spending more on both. See the Tunguz post or the McKinsey paper. Don’t do PLG to save money. Do it because you think you’ll have a better product, grow faster, take market share, and build leadership. PLG is not a cost-cutting strategy.
  • PLG still needs marketing. How do you think we get people to do all those trials anyway? Yes, you may have a viral product or a strong community (word of mouth), but you’ll still also rely on marketing to drive people to your trial via SEO, SEM, and making TRY-IT the primary call-to-action on your website. (This always makes me think of Boston with the anaphoric “listen to the record” on the back cover of their debut album.)
  • If you’re starting a new company, try to be born PLG. For example, were I to start a new EPM company, I’d try hard to build a PLG motion in from day one. That’s not particularly easy in a space with separate buyers and end-users (where end-users need to be connected to the corporate system), but I’d sure try. You’ll likely end up with a better product as a result. Or a teaser product linked to a core one.
  • PLG is another pipeline source. Traditionally we’ve had four pipeline sources (marketing/inbound, partners, sales/outbound, SDR/outbound). When do you PLG, you’re not only adding any direct revenue, you’re also adding a pipeline source (with its own vernacular, e.g., PQLs) much as ABM adds a pipeline source (with its own vernacular, e.g., MQAs).

1 Comment

Posted in Growth, Product, SaaS

Tagged ,

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

Posted on June 3, 2022 | 2 comments

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.

2 Comments

Posted in Communications, Product, Startups

The Product Superpowers That Few Flex: Join Special Guest Brett Queener on the SaaS Product Power Breakfast

Posted on May 1, 2021 | Leave a comment

Please join Thomas Otter and me this Thursday, May 6th at 8:00 am Pacific for the SaaS Product Power Breakfast on Clubhouse with special guest Brett Queener, partner at Bonfire Ventures, former President & COO at SmartRecruiters, product-line general manager at both Salesforce.com and Siebel, and member of the board of directors at Aforza, Atrium, ClearedIn, Cube, Invoca, Lytics, Pendo, SmartRecruiters, and Spekit.

Our topic will be The Product Superpowers That Few Flex:  Intention and Conviction.

We aim to cover the following questions:

  • What was it like running product for Marc Benioff?  (Or, for that matter, Tom Siebel?)
  • What do you look for when evaluating products for seed-stage investments?
  • Cadence:  daily / monthly / quarterly releases — which is best and why?
  • What in your mind is a world-class product manager?
  • How is the role of product decisioning changing?
  • In a product-led growth (PLG) world, does product own growth?
  • What’s a feature and not a company?

With Brett, the action is sure to be cutting, frank, insightful, fast-paced — and funny.  Content warning:  when Brett and I get together, the errant F-bomb has been known to drop, so this may be our first R-rated episode.

Bring a friend — it should be a crackling session.  If you need a Clubhouse invite, ask.  And for those who can’t make it live, the SaaS Product Power Breakfast is now available in podcast form, so it will be recorded and you can always listen to it later.

See you there!

Leave a comment

Posted in Product, SaaS

What is a Minimum Viable Product, Anyway? My Favorite MVP Analogy.

Posted on March 6, 2021 | 12 comments

The concept of minimum viable product (MVP) has been popularized in the past decade thanks to the success of the wonderful book, The Lean Startup.  It’s thrown around so casually, and you hear it so often, that sometimes you wonder how — or even if — people define it.

In this post, I’ll describe how I think about MVPs, first using one real-life example and then using my favorite MVP analogy.

The concept of a minimum viable product is simple:

  • Every startup is basically a hypothesis (e.g., we think people will buy an X).
  • Instead of doing a big build-up during a lengthy stealth phase concluding in a triumphant (if often ill-fated) product unveiling, let’s build and ship something basic quickly — and start iterating.
  • By taking this lean approach we can test our hypothesis, learn, and iterate more quickly — and avoid tons of work and waste in the process.

The trick is, of course, those two pesky words, minimum and viable.  In my worldview:

  • Minimum means the least you can do to test your hypothesis.
  • Viable means the product actually does the thing it’s supposed to do, even in some very basic way.

I’ll use an old, but concrete, example of an MVP from my career at Business Objects.  It’s the late 1990s.  The Internet is transforming computing.  We sell a high-functionality query & reporting tool, capable of everything from ad hoc query to complex, highly-formatted reports to interactive multidimensional analysis.  That tool is a client/server Windows application and we need to figure out our web strategy.  We are highly constrained technologically, because it’s still the early days of the web browser (e.g., browsers had no print functionality) [1].

After much controversy, John Ball and the WebIntelligence team agreed on (what we’d now call) the following MVP:

  • A catalog of reports that users can open/browse
  • End-user ad hoc query
  • Production of very basic tabular reports
  • Semi-compatibility with our existing product [2]

But it would work in a browser without any plug-ins, web native.  No multi-block reports.  No pages.  No printing.  No interactive analysis.  No multidimensional analysis.  No charting.  No cross-tabs.  No headers, no footers.  Effectively, the world’s most basic reporting tool — but it let users run an ad hoc query over the web and produce a simple report.  That was the MVP.  That was the hypothesis — that people would want to buy that and evolve with us over time.

Because of that tightly focused MVP we were able to build the product quickly, position it clearly within the product line [3], and eventually use it as the basis for an entirely new line of business [4].

Now, let’s do the analogy.  Pretend for a moment we’re in a world where there are no four-wheel drive cars.  We have invented the four-wheel drive car.  We imagine numerous use-cases [5] and a big total available market (TAM).

What should be our MVP?  Meet the 1947 Jeep Willys [6] [7].

No roof.  No back seat.  In some cases, no windscreen.  No doors.  No air conditioning.  No entertainment system.  No navigation.  No cup holders.  No leather.  No cruise control.  No rearview camera.  No ABS.  No seatbelts.  No airbags.

No <all that shit that too many product managers say are requirements because they don’t understand what MVP means>.

Just the core:  a seat, a steering wheel, an engine, a transmission, a clutch, and four traction tires.

  • Is it missing all kinds of functionality?  Yes
  • In this case, would it even be legal to sell?  No.  Well, maybe off-road, but we’re in analogy-mode here.
  • But can it get you across a muddy field or down a muddy road?  YES.

And that’s the point.  It’s minimum because it’s missing all kinds of things we can easily imagine people wanting, later.  It’s viable because it does the one thing that no other car does.  So if you need to cross a muddy field or go down a muddy road, you’ll buy one.

As Steve Blank says:  “You’re selling the vision and delivering the minimum feature set to visionaries, not everyone” [8]. 

So next time you think someone is focused on jamming common but non-core attributes into an MVP, tell them they’re counting cupholders in a Willys and point them here.

# # #

Notes

[1] And printing is a pretty core requirement for a reporting application!

[2] This was key.  WebIntelligence could not even open a BusinessObjects report.  Instead, we opted for compatibility one layer deeper, at the semantic layer (that defined data objects and security) not the reporting layer.

[3] If you want all that power, use BusinessObjects.  If you want web native, use WebIntelligence.  And you can share semantic layer definitions and security.

[4] BI extranets.

[5] From military off-road applications to emergency off-road and/or slippery conditions to sand recreational to family vehicles on snow and many  more.

[6] Which in some ways literally was the MVP for Jeeps.

[7] Popularized by the Grateful Dead in Sugar Magnolia (“… jump like a Willys in four-wheel drive.”)

[8] Where I’ll define visionary as someone who has the problem we’re trying to solve and willing to use a new technology to solve it.  It’s a little easier to think of someone trying a next-generation database system as a “technology visionary” than the Army buying a Jeep, but it’s the same characteristic.  They need a currently unsolvable problem solved, and are willing to try unconventional solutions to do it.

12 Comments

Posted in Grateful Dead, Marketing, Product, Startups

Don’t Let Product Management Turn Into “The Roadmap Guys”

Posted on September 30, 2017 | 3 comments

At many enterprise software companies product management (PM) ends up defaulting into a role that I can’t stand:  The Roadmap Guys*.

Like a restaurant with one item on the menu, the company defaults into ordering one thing from product management:  a roadmap pitch.

  • “The VP of PM is in Boston and Providence this week, can she visit some customers and do a few roadmap presentations?”
  • “Hey, there’s a local user group in NY this week; can PM do a roadmap pitch?”
  • “There’s a big customer in the executive briefing center today; can the PM do a roadmap?”
  • “As part of our sales cycle with prospect X, we’d love to get PM in to discuss the roadmap.”
  • “We’ve got a SAS day with Gartner next week, can PM come in a present the roadmap?”

You hear it all the time.  And I hate it.  Why?

From a sales perspective, roadmap presentations are the anti-sales pitch:  a well organized presentation of all the things your products don’t do.  Great, let’s spend lots of time talking about that.

From a competitive perspective, you’re broadcasting your plans.  If you’re presenting roadmap to every prospect who comes through the briefing center and at every local user group meeting, your competition is going to learn your roadmap, and fast.  Then they can copy it and/or blunt it.

But what irks me the most is what happens from a product management perspective:  you turn PM into “the talking guys” instead of “the listening guys.”  Given enough time, PM starts to view itself as the folks who show up and pitch roadmaps.

But that’s not their job.

PM should be the listening folks, not the talking folks.  Just like sales, PM should remember the adage:  we have two ears and one mouth; use them in proportion.

Wouldn’t the world be a better place if we changed the five previous bullets as follows?

  • “The VP of PM is in Boston and Providence this week, can she visit some customers and observe how people actually use the product?”
  • “Hey, there’s a local user group in NY this week; can PM break off a small focus group to ask customers about how they use the product?”
  • “There’s a big customer in the executive briefing center today; can PM come in and interview them about their impressions on evaluating the product?”
  • “As part of our sales cycle with prospect X, we’d love to get PM in to discuss what specifically they are trying to accomplish and how the product can do that?”
  • “We’ve got a SAS day with Gartner next week, can PM come in and hear from Gartner about what they’re seeing in the market and in their interactions with customers?”

So every time you hear the word “roadmap” in the same sentence as “product management,” stop, pause, and think of a better way to use the PM team.  Sure, there are certainly times when a roadmap presentation is in order.  But don’t default to it.  Keep your PM team listening instead of talking.

# # #

* I’m using “guys” here in a gender-neutral sense like “folks.”

3 Comments

Posted in Management, Marketing, Product, Startups, Uncategorized, VC