Introducing Productboard Pulse. Exec-level insights into what your customers need, powered by AI. Learn more

Why you should build for your actual user, not your aspirational one

Why you should build for your actual user, not your aspirational one

Too often, a product’s best features are accessible to only a small number of its users. Make sure you don’t fall into this trap.

This article was first published in Built In.

Imagine you’re bringing a friend skiing with you. They’re a beginner, so they’re a little nervous since they’ve only done green courses before, never the intermediate blues or advanced blacks. What do you do in this situation?

If you’re smart, you bring them on a green first and see how they do. When they feel comfortable, you can suggest trying out a blue. And what do you want to avoid at all costs? Bringing them on a black before they’re ready. Do that, and they’ll probably never go skiing with you again — and your friendship might even be over.

What does this have to do with product development? The same concept applies to software. We want to meet our users where they are and help them gradually develop their maturity within the product. Just like we would help our novice skier friends to move from the green courses to the blues, we need to create a path for our beginner and intermediate users to improve their skills. If we force them to become advanced before they’re ready, they’re likely to churn and burn.

What level is my user?

  • Actual user — The broadest base of your customers, this group includes novices and others who understand only the most basic functionalities of the product. Some of these users aspire to grow their skills, but others are fully satisfied completing basic tasks with the product.
  • Intermediate user — Intermediate users find enough value in your product that they begin to develop more advanced skills. You can likely convert them into power users from this stage.
  • Power user — Power users have mastered the product and can complete even the most complex processes. These folks are among your most loyal customers.

Why Do We Assume Everyone Is an Advanced User?

Assuming all users are experts might sound counterintuitive, but it happens all the time. There are a few reasons why product managers design for aspirational or power users rather than meeting most users where they actually are.

We suffer from the curse of knowledge

As product managers, we often use our own tools in a more advanced fashion than our average user. We forget that not everyone has the same depth of knowledge and experience with our product that we do.

We’re overly optimistic about outcomes

Product managers often have an optimistic outlook. We design our products to solve our customers’ problems and make their lives easier. So, of course, we hope that they’ll make full use of every feature we build, even if this isn’t realistic.

We believe advanced features are the most valuable

We pour so much effort into building features that we want our customers to use them in the way we intended. We believe the most advanced features will provide the most value because they’re solving the most sophisticated and complex problems. It’s easy to see how this can happen from a business metrics analytics perspective. When we do analysis to see which features are the most sticky, we can see that our “black diamond” features (things like Salesforce integration) are the ones that lead to longer lifetime values.

The Problem With Power Users

Many product managers would, understandably, like to use the information they gather from analysis to inform their product decisions. If you know which features have the biggest impact on customer lifetime value and retention, of course you’d want to prioritize those. But this approach can cause problems.

Sophie Lalonde hand-drawn example image of a scatter plot

In this example, A and B appear to be the most retentive features. They’re likely the most advanced ones because the other features appear to barely get touched. But getting folks that are beginners to C and D may be a better idea, even if these features are less retentive. Consider the maturity model for your users, not just which feature usage is more retentive (not causing churn) or converting (causing sales).

Plus, the problem with high-converting events is the lack of causation. The fact that someone used the Salesforce integration is not necessarily the reason they’re retained. It’s more likely that they’re a power user, and they get a lot of value from all the features they use.

Our power users are an aspirational user set. Getting an intermediate user to become a power user is a realistic goal. Getting our actual user to become a power user, however, skips many features that are more approachable and likely more useful for them, not to mention less overwhelming to set up or ascertain.

It is also worth mentioning why you should focus on individual users rather than treating an entire customer’s space the same. Just because one user at your customer is a power user, that does not mean the other users are the same. User patterns within one customer space can range quite a bit. Although you can try to teach the power users to teach the rest of their organization, change management can be hard. Getting the entire team bought in and willing to adopt a new way of working can take months, so make sure you are meeting each user where they are in their sophistication of using your product.

To sum up, we often mistake what our aspirational users do for the ultimate happy path of an actual user. But, in reality, if your actual user was just 10% happier, they’d probably be a lot likelier to stick around. This retention may eventually lead them to become a power user over time. You don’t necessarily need all the bells and whistles.

Sometimes people just want to ski blues on a powder day. That’s where they’ll be happiest and get the most value. Developing a clear understanding of your actual, intermediate, and power users will help you avoid some of the traps we’ve discussed.

How to Design for Your User’s Experience Level

The features that you highlight should be in the next level of the user’s maturity model, not two steps forward. Here are a few examples to illustrate this point.

Box (cloud-based content and file management):

  • Actual user: Store completed documents
  • Intermediate user: Edit documents in Box
  • Aspirational user: Complete document workflows with other people (like document signing)

Sophie Lalonde hand-drawn example of Box users

Although workflows are the most retentive feature, asking users to feel comfortable doing this may be a big jump. Getting users to edit their documents in Box is a good intermediate step that allows their documents to stay up to date and encourages them to continue using the product in a more advanced way. Once they achieve this, then we can encourage them to use workflows.

Productboard (user insights, prioritization, and roadmaps for product managers):

  • Actual user: Sharing roadmaps
  • Intermediate user: Tracking customer insights
  • Advanced user: Leveraging segmentation

Productboard’s best customer-centric feature is segmentation, and we want the broadest amount of our customers to use it. Thus, we can easily fall into the trap of trying to bring our users from sharing roadmaps to leveraging segmentation if we want our users to become more customer-centric.

Although segmentation certainly delivers all the bells and whistles, it takes quite a deal of effort to set up and involves Salesforce admins from outside the product department. It also requires an advanced way of thinking about comparing problems or feature requests across different sets of groupings.

On the opposite end, tracking customer insights doesn’t take as much effort to set up, and it is quite an intuitive way of thinking. It involves bringing in all customer feedback and seeing what comes to the top.

Even though leveraging segmentation provides more customer value, the happy path is to get users set up on tracking customer insights first before making the leap.

User-Centric Product Management Guidelines

Following these guidelines can help your entire process.

Don’t think about this at a space level

In other words, don’t group your customers as a single entity. Every company has multiple users, and they’re all at different levels of maturity. If you launch experiments trying to get people to use new features, target them to individual users and not the entire user base.

Some (but not all) actual users aspire to be power users

Although some users are happy to ski blues forever, they still like the idea of getting inspired by what’s possible. They want to know that if they do mature, there will be plenty of things for them to do at that next level. For these users, make sure to show your product vision, but also leave enough engineering effort to invest in the core use cases. Actual users will appreciate whenever you make their core workflows even more frictionless.

Growth tactics can help you guide users along their journey

You can take advantage of several growth tactics to help your users learn about and start using intermediate or advanced features. You can highlight the feature in an email, have customer success show folks how to use it, target specific customers with tooltips, or create inviting modals or collaboration loops so power users will hopefully encourage actual users to try out the feature.

Putting It All Together

What comes next? Now it’s time to apply the concepts I’ve been sharing here. Remember to put yourself in the user’s shoes, considering their needs at the actual, intermediate, and advanced levels.

Consider how you can help bring them to the next step in their journey. And remember you should not blindly think about it from a quantitative point of view, but truly internalize the right path to a happy user.

To take the next step for your own product, try drawing out a maturity model for your users. Here’s an example of how we’ve done this for our Insights product at Productboard.

Product Excellence Maturity Model

Just as I’ve outlined how our users progress from one stage to the next and how their behavior has changed, I’d encourage you to do the same. Taking the time to outline your maturity model will help ensure you and your team meet users where they’re at and nudge them to the next step.

You might also like

5 Benefits of Building Product Roadmaps Around Customer Insights
Product Management

5 Benefits of Building Product Roadmaps Around Customer Insights

Productboard Editorial
Productboard Editorial
Roadmap Alignment: How to Rally the Team Around Your Product Roadmaps
Product Management

Roadmap Alignment: How to Rally the Team Around Your Product Roadmaps

Productboard Editorial
Productboard Editorial
Product Makers Podcast: Ep. 1 Courtney Arnott, 120Water
Product Leaders

Product Makers Podcast: Ep. 1 Courtney Arnott, 120Water

Productboard Editorial
Productboard Editorial