Product design in practice: Fixing broken customer experiences in existing products
Digital products that clear the startup product-market fit race usually come with all kinds of baggage — tech debt, product debt, promises and visions teams never followed-up on… These can create serious friction between your customers and your company. If left unchecked, this kind of product debt can lead to horrible product experience, tons of poorly met needs and customer flight to your better competitors. In Kentico, I had an opportunity to work on optimizing product experience for almost 2 years. I’d like to share what worked for us and what turned out to be a red herring chase.
So your product now has customers, but its experience feels inconsistent, you’re getting bad customer feedback and it’s getting harder for your salespeople to do their job. First of all don’t panic, it’s quite normal. In the first years of product development, businesses usually care more about their competitiveness and finding a good product-market fit. Customer experience and retention is usually measured in only one metric — your customers’ churn.
After you have found your niche though, bad customer experience with lots of poorly met needs will lead to lower perceived product value and eventually, churn. This in turn leads to bleeding your company dry, as customers move to better solutions to their problems. Those that are left are unwilling to pay more of course, so you won’t grow. This is why it’s necessary to optimize customer experiences holistically, unlocking feature value for the users, fixing the biggest frustration hotspots first and building true clarity about product’s future vision.
Part 1: How to fix bad customer experiences, step by step service design guide
1. Define your outcome: What goals do you really want to achieve?
In the immortal words of Simon Sinek: “Start with the Why”. Why are you trying to have a better customer experience? What does it mean for you specifically? What’s your ultimate product goal, what’s missing in your product experience right now? What are you trying to accomplish? How do you measure it?
Enhancing your product satisfaction, less churn, better competitiveness, great usability are all valid goals to pursue. You can easily fall into the trap of not defining what you’re after and trying to do everything. This was the case for us at Kentico. We were trying to achieve the best experience in content management tools. Of course, that was way too vague to ever become actionable. Before I realised it, we were already filling our backlog with crazy ideas (few examples: customizable action panels, AI-powered asset tagging, mobile app…) that didn’t work for what I thought optimizing our customer experience should have been about. That’s when I realised, we never specifically defined objectives, outcomes and specific measurable key results, so everyone had a different idea of what it actually means.
If you want to skip all that, start with the outcome first. Have a sit down with stakeholders on your project, specifically your management that are submitting this project and the project owner. Be extremely specific about the budget you are willing to invest, how long it should take, and what specifically you want to happen for your business.
As a project owner, you should learn to love these constraints, as they provide structure and priority to everything else you’re doing. It’s likely you’ll be working months or years on this, so spend enough time on the outcome.
It will become more important as you go on in your project, as outcomes shape what things to cut from MLPs (minimum loveable products) to make them work and how to measure if you’re successful with your releases.
2. Map customer journeys, feedback hotspots, and personas
Bread & butter of every product manager and UX designer. The type of insight visualisation that’s best for you will depend a lot on the product you’re trying to fix. Whether you are providing physical customer services like e-commerce deliveries or something entirely digital like an API served content, you need to map what actors you are trying to affect and when. There are many great sources on customer journeys, impact mapping, and personas already on the web (anything from NNgroup is excellent), so I’ll skip over explaining them in detail.
Feedback hotspots can be summarised as areas of your digital product or service where a lot of negative feedback or requests is concentrated. Usually, your customers tend to be somewhat similar (they are using the same product after all), so when you delve deeper into your customer feedback, you’ll find specific parts of your experience stick out like a sore thumb. It’s a good idea to have a strategy in mind for how to gradually address these and prioritize them with the rest of your product debt that you’ll uncover.
But what if you don’t know your users yet and you don’t really have any feedback to go on? Read on!
3. Kickstart your insight gathering: Regular usability tests & measuring experiences systematically
What I quickly found out when I started talking to other Product Managers about exploring opportunities is that not many SaaS companies gather user insights right. Usually, PMs care a lot about feature requests, which I reckon comes from the traditional mindset of “build 1 solution > get 1 outcome”.
This is where I see things very differently. Users usually interact with the whole service, they seldom use just one isolated feature of a product.
People perceive the value you are providing them through your brand and how every piece of digital experience feels and functions. Through all our research and testing, I have come to the conclusion that it’s very hard for people to separate parts of their customer experience and judge them separately. If you’re in B2B, that means a salesperson who is up-selling your customer, UX of your single feature or your website’s marketing promise are all part of one product experience.
Therefore, if you want to gain a systematic overview of your service, you need to gather insights from more varied sources than just NPS and feature requests.
We’ve found two great tools for this, regular usability tests and product surveys. I will just briefly go through both, as they could warrant their own article.
Regular usability tests
These are done periodically to establish a baseline for your product's overall usability. We picked the most common scenarios done across our two personas, which we further split up into two different test batches. Every 6 months or so, we tested with users and used SEQ and SUS to measure how our scenarios and product are doing overall. On the way, we gathered hundreds of small usability and product insights and prioritized them according to impact on our outcome.
Product surveys
Getting rid of the NPS survey. I wanted to do this for a long time. NPS was a tool that just didn’t work for us at all. We wanted something that every user of our app would have a chance answering. We needed to know what specifically are they frustrated or happy with. At the same time, we needed it to be lightweight and fast, so that it’s not annoying.
We ended up using a variant of UMUX-lite survey, build into app. UMUX-lite is an amazing standardised survey, that every PM and UX designer should know, as it measures both usability and requirement satisfaction. You can read more details about it here.
Results were astounding. We successfully gathered hundreds of individual feedback from our users that we just wouldn’t get any other way.
Don’t forget insights you already have
There’s no need to trash all your existing research, just because you’re trying something new. You probably already have a lot of insights. Interviews, sales information, customer feedback etc.
You can absolutely use all of these when mapping out your problem space. It will take a lot of work, but if it’s still valid, it’s the cheapest way to synthesize new opportunities.
4. Prioritize opportunities/outcomes: Solution trees & RICE are great
Now that you have a nice problem space map, with actors (your personas), their scenarios, and hotspots of problems, you will see patterns in common feedback. These can be anything from bad feature design, unmet needs, nasty support or salespeople or unfulfilled marketing promise. Some will be easier to solve then others, but most will require cross-company cooperation. You’ll need to wrap-up all your insights into a concise form so you can talk about different opportunities and work with others to rank their importance.
We’ve found that a combination of Opportunity Solution Tree framework with RICE scoring is a very good fit for that. Again, I won’t go over too much detail in this article, but I’ll link more resources.
One excellent thing about Opportunity Solution Tree is that it brings clarity to everything in your project. It makes for an excellent communication tool with stakeholders when explaining why are you choosing to work on something. It’s amazing at bringing dev and designer teams up to speed because it’s much easier to understand than complex problem definitions and long documents.
It can also be used well for next product discovery efforts, like choosing what needs more extensive research, as you’ll quickly see what parts of the tree are foggy or not populated enough. Last but not least, they are great for product discovery teams, who need to understand problem space and decide on what experiments to build to validate hypotheses.
We’ve also had success with RICE score to compare different opportunities. We usually structured opportunities into a list from our Opportunity Solution Tree and then rated them with RICE. You can involve stakeholders, PMs or teams here, depends on your situation. I don’t believe RICE score should be absolute measure of how to sort our backlogs, but it makes for a great discussion tool. It forces you to ask the right questions like “How many customers actually asked for this?” or “How confident are we really about this?”.
It can serve as a great way to prioritize your research as well, as opportunities with high potential impact and reach, but low confidence will be the most valuable to gather more data on.
5. Begin real product discovery: smaller experiments with measured impact
Now that you know who your users are, what’s their customer experience like and what outcome you want to pursue, it’s time to bring it all together. For starters, you need a budget to make the necessary changes, usually that’s a developer and designer resource. Dedicating a small team to this is a good idea, the longer the teams have to absorb the context, the better their solutions will be.
First, you’ll need to decide what you are actually going to change to make the most impact. This is where things most differ between physical services and digital product offerings. How you go about it will be pretty similar though. For every opportunity that you think will be valuable, you need to actually prove it is first. If you don’t, you can easily get trapped with creeping scope and building expensive things that don’t solve anything. Remember, all insights so far are mostly hunches or feelings from your customers.
No one ever promised you that if you just build what they ask for, the result will be a meaningful product. People are just generally trying to be nice and give you their best opinion. It’s important to realise that and treat it as such — just an opinion.
That’s why you need to build experiments — small enhancements or proto-features that prove your hypotheses — to find the valuable features faster and cheaper.
These go hand-in-hand with good analytics. For every experiment you choose to build, it’s extremely important to first set a hypothesis you are trying to prove, time-box your experiment and set specific parameters that establish if it’s successful. For example, we’ve used Amplitude to measure these through in-app events. (Note: My colleague Veronika Hradilová works on a CMS product that’s not easily measured through data-analytics. They are using other methods to measure events, such as more qualitative interviews with users)
Going from here, the process is getting simple. You just repeat prioritisation, research and experiments until you are getting the outcomes you want.
Then you buy everyone pizza and celebrate, optionally retire in your 30s.
Summary
Thanks for sticking ‘til the end. At the start, I set out to summarise the process that me and my teams found out to work quite well in optimising existing products. It’s based on science, iteration, and focusing on your customers. I hope this will help you in whatever product you are trying to change for the better.
To sum up:
