As a product marketer, when you write content for your website, don’t you want your readers to say “hell, yeah” instead of closing their tabs and moving on? Don’t you want them to feel like you read their mind, sign up and try your product?
How do you write copy that truly moves your readers to take action?
Often, people will tell you that you need to get into the shoes of the person who landed on your site. They’ll tell you you need to ’empathize’ with them. They’ll say you’ll need to talk about the problem statement so that your readers just ‘get it’.
But for someone who is getting started with copywriting, ‘getting into the shoes’ or ’empathizing with visitors’ barely means anything. These concepts are alien to folks who are just getting started.
As copywriters, we often end up opening Google Docs, writing sentences, looking at them over and over again. And after a couple of days of self-loathing, we finally push the work we’re often not happy about, on our sites. We’ve all done this before - I’m guilty of it too.
Continue reading “Getting readers to say “hell yeah” when they land on your web page”
But what comes out of this process is forgettable copy. You know what it leads to – poor signups, poor conversions, and whatnot.
In this post, I want to talk about how I got over this habit and learned to write better copy. I want to unpack how you can actually go about empathizing with your users so that empathizing becomes more than just a jargon everyone throws around at you. This is certainly not rocket science - I’ve done this only by naturally studying what the best web pages I’ve seen have done in the past with words.
Imagine I’m building a product that any home baker across the world can use. I can write this headline and description introducing it on the homepage of Goodcookie, my product:
Everywhere else on the internet, you’ll find marketers talking about ideas (drip emails, etc.) that drive conversions for entire products. Here, I’m going to lay out specific tactics you can use to increase feature adoption in your SaaS product.
When you ship something useful in a SaaS product, the work is barely over – it’s just getting started. In the months and weeks that follow, you need to learn what’s working, unlearn your assumptions, and find repeatable methods to consistently increase the adoption for the feature you just built. In this post, I’ll talk about how we used our product and website to drive user adoption for the help widget, something we recently worked on.
You can take these methods and replicate them for anything you’re building in your SaaS product to get your users to adopt them (assuming what you’ve built is useful.)
Continue reading “Increase feature adoption in your SaaS product with these seven ideas”
For a long time, business software was clunky. Consumer software continued to radically innovate on user experience, staying ahead of the curve.
Palm to iPhone. Styluses to capacitive touch. Taxis to Ubers. Torrents to Netflix. MP3s to Spotify, etc. We’ve lived through this story of how innovation in consumer software radically improved our lives in the last decade.
At one point, business software had no choice but to stop being clunky and terrible to use, because nobody wanted to walk into work to use shitty software. And as teams got more power to pick the software they wanted, business software had no choice but to be simple enough for anyone to try and buy.
If a business application wasn’t easy to use, people just abandoned it and start trialing something else. Apps that had the best user experience started winning more often at work than the ones that didn’t.
Everyone called this trend ‘consumerization of business software/IT’. Dropbox, Google Drive, Docs and Sheets, etc led this era. But despite all efforts by business apps to keep things simple, consumer software continued to set the gold standard in user experience. Business software just followed the direction already set by consumer software products.
However, I think the scene is changing.
Continue reading “Business software is so good now, that it’s competing with consumer software”
When businesses start out, support and sales teams (like any other team) are closely knit. The teams are small and most folks know the ins and outs of the product being sold. Everyone stays on top of new product updates by playing with the latest features, reading documentation or just being quizzed in the hallway by another team member.
When these team members work together, they create knowledge that’s shared within their tribe. They know what works really well in the product and what doesn’t, what pitch to use when on a sales call and what’s the best solution to provide when a certain problem is reported by customers. Even if someone doesn’t know the direct answer, they’d most certainly know an expert in the tribe who can help them out.
This is tribal knowledge. In most companies, tribal knowledge is not written down. It’s created every day. People acquire tribal knowledge by working together, talking about problems, sharing insights and know-how when solving those problems together.
Continue reading “Fighting outdated tribal knowledge in sales and support teams”
Businesses default to re-organizing their teams when they want to do things differently. While this does solve certain problems, it’s not always the silver bullet.
I’ve been part of several changes in teams, and I’ve seen people move teams. I’ve seen re-orgs happen so many times that I’ve gotten tired of them. The people doing the re-orgs see them as a panacea to everything, but they often miss the details.
Continue reading “On team reorganizations”
We hired Akshaya to work on product copy for Freshdesk. We worked together for six months, writing and reviewing content for screens every day.
She wrote about how she got started and lessons we learned together, along the way. If you’re just getting started with UX writing, you should check out her post here.
I started out in PR at Freshworks. I rarely spoke to customers when I was in PR, except when I worked on doing some case studies of how people used Freshdesk. It’s something I regret now – I should have used the first two years of my career to get in front of more customers. The fact that I didn’t start out in support or presales was a big disadvantage for me when I moved to product management.
But when I did move, the first thing I wanted to do was talk to our users and get a mental model of a typical business that used Freshdesk. We didn’t have a user research team back then, and I’ve never liked waiting, so this is how I rolled up my sleeves and got some work done, to start talking to several customers.
I’m sharing these three ideas, because they will help you quash blockers to user research in your organization. Let’s go.
Continue reading “Three ideas to help you get started with user research”
Last week, my engineers and I met to discuss the specifics (or so we thought) about a feature we were going to be working on. Even after an hour of healthy debate and discussion, I felt that everyone in the room wasn’t on the same page.
- the backend engineers thought they knew – down to the details – how they needed to structure what they’re going to build
- the frontend engineers assumed a certain structure for how the backend engineers would build their pieces, on top of which they’d be working on
- the new hires in the team were probably struggling to put pieces together based on our discussion
If we had actually gone ahead and built what we wanted to build without getting to the details in writing, it’d have been nothing short of a disaster.
Continue reading “Making your team discover the joy and value in writing things down”
I think copy is an intricate part of product design. Getting everything else right, and product copy wrong would still be a disaster. But in most organizations, product copy falls through the cracks. It’s the last thing anyone worries about, and it isn’t seen as something that influences user experience. When not well thought-out, unclear copy doesn’t just make your product look unprofessional, but also frustrates and annoys users.
The hardest thing to do is convincing designers and engineers – the entire product team that words matter. The best way to go about it is to show, and not tell. When we got on calls talking to Freshdesk users, we realized many of them were confused by something we thought was very simple to understand.
Continue reading “Convincing your team that words matter”
If you’re building a business that grows like crazy, documentation should be a culture trait you should promote and look for in the people you hire. I realized this when we worked on a major revamp of Freshdesk’s product interface in 2017.
The team worked hard for close to a year on this project, and we thought we had a great launch in 2017, but soon discovered hundreds of features that we missed out. Our very own customer support team had to tell us about features that were part of the older interface, and we scrambled to build them later. A lot of times, we learned about product behaviour only after our customers told us about how much they missed them in the newer interface.
Continue reading “You cannot scale without documentation”