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.”

Shaun Juncal makes a compelling argument in Product Accessibility Shouldn’t Be an Afterthought:

But addressing accessibility early and often—if not making it an ongoing pillar of product quality—is a best practice every product team should embrace. Accessibility enables the maximum number of potential users to engage with products, increasing the total addressable market and avoiding frustrated customers from getting tripped up on accessibility shortcomings. […]

When a product doesn’t fully incorporate accessibility, the company is essentially telling a cohort of potential users that “this product isn’t for you.”

He shares some good advice on how to make accessibility efforts a natural part of the product development process.

Ben Nadel proposes A Good Samaritan Law For Engineers At A Software As A Service (SaaS) Company:

How can we instill in our people the unwavering conviction that they have the freedom to create a better user experience?

One idea that popped into my head was to create a Good Samaritan Law For Engineers: an explicit promise by the company that no engineer will ever be fired for attempting to, in good faith, help a user or create a better user experience. And, I don’t mean as an implicit piece of the Tribal Knowledge; I mean as an explicit, codified part of the culture — an entry in the employee handbook — a poster, up on the wall, that any employee can look at and point to and use in their decision-making algorithm.

This should, of course, be true for everyone in an organization, not just engineers. But I like the point about codifying it — making it a principle that’s published, well-known, and ingrained in the company culture.

Emile Ledure tries to answer the question, “how do you build products that stick and last in a healthy way?” I really like his approach in Healthy Retention: What Makes People Keep Coming Back? I especially appreciate the principle “Have fewer but better interactions”:

You don’t necessarily build retention by pushing people to use your product every day, you do it by bringing high value every time they need it — even if it means being absent most of the time. So don’t be greedy. […]

Fewer but more memorable experiences help you build stronger and deeper relationships with your users, which creates loyalty in the long run.

This is a helpful article from Jeff Vincent about the “nth user problem”. This is a not-so-great term for a very real problem: how to make sure you’re able to effectively onboard additional team members on a customer’s primary account. From SaaS has an nth user problem:

A huge driver of churn in the most successful SaaS businesses is loss of champion churn — or when your product’s greatest advocate within a customer company moves on to another job or department and the replacement admin abandons your product in favor of a new platform. This is the end result of the nth user problem at work.

Jeff shares lots of good advice on how to take care of additional account users and make sure they become engaged users and advocates.

Google UX Designer David Hogue shares his thoughts on How to Reverse Over-Complication in Product Design and How to Avoid It Altogether. It’s a very good read for product managers. Here he describes how do build a process to avoid over-complication:

Critically evaluate every new and existing feature for the value it provides weighed against the costs of including in a product or service. Does a feature introduce friction or ambiguity? Does adding something more make flows, paths, and choices harder to understand? What are the potential positive AND negative outcomes of adding something, and is it worth it?

Constant vigilance against entropy, scope creep, and the accumulation of friction is necessary. Pausing for review after major releases, conducting retrospectives after updates or changes, critical analysis of product performance before and after a change, and ongoing quantitative and qualitative research can all provide information about and indicators of increasing and unintended complication.

Ian Bicking makes some very good points in his post “Users want control” is a shoulder shrug:

Control is what you need when you want something and it won’t happen on its own. But (usually) it’s not control you want, it’s just a means. So when we say users want control over X — their privacy, their security, their data, their history — we are first acknowledging that current systems act against users, but we aren’t proposing any real solution. We’re avoiding even talking about the problems.

I like the framing of the broad concept of “user control” in this very Jobs-to-be-Done way. It’s almost like a safe word to watch out for. Whenever we catch our colleagues (or ourselves!) arguing for giving users more control over something, we should immediately stop ourselves and try to uncover what deeper need the discussion about control might be obfuscating.

I’m staying out of the “hot takes on that John Maeda interview” genre, but I do want to link to Heather Phillips’s Stop dwelling on being design-led: Focus on the user. She brings up some great points that product managers need to keep in mind as well:

We shouldn’t think about being design-first, or development-first. Instead, we should be thinking about how we can bring our paths closer together. Every business function — including design — should be thinking about the user, first and foremost. And building solutions with the best user experience in mind. This work should not be silo’d in product, marketing, or design.

We’re in this together.

Amen to that.

I talked about adding friction to products last week, and Kurt Yalcin’s article Against Engagement makes for a great companion piece. He touches on many topics, but I especially appreciate his views on that topic:

Slowing experiences down with intention and adding deliberate requests for user action at critical moments in a user flow makes for better experiences in the long run. Bring a level of consciousness to your designs and address the pressures you may have to reduce friction at all costs. If adding an additional click means giving users more freedom, go with the extra clicks. This level of awareness in your design enables users to make conscious choices about when, where and how to engage with your products, rather than acting on autopilot.