Sorting through customer feedback on your product is one of the main duties of a PM. Once your product is successful at scale, you will need to move beyond analyzing and responding to individual, discrete pieces of feedback, and trying to find patterns in that feedback: patterns that help you to discern users’ true needs (problems) and not their wants (solutions).
Unfortunately for you as a PM, customer feedback tends to come in the form of solutions. This isn’t to blame users, far from it: that’s the most tangible interface for them, so exhorting users (or even your technical sales team) to “bring problems, not solutions” is unlikely to solve the issue. Defining the problem is your job, not your customers or your SEs.
If you are currently my customer, and you see the above headline, you might be understandably alarmed. “I spend my valuable time meeting with this guy, and he brazenly admits that he ignores half of what I tell him. Why should I take his call again?” Let me be the first to assure you that this is not what I mean. For one thing, forgetting is not the same thing as ignoring. For another thing, I am actively listening to whatever you are telling me in the moment, and truly trying to analyze and synthesize it. I am also writing down the most substantial or insightful things you say, with pen and paper (because studies show that this physical act, rather than typing out notes, is the best way to retain information). But after that? I probably won’t remember exactly what you said, and I’m definitely not taking immediate action to prioritize anything. That’s because successful product management is about pattern-matching and sense making across a market, not individual customers, and any individual data point, even from our most important customers, might be an outlier. Which leads me to the practice that I call selective forgetting.
As a product leader, I have been using PR/FAQ in some form with my teams since about 2016. While I’m heartened that there is now a robust body of work describing the artifact, there is much less information about when and how to use it effectively in practice. That is what I intend to convey in this article.
There’s an overused and overloaded aphorism: words matter. Usually, this phrase is used to state that the selection of words has particular import (true). Yet to a product marketer, the definitions of those words and a company’s alignment around them is much more important. I don’t just mean the terms that you use to market your products (though I’ve had many vigorous arguments about “incident management” versus “incident response” that I’ll save for another day.) I mean the terms that you use inside your company to refer to the various parts of the kit you produce – your firm’s products and solutions. “Products” and “solutions”, though… what the heck do those terms mean, anyway?
I have now worked at several software companies who have either entered or considered entering the US federal government market. From a distance, this market appears very attractive. After all, the government spends about $90B per year on IT services, an addressable market size that dwarfs private sector IT spending of whole countries. Sometimes, individual solicitations like the (recently-cancelled) $10B JEDI initiative can do so as well.
However, many tech CEOs often make the mistake of assuming that the capabilities needed to service this market are similar to those that need to be developed for pure geographic expansion. Simply hire a sales specialist and you’re done, right? Wrong. Failure to anticipate and build critical product features that are mandatory for successful entry into this market, as well as understanding the peculiarities of the go-to-market capabilities necessary to do so, are the two biggest mistakes I’ve seen when tech CEOs seek to capture US federal government market share.
Below are the various product, marketing, sales, and channel requirements that CEOs and product managers must consider prior to entry so that you do not unintentionally turn that attractive top line into a negative bottom line.
I’m returning from my first conference/trade show in over a year. It’s wonderful to be able to hit the road again and meet customers face-to-face. After all, humans are social creatures, and while the last year has brought some interesting innovations in virtual events like wine tastings over Zoom, there really is no substitute for in-person conversation.
I’ve been “working the booth” now for nearly ten years, first as a solutions consultant, and then as a product manager and product marketer. Yet I’ve often noticed that booth conversations between vendor reps and customers can be extremely awkward. It doesn’t have to be this way. Here are some tips for you as an exhibitor to make the most of your customer interactions at the booth, all distilled from advice that I’ve given to sales and marketing teams over the years to prepare them to have effective conversations with customers on the show floor.
I often get asked for advice from product managers on the skills I consider critical for the role. Invariably, I find myself falling back on some practices that I learned as a journalism student nearly ten years ago. Although I never actually worked as a full-time reporter, I found that basic skills I learned in my very first “craft of journalism” courses are the ones that I now return to again and again as a product leader.
As such, here are the top five things I learned in journalism school that I think are important for emerging product leaders.
As I’ve explained in previous blog posts, I come to marketing not from a traditional marketing background, but from product development and engineering. When I first showed up in marketing, I was as baffled as many of you might be by all the different roles in B2B marketing, and wish I’d had a primer to explain what all the different roles in marketing are.
This is that document. I hope it’s a handy guide for folks outside of the marketing department who need to interact with it. It’s also helpful for startups to understand what kinds of marketing they need right now and what types of people they should be interviewing.
I constantly hear folks in the industry – specifically, product managers and engineers – confusing these two concepts. It’s a huge sliver in my eye. Just like how senior engineers twitch when we in marketing confuse “AI” and “ML”, this is just as bothersome and needs clarification.
Why does this even matter? Fundamentally, it matters because product managers and engineers often complain about marketing teams “marketing” the wrong thing. Usually what this means is that we are messaging the wrong thing. But if the product hasn’t been correctly positioned, then the messaging is going to be garbage. To solve this, I’m going to propose something potentially controversial here: product managers should own the positioning for their products. Product marketing should own the messaging.
The Dark language and coding platform launched this week, and I couldn’t be more excited. (I had half a mind to fly to St. Louis and see them launch in person at StrangeLoop.) For a while, I’ve been following what Paul Biggar (founder of CircleCI) and Ellen Chisa (a product leader whom I respect) have been building in Dark: a product to democratize software development and make it easier for everyone, particularly for folks who haven’t previously coded before. The frustration Paul expresses in his launch video –- about infrastructure and today’s delivery process getting in the way of delivering code – resonated deeply, particularly when I think about how we used to “deploy” in the early days of web software engineering (FTP-ing PHP files to production). Obviously, that was risky.
Today, however, in the name of risk reduction, we have complicated CI/CD pipelines, Kubernetes and rolling deploys, thousands of lines of AWS CloudFormation and Chaos Monkey to kill it all, and a million other extraneous guardrails that developers today need to learn just to get something into production. An end-to-end, low-friction developer experience such as what Dark is providing is certainly appealing, not just for new developers, but for old folks like me who would like to program again occasionally but find today’s frontend and backend stacks daunting.
In this post, I’d like to give my thoughts in just three
areas: what did Ellen and Paul and their team build? In what way could they
reasonably go to market? And also – to address some of the early criticism
about Dark, e.g. that it’s a closed ecosystem and not open source – does it
matter? Are there are other valid criticisms and how could they overcome them?