Menu

Make accessibility part of planning for every project

In Getting to the Heart of Digital Accessibility Carie Fisher makes a compelling argument for making accessibility a priority in tech companies. Her conclusion really resonated with me:

Maybe I’m naive, but I’d like to think we’ve come to a point in our society where we want our work lives to have meaning. And that we don’t want to just hear about the positive change that is happening, but want to be part of the change. Digital accessibility is a place where this can happen! Not only does understanding and writing purpose-driven code help people with disabilities in the short-run, I believe strongly that is key to solving the overarching diversity issue in tech in the long-run. Developers who reach Stage 4: Understanding, and who prioritize accessible code because they understand it’s fundamentally about people, will also be the ones who help create and cultivate an inclusive environment where people from more diverse backgrounds are also prioritized and accepted in the tech world.

She mainly mentions developers in this article, but I’d argue that it is very much also the responsibility of product managers to make sure accessibility is always in the discussion on projects. We need to make sure that if extra time is needed for accessibility, we build that into the planning.

Further reading

For some practical advice on how to make emails more accessible, see Accessibility vs. Inclusion: What it Takes to Create More Inclusive Email Marketing Experiences and Email Accessibility: Looks aren’t everything.

For an example of how not to approach this topic, see Should websites be accessible to everyone? Domino’s says no.

Measure product teams by value created, not number of features launched

In his post Why Feature FOMO Stalls Product Innovation Brian Crofts discusses the many reasons why product teams tend to add a slew unnecessary features to a product. This issue hit close to home:

Pendo’s recent State of Product Leadership survey found that 77% of product teams are evaluated based on the number of features they ship. This gives product teams an implied incentive to add more, regardless of whether those features are being used and adopted.

I can only trust that this has changed by now, but when I worked at eBay product managers were measured by how many PRDs they wrote. The things didn’t even have to ship. The measure was literally “How many Word templates did you fill out this quarter?”

Instead, Brian proposes a better way:

Technology brands should hold their product teams accountable for metrics that have the greatest impact on success. Instead of the raw number of features shipped or revenue driven, metrics such as feature adoption, customer happiness, and customer engagement are critical. These measures point to which features are working now and help form longer-term rollout strategy.

Don’t get customers hooked, focus on healthy retention instead

I’m getting increasingly nervous about the ongoing emphasis on getting users “hooked”, which is taking the product world by storm. The latest example (of many) I’ve read over the past few months is Sticky From the Start: How to Create a Sticky Product Experience, which includes advice such as “Create habits to keep them hooked”:

But thanks to notifications, emails, and other prompts, SaaS products have the option to nudge new users to engage in the behaviors most likely to deliver initial value. In-app messages can build awareness of features, spark usage, and beckon users back to apps even when they’re not using them. They’ve been found to increase user engagement by 4X and when combined with push notifications can increase engagement rates by 30-40%.

Thinking only about engagement rates without the impact that has on users is a short-sighted and unethical way to build a lasting product. Think about the proliferation of chat widgets on websites that ask you if you need anything before you’ve even had a chance to read a few words. What thoughts go through your mind when that happens? Or when a site immediately asks permission to send you notifications, before you’ve been able to figure out if you’re interested in what they have to say. My guess is that you are as annoyed and turned off by those tactics as I am.

I am way more interested in the idea of healthy retention, which is based on the principle of “fewer but better interactions”. We don’t need to get people hooked or “increase engagement” to make them happy customers for life. Emile Ledure makes that point well in the post Healthy Retention: What Makes People Keep Coming Back? with three proposed principles:

  1. Define how you empower people — what do you help people accomplish in their lives?
  2. Have fewer but better interactions — how do you focus on value rather than frequency?
  3. Care — what makes your experience human?

In his excellent book Company of One: Why Staying Small Is the Next Big Thing for Business Paul Jarvis makes a similar point in a slightly different way:

I 100% agree with his point that the cornerstone of a profitable company is customer success — not people who are hooked on us. Let’s look for ways to have fewer but better interactions with our customers. Let’s measure our success by how happy people are to pay us, not by how often they log in. That’s how you create lifelong fans instead of temporary “users”.

Collaboration > tooling

Brad Frost argues that design tools are holding us back because “they require a specific toolchain in order to function”. Instead, what we need is closer collaboration:

Tooling can help, sure, but it’s not a silver bullet. To truly address the realities of the medium for which you’re designing, designers and developers should collaborate as equals to solve problems together. That means more talking and real-time collaboration and less time spent throwing static artifacts and Zeplin links at each other.

The importance of getting customer feedback before product launches

I’m not usually a fan of posts like this, but I just couldn’t resist clicking on Pink Floyd Were Masters At Achieving Product-Market Fit. The first of seven “lessons” is the one that stands out for me:

Obtain Customer Feedback Before You Release Your Product

Musicians spend their entire youth writing songs and performing them in front of live audiences, which ensures that their initial album is validated by their fans before they enter the recording studio.

Unfortunately, successful musicians seldom have the luxury of market testing their subsequent albums. Instead of refining their material based on customer feedback, they are often lock away in a recording studio, isolated from their fans. Thus, it is no surprise that many bands suffer the sophomore jinx, in which their second album fails to achieve the success of their initial release.

Pink Floyd recorded Dark Side of the Moon after a year of writing and performing the material in front of live audiences. This audience feedback allowed the band to iteratively modify their creation.

Lesson: Avoid the sophomore jinx with your product launches by continuing to seek market validation, despite your initial success.

I guess in the interest of full disclosure, I should admit that I wrote a post like this once: A story about Miles Davis and the nature of true genius.

Reducing Time to Value, and other important product-led growth metrics

In 8 essential metrics for measuring product-led growth Katryna Balboni discusses a few important metrics for measuring and monitoring product-led growth (i.e., turning users into advocates so that they can they drive more acquisition and growth). Time to Value is one that seems particularly useful:

Time to value (TTV) is the amount of time it takes new users to realize your product’s value. Your goal should be to reduce time to value as much as possible-the sooner users reach their first aha moment or activation event, the better.

To do this, focus on optimizing your user onboarding experience around the key actions within your product that correlate to activation-like inviting colleagues to your platform, importing customer data, or integrating with other tools in their tech stack.

The best response to a product is “I happily give you money”

This was fun. I got to talk to the productboard team about our values and how we approach product strategy at Postmark. Here’s an excerpt from the article For Postmark, Product Excellence means enabling startups and developers to build great things:

For every feature that goes into delivery, and when considering Postmark’s product as a whole, Rian aims for customers to have two primary responses. One is: “Well that was easy.” The second is: “I don’t mind paying for this at all.”

“We want to create enough value so we’re not seen as just another app that our customers have to grudgingly pay for every month. We want to be the kind of software that we ourselves would enjoy using and paying for. I feel like that’s such a great metric: ‘I happily give you my money.’ That is the best response to a product.

Make customer success part of your product as early as possible

The co-founder and CEO of knowledge sharing tool Guru shares some great advice on product development in Mastering the Art of the Outcome: How Guru Turned Customer Success Into a Company Cornerstone. I especially appreciate his point on the importance of making customer success integral to the company very early on:

“Most young companies will hold off on investing in a customer success manager before they reach a certain annual recurring revenue. You’ll see founders working off of ratios, such as having one CSM for every one to two million in ARR, all while they’re furiously expanding the sales team,” he says. “If you want to stay outcome-oriented, that’s a huge mistake.”

In Nucci’s view, this approach overlooks a simple truth: When the contract is signed, your work is just beginning. “Dedicating a team to customer success lets you optimize for customer outcomes proactively,” he says. “If you neglect customer success, you’re setting yourself up to battle fires as they start, and potentially losing customers along the way. You don’t need me to tell you that’s not a great outcome.”

More

  1. 1
  2. ...
  3. 35
  4. 36
  5. 37
  6. 38
  7. 39
  8. ...
  9. 201