Category Archives: Product

Aligning Product and Go-To-Market with Metrics

Posted on August 11, 2025 | Leave a comment

My fellow Balderton Capital EIR Dan Teodosiu and I recently published an article on aligning product and go-to-market teams using metrics, specifically customer-value metrics. In this post, I’ll talk a bit about the article and how we came to write it, with the hope that I’ll pique your interest in reading it.

First, a bit on the authors. The definition of EIR (here meaning executive-in-residence) varies widely — as does the job itself. At Balderton, it means that we are on-staff resources available to help portfolio companies, on an opt-in basis, with the issues that founders and executives face in building a startup. Dan focuses on technology and engineering while I focus on sales and marketing. Dan’s founded two startups as well as having technology leadership roles at Criteo, Google, and Microsoft, and I’ve been CEO of two startups in addition to having served as CMO of three. That means we are both able to see the bigger picture in addition to our purely functional views. Not to be immodest, but I’d have trouble finding two better people to write an article on how to align product/technology and go-to-market. Heck, we even had the expected us vs. them disputes!

I write a lot about aligning sales and marketing (always remember the CRO is the #1 cause of death for the CMO), but I’ve not written before about aligning product and GTM. So this was a new, fun challenge that necessarily led to strategy, organizational behavior, and leadership. Yes, often, the CEO is the cause of the problem. I can’t tell you the number of times I’ve said: “You want to know whose fault this is? Grab a mirror!” But knowing that doesn’t necessarily help the particpants in a mess unless they know how to get out of it. Usually that starts by asking one simple question: why would anyone want to buy this again?

Does any of this sound familiar?

It’s a 2,750-word paper, which should take around 10 minutes to read, and I’d encourage everyone to check it out. We’ve got some nice, juicy historical examples in there where good companies, even great companies, lost the plot, forgot about customer value and wasted tons of resources as a result. Spare yourselves that pain. Or, if you’re in the thick of it already, step up and start asking the one big question: why would anyone want to buy this again?

Leave a comment

Posted in GTM, Product, Startups, Strategy

Your Competitive Analyst Should Not Be Named Harvey Balls

Posted on April 29, 2025 | 4 comments

Does your competitive analyst introduce themselves like this?

If so, you’ve got a problem. Not only because his younger brother Big is a controversial employee over in DOGE but, more importantly, because old Harvey is not defining his job correctly.

Many competitive analysts effectively define their job as product comparison. In short, to make Harvey Balls that compare products on different features, usually on a 1-5 scale using a circular ideogram. You know, something like this:

Harvey Balls are a useful communication tool. And you can use them not only for product features, but for non-functional product attributes (e.g., useability, performance) and even company attributes (e.g., support, viability).

I’ve got no problem with Harvey Balls in theory. In practice, however, such charts often quickly fall apart because they are entirely subjective and lack any rigorous foundation for the underlying 1-5 scoring. If you’re going to make comparisons using Harvey Balls, you must strive to maintain credibility by documenting and footnoting your scoring system, so a reader can verify the basis on which you’re assigning scores.

Otherwise, Harvey Balls are simply opinion thinly disguised as fact.

So what’s the real problem if your competitive analyst thinks his name is Harvey Balls?

Well, old Harvey has missed the point.

Marketing teams shouldn’t pay competitive analysts to make product comparisons. They should pay them to win deals. To quote one of my favorite movie scenes:

“I know how you feel. You don’t believe me, but I do know. I’m going to tell you something that I learned when I was your age. I’d prepared a case and old man White said to me, “How did you do?” And, uh, I said, “Did my best.” And he said, “You’re not paid to do your best. You’re paid to win.” And that’s what pays for this office … pays for the pro bono work that we do for the poor … pays for the type of law that you want to practice … pays for my whiskey … pays for your clothes … pays for the leisure we have to sit back and discuss philosophy as we’re doing tonight. We’re paid to win the case. You finished your marriage. You wanted to come back and practice the law. You wanted to come back to the world. Welcome back.”

To reiterate for Harvey’s sake: you’re not paid to make product comparisons, you’re paid to win.

What does that mean?

  • The goal of competitive is not to produce research for the sake of knowing, to support product management, or to tell sales so they can figure out how to use it.
  • The goal is to win deals, which does require in-depth product and competitive knowledge.
  • Competitive intelligence is an applied function — they must apply the knowledge gained from research into creating sales plays to win deals.

And note that the research need not be limited to product — it can and should include the competitions’ sales plays (i.e., what they plan to do to us and how to defeat it). And it can and should include company research (e.g., executive biographies to anticipate strategies).

Let’s elucidate this via an example. Let’s say your competitor sells a data analysis product that demos really well. Yours looks like a clunker by comparison, especially in quick reactions to end-user demos. Let’s also say that competitor has poor governance, administration, and security controls. Yours look great by comparison. Furthermore, let’s say you know your competitor is going to run a sales play called “the end run,” where they want to leverage the end-users’ love for the product to effectively ram it down the throat of a resistant central data team.

Let’s contrast three approaches:

  • Product comparison: create Harvey Balls that show the relative strengths and weaknesses in useability vs. administration.
  • Holistic research: include warning your sales team to expect the end-run as the competition’s standard sales play.
  • Win-deals: use all that information to create a sales play called “the Heisman” where you leverage the central data team to anticipate and block the end users to avoid purchasing a system with insufficient security and administration. That includes reframing user sentiment from a selection criteria to a hygiene criteria (i.e., it needs to be “good enough”).

Don’t get me wrong. Good product knowledge is critical. But it’s simply the foundation of the win-deals approach which also factors in company- and sales-level intelligence and then applies everything to creating sales plays that win deals.

If you had to put a metric on all this, it would be win rate. Competitive’s job is not to produce reports. It’s to increase head-to-head win rate vs. chosen competitors. If they sign up for that, then the rest should follow.

4 Comments

Posted in Competition, Marketing, Positioning, Product, Sales, Startups

Tagged

Slides from Five Ways to Get Product and Marketing Working Together

Posted on November 12, 2023 | 2 comments

Last week in London, fellow Balderton EIR David Vismans and I held a joint meeting to discuss the working relationship (or moreover, the lack thereof) between product and marketing organizations.

David is a career product leader, who worked for over 8 years leading product at Booking.com.  I am a former CEO and CMO who still considers himself to have 100% marketing DNA.  So, we were both well able to represent our functions.  Additionally, because I am a B2B person and David is mostly a B2C person that added another dimension of difference for us to explore.

In the session, which was held as an interactive workshop for Balderton portfolio companies, we described the problem, shared a few war stories as examples, and then discussed the five things companies can do to get their product and marketing teams working better together.

  • Foster a culture of collaboration and respect.  This begins at the top.  Do not apply the old adage that “good fences make good neighbors,” and wall the teams off from each other.  (David had a great story where security literally kept them from visiting each other’s floors.)  Instead, do what we say in point 3, below.
  • Drive together for both PMF and PCF (product-channel fit), an idea that David brought.  This means the teams should work together to build and sell a product that solves a problem for a person (i.e., my definition of PMF) in conjunction with finding a way to economically reach that person (i.e., PCF).  David provided a few examples where he believes you could get PMF fairly easily (e.g., a hotel booking site for people traveling with dogs or who need chargers for electric cars), but have a hard time economically finding customers due to the need to compete with large vendors for contested search terms in paid channels.
  • Build a high-level interaction model.  That sounds fancy but it just means make a one-page table with three rows:  lifecycle phase, product responsibilities, and marketing responsibilities.  Taking the time to make this – typically done in a few meetings of a working group — sets expectations on both sides.  It avoids the common problem of ten people bringing expectations from ten different prior employers, which usually results in everyone being disappointed all the time.
  • Adapt your model with stage and scale.  We both like the Ansoff matrix and David uses it as a framework to adapt the product/marketing collaboration model.  He argues that the more you’re in “keep on keeping on” mode (box 1), the more is known, and the higher the fence between product and marketing can be.  But in boxes 2 and 3 you are working with one unknown dimension and that requires more collaboration.  Box 4, where both product and market unknown, is basically like starting a new company and requires maximum collaboration. (I largely, but not entirely, agree. My primary argument being that in Box 1, marketing will be more focused on features to differentiate and win deals than product usually is.)
  • When it comes time for your second album, don’t forget your roots.  I think as companies grow they forget how they innovated in the past, they forget the processes they used in the early days and end up, for example, localizing a new product into 10 languages on its initial release – because that’s what we do now with all products.   

Thanks to everyone who attended the session.  I’ve embedded the slides below.  They are available in PDF here (so the links on the resources page work).  Balderton is producing a summary of the event as well, which I’ll link to once it’s up.

2 Comments

Posted in Management, Marketing, Product

Tagged ,

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