“We aren’t updating our customers enough” is a common realization for companies of all sizes.
Instead of pointing fingers, smart, experienced, and action biased teams will start with the most important question: who’s responsible for customer updates?
If you can identify who’s accountable for getting customer updates out the door the actual steps of solving the problem get a lot easier.
—
To understand who’s responsible for customer updates, we first need to be clear on what we mean. The question is not ”who’s responsible for any step in the process,” because we’re looking for who owns the entire process. It’s also not “who’s responsible for doing noteworthy things,” because that’s everyone’s job.
To fully expand this simple question into what we actually mean, it’s something like:
“Who is responsible for gathering information on changes are happening in our product and throughout the company, batching those changes into logical groups and writing those groups of changes in a customer friendly tone, fact checking that the combined information is true once combined, and finally pushing that update to all the places customers might look, including the blog, email newsletter(s), Twitter, LinkedIn, in app banners, and to relevant people in the sales pipeline?”
Phew!
Spelling the question out in full terms makes it a bit more clear why we’re not always on top of customer updates.
In this post I’ll cover:
- The reasons why you’re not writing enough customer updates,
- Who could possibly own this responsibility, and
- My recommendation of how to handle this on small and medium size teams.
Why you aren’t writing enough updates.
It’s worth a disclaimer: I wrote ~90 pages on the topic of customer updates, which does include a pitch on why customer updates are important, and why you may have trouble keeping to a frequent, consistent publishing schedule.
If you’re reading this article and think “this is great, but I wish it was about 800 times longer” I highly recommend flipping over to that post for a quick skim.
To summarize from that article, the common reasons why companies aren’t updating their customers enough are:
- No process to gather the needed information, combine it, fact check, and publish.
- Teams are time limited from building the product, they don’t have time to also write updates.
- Teams don’t have a single person who’s accountable for getting updates published.
No Process
Not having a process is the main indicator that there’s not a single owner responsible for publishing customer updates.
Building a company (especially a startup) is one big coordination issue. Customer updates are a uniquely challenging problem because every team within your company has a hand in the process. No individual person has all the knowledge and background to cover the entire scope of every update.
(And if there is a single person who can handle customer updates from beginning to end, I’ll bet they’d identify problem number two, no time, as a big issue.)
It requires a village to produce great updates.
You need the technical skill to understand how changes and improvements actually work, customer knowledge to know what sort of benefits people rely on your product to provide, you need to be able to write and communicate clearly and with brand voice, and you need to be a distribution and repetition machine to get the updates to where they need to go.
Writing great updates does not happen by accident. It takes an organized, company-wide effort to make it happen.
No Time
The meme is that product teams spend all their time building and no time marketing. Not sending customer updates is the manifestation of this problem, and the front line excuse is “we don’t have time to do this.”
Without trying to sound like a business coach we need to flip our perception on customer updates.
Updates are the reason why we make the changes (or more accurately, communicating with our customers that we’ve fixed bugs and improved the product,) it’s not possible for updates to get in the way of making improvements.
Updates are the reason for the season.
Consider this: if you make 100 improvements and none of your customers or prospects knew about these changes, is that better than 10 improvements that all of your customers know about?
Now, food for thought, how close is your business to the “100 improvements that no one knows about” scenario?
Great updates do take time.
But it’s worth it.
With the right tools, process, and people, you can get way better results than you expect with much less time than you think.
No Accountability
Accountability drives results in a company. To illustrate, let me share a story of startups' past.
My first real company was a password manager.
I’d ask everyone I met “how happy are you with how you store and give access to passwords?” and effectively 100% of people would say “well Brian, not that happy.”
This included people who already had a solution in place too!
You must be thinking “wow, you elegantly solved a problem that every tech business in the world had, you must have made billions!”
Unfortunately while most companies have “better way to share passwords” on their todo list it’s perpetually item number 25, under items like “get enough new customers to pay our bills”, “prevent important employees from quitting”, and “fix bug for our biggest customer so they don’t churn.”
I share this to illustrate the point from the outside looking in: every business has dozens of things happening at once.
If there’s not a single person on the team who has a goal around publishing more updates it’s just not going to happen. Reality has shown that a million other high priority items are going to come up.
Urgent will beat important every time unless you’ve already made room for Important.
Sending frequent customer updates has a persistent, long term impact, but without a clear goal (and guidance) accomplishing this goal is too big, too complicated, and too important to leave to chance and whatever time is left over.
Just like with everything else: If you don’t set a goal, don’t plan on it happening.
If you plan on it happening, you need a happener.
Who could own customer updates?
Because the whole company is responsible for doing noteworthy things, it’s the case that literally anyone within the company could hold the responsibility for updating customers.
Yet another reason why this problem is unsolved at so many companies.
I’ll run through each department and provide you with the pros and cons of the update responsibility living there. The organization of each of these departments is too varied for me to make a blanket statement as to which job title should own updates, but, if you tweet your org chart at me I’ll tell you what I think.
Product Marketing
Do you already have a product marketing team? If so, congrats, you’re done! Customer updates are at the absolute core of product marketing, so that team should already have updates totally covered.
However if you’re reading this, that probably means one of two things:
- You don’t have a product marketing team, or
- They aren’t doing updates 🙃.
If you don’t have a product marketing team, that’s not too surprising. Doing a bit of research I found a wide range of opinions on when to start hiring in a formal “product marketing” team, and moreover what product marketing even is.
This thread of mostly product marketers all said “hire them (me) at the seed stage! Pre seed! First marketing hire!” And while I agree with them, my experience is that the response further down the page is the most accurate:
“The two startups I joined as the first PMM were ~100 employees and both were for technical software products.” - Adam Kerin, Truework SVP of Marketing.
This article by Jordan Cohen looks at the question of “when” another way, he says:
“So, with that in mind, product marketing is always the LAST hire I make when building out a marketing team.”
Want to know what he meant by “with that in mind?” You’ll have to read the post.
(reading rainbow gif)
The final point that’s best made in this post: “It’s very likely that someone in your organisation is already doing product marketing”
Keep this in mind as we go through the other departments. “Product marketer” is both a noun and a verb, so even if they aren’t the title of “product marketer”, they may be product marketing as a part of making the company the best it can be.
Marketing
The next logical thought is “Well, if we don’t have product marketing… what about just… marketing?”
All things considered, I tend to agree. The marketing team has a number of benefits that are hard to install into other teams.
The marketing team understands your ideal customer profile, is used to talking about benefits, and is used to having a large percent of their work being customer facing. It can be a challenge to teach great writing, and it's also hard teaching people to be benefits focused, so having a team with these characteristics built in is a huge benefit.
The marketing team also understands publishing on a schedule, and distribution. Two of the biggest mistakes companies make with updates are not publishing them frequently enough, and not publishing them everywhere.
Marketing teams do both of these by default, making them the presumptive champions of customer updates.
To be balanced there may be a few downsides to having the marketing team own updates. Please forgive me for potentially engaging in stereotype.
First, marketers don’t have a reputation for being deeply technical. This isn’t always a problem, and is often a benefit by not sending needlessly complex updates to customers.
However, not being technical means that the complexity of the update needs to be pre-processed, meaning that a marketer might not be able to work from the “raw data” of commit messages and turn them into benefits focused copy they’d like to publish.
Second, the marketing team is often measured on metrics like top of funnel traffic, leads, and social mentions. Having great customer updates benefits EVERYONE at the company, but there are other activities that could have a more immediate short term effect on all of these metrics.
This is why “number of customer updates” needs to be its own goal, and the company needs to appreciate that this effort makes everyone’s job easier.
(If you don’t buy into that I have a 90+ page argument to back it up.)
Last, and probably least, the marketing team is busy.
Constantly pulled between long term projects strategic planning, making messaging matrixes, and asking if the website needs to be remade, and short term projects like improving SEO on a specific winning blog post, increasing top of funnel traffic with a sponsorship, or asking if the website needs to be remade.
I say “and probably least” because this is true of every team, I’ve never met a business that’s said “we have so much extra time on our hands, we don’t know what to do with it!”
Product Management
If not Product Marketing, and not Marketing, then how about Product Management?
Product Management vs Product Marketing is another frequent conversation (and sometimes argument.) From my perspective while Product Marketers are responsible for bringing the product to market, product managers are responsible for the creation of the product.
This includes market research, talking to customers, building a product roadmap, turning that roadmap in to backlog for the developers, and then testing and getting those features live. Product managers are also generally involved in the post launch process of getting feedback from customers and making the determination on which feedback to implement.
Given this unique positioning, Product Managers are a great choice to own the customer update process.
They know what’s being worked on, what’s coming up, what’s ready to ship, what customers are currently using and what they’re asking for in the future.
Since Product Managers have vision through the development process they can begin writing customer updates as the feature takes shape, so that the launch and the update can go live at the same time.
The main problem with electing a Product Manager to own customer updates is that Product Managers are quite rare, especially at early stage companies, and especially lately.
This could be a function of my particular bubble, but I’ve noticed the jack of all trades Product Manager role going away in favor of more domain specialist… most of the time more developers.
(Or, unfortunately with the recent trend in tech layoffs, PMs are getting replaced by empty seats.)
If you do have a Product Manager in charge of the product that you want more updates for, the only other reason why they might not be the perfect fit would be due to the variance in the role.
Some Product Managers may not speak to prospects, some might not be in touch with the sales team at all, some may not interact with marketing, some may not interact with support tickets or angry customers, and some might only talk to a subset of current customers.
Depending on the company’s some Product Managers may not talk to customers at all.
The Product Manager role is high variance, with a number of extremely strong opinions surrounding it. Undoubtedly there’s someone reading the paragraph above a furiously leaving the comment “If your product manger doesn’t talk to prospects they aren’t a real product manager!!!!!”
The reality is that the role needs to conform to the business, this leads to variance and could cause the Product Manager to be a worse customer updates owner.
Support
Support is the team all ownerless tasks find their way to.
Whenever a project or task comes up that no other team default owns, it goes to support.
Need to write up documentation? Support team.
Need reviews? Support team.
Need to update billing? Support team.
Need to orchestrate a multi year deal? Support team.
Need to build a dashboard to report on sales numbers? Believe it or not: support team.
However in the case of customer updates there is a bit of an argument to be made for the support team. Support has direct, 1:1 relationships with customers. They see real, every day usage of the product to know what’s happening in the wild.
The support team sees the bugs and rough edges too. One of the things that prevents teams from sharing updates is the thought “well, this is just a bug fix, us talking about it only shows that it was broken in the first place.”
I reject that premise and most support teams are with me: if a painful bug is fixed they will shout that from the rooftops, which is exactly the right thing to do.
There’s also a few challenges to putting support in charge of updates.
Partially because support is the default termination point of all unassigned tasks, the support team is the most likely team to experience time crunches and emergencies.
While they might have free time one week to help get updates posted, the next week they might be totally at capacity, and as such aren’t a great fit for having maximum consistency.
It’s also possible for the support team to be cursed with knowledge–it’s not always easy to be excited about one issue being fixed when you know there are ten more customers waiting for another bug to be fixed.
And the support team, like most others, doesn’t have the full picture of how a new feature went from customer insight to product and might not be able to capture and summarize that process in an update.
Engineering
Engineering is a popular choice for writing customer updates, or at least delivering an outline to a dedicated writer on the team.
It seems like companies can’t help but try and pull software engineers out of their core responsibility of delivering function code, including:
- Spending a week a month in support,
- Joining sales calls,
- Writing a blog post on a regular schedule,
- Scoping out potential new features with stakeholders, and
- Attending meetings on why the dev team is missing deadlines.
I suspect everyone comes to the same conclusion when they ask the development team to write the updates: they know exactly what changes have been made.
Generally the hardest part to crafting a great update is translating the research, design, and development work into a short, focused, yet informative story. You cast your customers in the lead heroic role and explain how, through their hard work, they’ve come out the other side stronger.
The developers know the exact changes made to the product to introduce these improvements to customers, they also probably have a good insight as to why the feature was even built in the first place, and they know what actually made it into the final product.
So, shouldn’t they be the best choice to write updates?
Well… so here’s the thing.
The first problem is my (sort of) joke in the bullets above. Of everyone likely to say “I can either do everything I need to do, or I can spend half of my time writing updates,” developers are most likely to actually be right.
Again, when’s the last time you spoke with a company that’s like yeah, we just have way too many developer hours, our velocity is too high.
In my experience the engineering team provides the most leverage shipping high value code, and the company structure should organize around that. Shipping is a skill that should be honed and supported, not derailed.
Next, developers generally aren’t the best writers. One suggestion, that I sort of agree with, is that developers should write great commit messages so that especially other developers, but even other people at the company can read these commit messages to know exactly what’s happening.
In my experience getting developers to do this is a bit like pulling teeth, and requires constant, constant, constant reminders to write great commit messages. Most of the time it looks like this:
Writing is its own skill distinct from software development.
Finally, developers see a very specific slice of the business. Generally developers interact more with internal team members than customers or prospects, so a lot of their information is second hand.
Great updates take into consideration not just the actual mechanism of the product but the benefit received by the customer. This is why most developers are shocked when they learn the cost of seats for a sales enablement tool.
For example:
Github, the tool where most company store all the code and workflows needed to run their product is either free, or, $4/user/month.
Chili Piper, a tool that makes it a bit easier to book sales meetings, starts at $23/user/month, and goes up from there.
To most developers' shock, companies are willing to pay it!
Not existing in the world of “benefits” makes it hard for most developers to write $23/user/month customer updates.
Success
All of the arguments for and against support also apply to success, with a few caveats.
First, success can tend to be a bit more regulated in the amount of work (eg, every week you need to check in with X companies,) but are still susceptible to emergencies. If they check in with your number one customer and they say they might churn, that instantly becomes the top priority.
Success usually has great customer relationships, maybe even beyond the scope of what support has.
The success team also generally has an upsell goal, so being in charge of updates ensures that they know of all the new features and improvements, arming them to go into renewal calls with all the info that they need.
Beyond that, the question of the success team owning customer updates is the exact same analysis as the support team owning it.
Sales
Hoo boy.
To be honest I’ve never seen a company do this, and to the best of my knowledge no one has even suggested that the sales team be responsible for customer updates.
However, in the interest of full exploration, I decided to include them in the list.
The sales team has a number of strengths in owning customer updates, including:
- An extreme benefits focused mindset,
- A clear picture of current and future best fits customers,
- An understanding of the market and competitors,
- Strong communication skills, especially written communication,
- Understanding of distribution and generally “getting the word out.”
These are all super unique, strong skills that no other team brings.
However, there are a few challenges.
Just like the point I made about wanting your developers writing code, you also want your sales team selling. If they’re not ringing the bell, hitting the gong, or engaging in whatever brand of celebratory percussion you’ve decided on, they’re not providing the results you need to your company.
Unlike developers, the sales team likely has the least insight into the product development process. Any hope that the sales team can paint a word picture of how a feature came to be is pretty misguided.
Finally, I’d personally be a bit concerned of let’s say “over emphasizing” some of the finer points of what’s going on. Perhaps an update on a new admin panel may be communicated as “The best, greatest admin tool ever conceived by mankind,” or something along those lines. There’s definitely a fine line between benefits focused language and… well just going crazy town on it.
I don’t suspect this article will convince anyone to put their sales team in charge of customer updates, and I don’t think that’s even my intention, but as food for thought I wanted to put this idea out into the world.
Leadership
I’ve generally seen executive level, CXO style updates either at very early stage companies, for BIG strategically relevant updates, or for recap (like “2023 year in review” style updates.)
For very small companies I might recommend this option on the basis of… there’s no one else :).
Big strategy updates also make sense to come from leadership, and a yearly recap also makes sense to come from the leadership team.
However, unless you’re the only one to do it, I haven’t seen in practice the ability for leadership teams to do anything more than a monthly shareholder update… and frankly most fail at doing that. Having the time, focus, and context to achieve weekly customer updates means not being able to do a whole lot more out of that scope, so almost instantly the leadership team is disqualified from owning customer updates.
However, I do think there’s a lot the leadership team can do to help move the needle. Take this tweet for example:
What should we do Brian?
Am I allowed to say “it depends?”
The answer unfortunately changes on a number of factors, including the size of your company, how complicated / technical your product is, and who in your company is already in touch with customers.
I’ll provide some options and you can see which is the best fit for your team.
First off, the “easy” way to solve this problem is to simply buy a product to do this work for you. I actually have a recommendation of the product you could use. In fact, this blog is the blog of the product.
Without too much of a pitch, Changebot will effectively be your product marketing team for you if you don’t have one, or supercharge your existing team by picking up all the work they don’t really want to do (namely, turning code changes into great customer’s updates.)
Click here to create your account and we’ll have a bunch of updates your way ASAP.
The second option is a bit of an investment: consider spinning up a product marketing team. Per the list of departments that could own this, product marketing is by far the best choice. Customer updates are the life blood of any great product marketing team.
It’s enough work that you’ll find that even for small teams, a full time product marketer will have their hands full, and you should see results relatively quickly.
Option three is to elect a single “owner” for the more customer updates goal, and then share the task across all the teams.
Your owner is the one who’s responsible for reporting on and hitting the goal. If you do team meetings to review goal progress this owner speaks to the number and talks about ways to improve that speed. This goal owner could be literally anyone, from a marketing lead, COO, support lead, etc.
That goal owner probably can’t do everything, so they’d need help from the team to put everything together:
Sales and support need to provide the pulse on what current and potential customers are talking about.
Engineering speaks to the roadmap, what’s currently in progress, and then when things are being shipped. It’s important to know what’s in progress because the updates should be in the works as the work is being done, so the update can go live when the feature / bug fix goes live.
This person will probably also need writing help, which could come from anywhere, but probably comes from marketing.
Finally the goal owner will need help distributing the update, marketing can help get the update out on the blog, in app messaging, and social, support and success can get the message out to existing customers, and sales can help spread the word into the pipeline.
With everyone’s part time help you can hit your goal without getting massively distracted from other work.
And that’s… who’s responsible for customer updates.
