« Back to Dev Toolkit

💁 Is your product too opinionated?

  • GTM, Product
A drawing of Sparky the boldstart mascot riding a skateboard.

This article was originally published on Medium.

When reviewing new products, I’ll often come across one that takes a very opinionated approach to a solution. These products are designed for the process that the founder believes is the best way of doing things. Success becomes dependent on users already following this process or being willing and ready to adopt it.

Products give their opinions all the time — my language app believes the best chance of my success is by pushing me down a single path, even though maybe I’d prefer to jump ahead. My food delivery app thinks I should try new places instead of sticking to that one sushi place I like. My social media app thinks I should look at messages from people I don’t follow rather than those I do… sigh. The purpose behind these opinions is to drive the desired behaviour — but these are opinions at the feature level (which my colleague Ellen suggests I could write a whole separate post on!) rather than the entire philosophy of the product.

On the flipside, being too unopinionated is also unhelpful — not just because it leads to mediocre products — it can also leave users feeling unsure on the direction they should take that will give them the best chance of success.

A group of cave people at a market swarming around a stall selling rocks. A stall selling hoverboards has no customers.

The opinionated product

Apple is well known for releasing opinionated products which then inform the new standard. The proliferation of new languages and frameworks is built off of strong opinions on how code should be written and managed. The opinionated product can work. But it’s important to remember that even if you’ve got strong champions for your method, their needs might only represent pockets within an industry or company. Champions will need to convince other teams, and also their stakeholders, that this new way of doing things is better. Even once they’ve done that, there may need to be a transition period, slowing down any sales process.

One approach is to wait for the market to catch up and hope your company is still around by the time your user base adopts the new process. Another is to try and speed up adoption of that process through education. That can be risky.

Let’s consider an example. Most DevOps teams I talk to agree that percentage uptime is not the best measure of reliability. True reliability takes into account how many users that downtime impacts and which particular components it affects. Also, degraded performance isn’t part of downtime but really should also be taken into account. Still, that uptime percentage is what’s front and centre on most status pages. It might not be the best measure, but it’s become a standard that most people understand.

An opinionated product that attempted to disrupt this standard by showing a completely different metric might be able to win over a niche, similarly strongly opinionated audience, but would struggle to gain momentum beyond this.

To try and get more users to adopt this new metric, the company may kick off education on this approach — publishing whitepapers and giving talks. In the meantime, the competition could add this new metric to their existing tool. Then, all that hard work the company has done to educate the market on this new approach has improved improved adoption — but in someone else’s product. Ouch.

The most effective way I’ve found to get buy-in on your opinionated product is by supporting the team’s existing approach while nudging them onto your new one. Think of it as steadily removing a comfort blanket, or transitioning off of training wheels.

Strong opinions, loosely held

In design, Raymond Loewy (designer of the Coca Cola bottle, Greyhound bus, and US Postal Service logo) labelled his approach to successfully pushing boundaries as the MAYA principle “Most Advanced Yet Acceptable”. This approach encourages innovation, but with just enough familiarity that the user isn’t put off by the complete novelty of the new design. That balance is referred to as “optimal newness”.

“The adult public’s taste is not necessarily ready to accept the logical solutions to their requirements if the solution implies too vast a departure from what they have been conditioned into accepting as the norm.”

Translating this to product, we can ensure a new approach is more likely to be accepted if we make it familiar enough. Applying too much dogmatism on how users should do things will reduce the likelihood of it being adopted.

The training wheels approach

Understanding where a company is on their journey will help you build a product that can be adopted more widely. Be prepared to make some compromises, potentially enabling success with a method you disagree with, but you can still do this in a way that doesn’t completely compromise your philosophy.

A group of cave people at a market swarming around a stall selling skateboards. The rock stall has no customers.

Snyk followed this approach when implementing a proprietary Priority Score — a more contextually aware version of CVSS (a widely adopted security standard that scores the severity of vulnerabilities).

Security posture varies from company to company. Some companies are at the beginning of their journey and have no formal process when they discover a new vulnerability. Others are more advanced and have aspirational goals in place. Some are incredibly advanced and have created their own prioritisation scoring for vulnerabilities. Snyk had to try and meet the needs of each of these different levels of security maturity.

One of the goals that Snyk has is not to force developers to change their existing processes. Forcing a team to change their processes and adopt a new philosophy would cause a failure to adopt and roll the tool out in most cases. Instead, the tool supports a team’s existing processes, and guides them to optimising these towards better practices when they’re ready.

When Snyk implemented Priority Score, the goal was to get customers to use that instead of CVSS so they could fix the most truly critical issues first. And while many users were keen to adopt it, those users had to convince their stakeholders to adopt it too. In some cases, this would mean huge changes to how they reported on their security posture not just internally, but to external stakeholders such as auditors or their own customers. For this reason, Snyk showed both priority score and CVSS so that users could choose which they wanted to focus on. Over time, champions were able to sell the new concept internally, and they gradually switched over to it.

If your opinionated product can support users through their transition, you’ll be able to capture both today’s market and tomorrow’s.