Focus on the high-expectation customer(uxdesign.cc)
uxdesign.cc
Focus on the high-expectation customer
https://uxdesign.cc/stop-designing-products-for-random-people-4734423cbfe6
15 comments
I hope so! I've had so many software enhancements written off by product owners because the features were, "targeted at power users". It gets tiring explaining that while we might not have any power users before the app is released (besides devs); we certainly will if our app meets with any definition of success.
That being said, I once put my high-expectations into hasty action and found out that my expectations and my customer's expectations can differ in seemingly impossible ways.
I was working on-site at a gold mine in Nevada performing updates to our mining software suite when I became deeply bothered by the fact that the touchscreen panel which we installed in the equipment had a keyboard where the letters were laid out alphabetically.
I quickly coded up a QWERTY version (and even had a DVORAK mode that could be toggled via an environment variable). I pushed the code that night and then went to an operator training session the following evening. More than one person asked why all the letters on the keyboard were in a random order. I barely tried to explain. Just admitted that it was a mistake and rolled back the code change.
That being said, I once put my high-expectations into hasty action and found out that my expectations and my customer's expectations can differ in seemingly impossible ways.
I was working on-site at a gold mine in Nevada performing updates to our mining software suite when I became deeply bothered by the fact that the touchscreen panel which we installed in the equipment had a keyboard where the letters were laid out alphabetically.
I quickly coded up a QWERTY version (and even had a DVORAK mode that could be toggled via an environment variable). I pushed the code that night and then went to an operator training session the following evening. More than one person asked why all the letters on the keyboard were in a random order. I barely tried to explain. Just admitted that it was a mistake and rolled back the code change.
They'd seriously never seen a computer keyboard?
I guess... I'm sure they'd seen a keyboard, but likely never studied it. Lots of flip phones and people that used a computer once at the library. Seemed impossible in 2011.
Most software businesses are driven by some sort of funnel - a set of conversion rates.
If you make things simpler/easier/clearer, conversion rates will almost always improve.
The "dumbification" trend you describe is simply driven by capitalism.
If you make things simpler/easier/clearer, conversion rates will almost always improve.
The "dumbification" trend you describe is simply driven by capitalism.
That was my initial gut feeling as well but high-expectation doesn't necessarily mean "more features" or "more customization". It could mean "simply works without much trouble" and then the dumbification trend fits perfectly.
The article was pretty specific about what it meant. She meant 1) someone who benefited from the solution 2) already had a hacked-together solution, and 3) had other people looking up to them in their field.
You shouldn’t market it as mediocre, but data will correctly show most customers are best served by mediocre products: most people need a mediocre car, not one that drives 300kmh, drives well off-road, or can carry 10m3 of stuff. Similarly, mediocre furniture (ikea), electronics or most anything else is good enough.
Funny story. My dad was a city planner for a small town who also ran the inspections department.
He would get frequent letters and calls from a particular citizen about inspection violations, who was kind of a pain in his ass.
So my dad hired him. And he became the best inspector he'd ever worked with.
He would get frequent letters and calls from a particular citizen about inspection violations, who was kind of a pain in his ass.
So my dad hired him. And he became the best inspector he'd ever worked with.
I like working with people with high expectations because you learn the most from them but you can't let them dictate your self-worth.
It's also important to note that the high-expectation customer is not the high-frequency complainer that you will have in your customer base. Don't confuse the two, they are opposites.
In my experience with my own company, there were customers who would reach out very often with ideas, complaints, and questions.
I learned at some point that these customers often were just confused did not even really understand their own problems. Figuring out a solution to help someone in that position is a very ineffective way to think about the product.
In terms of the model presented by the article, those vocal customers often lacked the hacker spirit, they benefitted marginally and were never considered experts in their field.
Took me a while to understand that the volume of feedback is not correlated with meaningful gains of information.
In my experience with my own company, there were customers who would reach out very often with ideas, complaints, and questions.
I learned at some point that these customers often were just confused did not even really understand their own problems. Figuring out a solution to help someone in that position is a very ineffective way to think about the product.
In terms of the model presented by the article, those vocal customers often lacked the hacker spirit, they benefitted marginally and were never considered experts in their field.
Took me a while to understand that the volume of feedback is not correlated with meaningful gains of information.
For this reason, I'm not sure "high-expectation customer" is a good term.
It also doesn't capture this part well: "someone who will benefit the most from your product, whether they realise this yet or not". If they don't realise it, their expectations are zero.
Maybe 'high potential benefit' would be a better term ("HPB customers").
It also doesn't capture this part well: "someone who will benefit the most from your product, whether they realise this yet or not". If they don't realise it, their expectations are zero.
Maybe 'high potential benefit' would be a better term ("HPB customers").
I would say "high performance customer". The one that is going to push your product to its limits, trying to make it do more than you thought it could. Those limits are where you need to add features so people don't have to hack around the limitations.
So, "power customer" (analogous to power user)?
I would invoke the "skin in the game" metaphor. Listen to customers who have a vested interest, for their own reasons (brand building, networking, the "expert" part) as well as for optimizing some part of their professional workflow, making your service a catalyst of their moneymaking abilities (the benefitter part). The hacker part to me is mostly a consequence of frustration or necessity, and that is different for every industry.
If a publicly outspoken professional uses your software, engage them. That has been very helpful for our company every single time. It resulted in great publicity, brand building and in almost all cases meaningful insight into the what and why of their actual business problems.
If a publicly outspoken professional uses your software, engage them. That has been very helpful for our company every single time. It resulted in great publicity, brand building and in almost all cases meaningful insight into the what and why of their actual business problems.
"customer need"
Something I noticed about the high-frequency complainers among my customers is that almost all of them got the product for free.
You have to gaurd yourself against cheap customers. They will squeeze you for everything they can get. This is not the same as customers that are low paying.
It seems to be statistically correlated, at least from my experience. We used to have a really cheap plan, now grandfathered in with just a handful of users, and those are - to this day - the most vocal group of complainers.
I believe that for some reason, a low price creates more entitlement than a higher price. I have yet to comprehend the psychology behind this, but customers paying up to three times as much complain far less often.
I believe that for some reason, a low price creates more entitlement than a higher price. I have yet to comprehend the psychology behind this, but customers paying up to three times as much complain far less often.
> these customers often were just confused did not even really understand their own problems
When you make software that helps people earn money, you’re competing with driving for Uber and Facebook ads, not just other business services. A less confusing way to make money is actually a huge innovation.
When you make software that helps people earn money, you’re competing with driving for Uber and Facebook ads, not just other business services. A less confusing way to make money is actually a huge innovation.
This is a very interesting insight.
If your product can both provide a great service AND educate you about how this service can be amplified by choosing the correct job to use it with, then you have a great service.
For me, customer education is a very big part of value nurturing. In my customer service conversations, I have often had the opportunity to directly talk to people who had yet to hear about major technical improvements that most of us here reading HN take for granted, things like clipboard history managers, text expansion tools or shareable screenshot / screencast tools. Providing insights directly to customers has been very interesting.
If your product can both provide a great service AND educate you about how this service can be amplified by choosing the correct job to use it with, then you have a great service.
For me, customer education is a very big part of value nurturing. In my customer service conversations, I have often had the opportunity to directly talk to people who had yet to hear about major technical improvements that most of us here reading HN take for granted, things like clipboard history managers, text expansion tools or shareable screenshot / screencast tools. Providing insights directly to customers has been very interesting.
If you take this advice, you'll run straight into the famous Innovators Dilemma (https://en.wikipedia.org/wiki/The_Innovator%27s_Dilemma).
And, I have personally experienced at least one counter-example to this advice. Your product can be pushed into a direction that meets only one person's needs, and confuses everyone else.
This is fine for a personal tool, and deadly to a tool that wants to be widely and frequently used.
Free advice is a risk-free way to get others to test your hypothesis for you.
And, I have personally experienced at least one counter-example to this advice. Your product can be pushed into a direction that meets only one person's needs, and confuses everyone else.
This is fine for a personal tool, and deadly to a tool that wants to be widely and frequently used.
Free advice is a risk-free way to get others to test your hypothesis for you.
Either I'm greatly misinterpreting your comment, or you mean something different than the innovators dilemma (maybe crossing the chasm?).
The innovators dilemma (and CC) refers to incumbents (established and huge) having issues handling disruptive /revolutionary innovation (in particular low value ones) due to issues with creating new markets due to not seeing enough size initially, path dependency, etc. This article seems to be targeted at startups.
The innovators dilemma (and CC) refers to incumbents (established and huge) having issues handling disruptive /revolutionary innovation (in particular low value ones) due to issues with creating new markets due to not seeing enough size initially, path dependency, etc. This article seems to be targeted at startups.
Yes, but companies don't see that they are running into this problem unless they get outside their own bubble.
When they keep doing what worked for them yesterday, they run into trouble.
When they keep doing what worked for them yesterday, they run into trouble.
This is actually a very narrow way of looking at users. There are plenty of situations that the users aren't aware of their "problem" or "need". In other words, they are not aware, that they could do something more easily, comfortably, etc. Or maybe they are aware, but don't have a solution. These people never fulfil the "hacker" or "expert" condition.
I would even argue, that designing primarily for anyone who could be described as "hacker" or "expert", is a highway to hell. These people have significantly different mind and way of using products (especially tech products), than mass market. So picking up this particular segment is a bad choice for most (not all) products.
I would even argue, that designing primarily for anyone who could be described as "hacker" or "expert", is a highway to hell. These people have significantly different mind and way of using products (especially tech products), than mass market. So picking up this particular segment is a bad choice for most (not all) products.
> These people have significantly different mind and way of using products (especially tech products), than mass market.
I think the point the article is trying to make is the high-expectation customers have or quickly find a way that definitely works for them. Whereas the typical customer will poke at it, say it doesn't work, and move on.
From a design standpoint, you want to start with an overall system that definitely works with some motivation and then solve the problems that block other customers from using it.
And I think it's implicit in their argument that you won't solve these problems for everyone who could potentially use the product, and that's a business tradeoff you have to make.
I think the point the article is trying to make is the high-expectation customers have or quickly find a way that definitely works for them. Whereas the typical customer will poke at it, say it doesn't work, and move on.
From a design standpoint, you want to start with an overall system that definitely works with some motivation and then solve the problems that block other customers from using it.
And I think it's implicit in their argument that you won't solve these problems for everyone who could potentially use the product, and that's a business tradeoff you have to make.
>Once you identify your benefiter, you need to understand how your product can help them get where they want to be.
How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
>hacks are temporary fixes at best. They (the high expectation customers) need a single solution that meets all their demands.
This isn't true, a hack doesn't imply that it's temporary, its longevity depends on the underlying problem and problem space. And even if they would be temporary, quick hacks can be more flexible and make it easier to react to a changing environment, so if that's important..
How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
>hacks are temporary fixes at best. They (the high expectation customers) need a single solution that meets all their demands.
This isn't true, a hack doesn't imply that it's temporary, its longevity depends on the underlying problem and problem space. And even if they would be temporary, quick hacks can be more flexible and make it easier to react to a changing environment, so if that's important..
> How can you identify a benefiter of a product, without knowing the problem that the product is going to solve (help them where they want to be)?
The two go hand in hand. You need to have an idea of where you want to be. However once you find the customer willing to spend money (if you are a business make sure they are willing to spend money!), you should chase the and ensure they are satisfied first. Don't make them regret giving you money by prioritizing features that they don't need over features they need. Make sure they are satisfied first, and use their satisfaction to drive more customers who are treated the same way.
Of course you need to be careful. If you want more than one customer you may eventually need to do a feature your customer doesn't need because future customers will, even at the expense of losing your one customer. This is a complex decision that you need to consider carefully - in part because how you treat your customer gets out and may drive away potential customers. There are a lot of products out there with exactly one customer, one more consideration. You need to figure out how this applies to your product yourself.
The two go hand in hand. You need to have an idea of where you want to be. However once you find the customer willing to spend money (if you are a business make sure they are willing to spend money!), you should chase the and ensure they are satisfied first. Don't make them regret giving you money by prioritizing features that they don't need over features they need. Make sure they are satisfied first, and use their satisfaction to drive more customers who are treated the same way.
Of course you need to be careful. If you want more than one customer you may eventually need to do a feature your customer doesn't need because future customers will, even at the expense of losing your one customer. This is a complex decision that you need to consider carefully - in part because how you treat your customer gets out and may drive away potential customers. There are a lot of products out there with exactly one customer, one more consideration. You need to figure out how this applies to your product yourself.
Wouldn't it be smarter to be the customer yourself, basically develop something for your own (business) progress or job to be done, and then sell it optionally to those in a similar situation?
The market first approach (developing a product for demand) only seems to really work with more generic products without high development cost, where the product advantages that result from deeper customer insights can't really play out. Where you don't run the risk of being outcompeted by a company that has those insights and customer trust from "wearing the same shoes" as their customers.
Market first could also work if you anticipate a future demand and it's a completely new market without any players yet, where you'd become the trusted choice over time because you're then seen as the original brand. But without funding it could be impossible to sustain to the point until you have enough customers.
The market first approach (developing a product for demand) only seems to really work with more generic products without high development cost, where the product advantages that result from deeper customer insights can't really play out. Where you don't run the risk of being outcompeted by a company that has those insights and customer trust from "wearing the same shoes" as their customers.
Market first could also work if you anticipate a future demand and it's a completely new market without any players yet, where you'd become the trusted choice over time because you're then seen as the original brand. But without funding it could be impossible to sustain to the point until you have enough customers.
Only if you are your own customer. There is a lot of need for software where the user is not a developer, and has better things to do with their time than write software.
Very true about "hacks". Oftentimes they have longer lifespan that standard solutions - because they "just work", might actually be inherently fragile, the original hacker is not around anymore, etc. => better not touch what ain't broken.
Hm. I've always thought that building for the hacker/expert is a mistake, because it means building for someone who is willing to invest more time in figuring out what your software can do for them and figure out your UX (and has more skill at doing so) than many, and you're going to wind up with a UX that less expert non-hackers find confusing and too hard to figure out, and give up on without finding value.
The hacker/expert understands the problem domain better than most (expert), and is willing to invest more time in figuring out how to find value in the software (hacker) than most users. Unless you only want to target hackers/experts (which you can if you think there are enough of them), it seems dangerous to your UX to focus on them.
Am I wrong?
(Focus, at first anyway, on those who will get the most benefit from the product "whether they realise this yet or not" -- seems unproblematic good advice to me).
The hacker/expert understands the problem domain better than most (expert), and is willing to invest more time in figuring out how to find value in the software (hacker) than most users. Unless you only want to target hackers/experts (which you can if you think there are enough of them), it seems dangerous to your UX to focus on them.
Am I wrong?
(Focus, at first anyway, on those who will get the most benefit from the product "whether they realise this yet or not" -- seems unproblematic good advice to me).
I have high expectations for free apps/services: They need to work immediately without a learning curve. See "hallway testing". They need to be competent but only modestly useful, if better alternatives are not available.
I have different high expectations for something I pay for. They need to be marketed to me, proving to me that they solve my real life problems competently. They can have a reasonable learning curve.
I have different high expectations for something I pay for. They need to be marketed to me, proving to me that they solve my real life problems competently. They can have a reasonable learning curve.
You could reject some very good free apps then. But I kinda agree with you. It's partly the phenomenon of attaching little value to something one gets for cheap/free. And conversely, people can bend over backwards to be impressed by something they pay a lot of money for.
I think the difference is that if it's a free app[1], the developer wants me to use it and I need to be convinced that it's worth my time.
If it's a paid app, I've already decided that it's worth money. If the app offers enough value for me to pay, then it offers enough value for me to learn what I need to learn.
[1] excluding open source - sure they want me to use it, but that's more like "here it is, use it if you want it". My expectations there are very different, particularly since I can often change things if it doesn't quite do what I want.
If it's a paid app, I've already decided that it's worth money. If the app offers enough value for me to pay, then it offers enough value for me to learn what I need to learn.
[1] excluding open source - sure they want me to use it, but that's more like "here it is, use it if you want it". My expectations there are very different, particularly since I can often change things if it doesn't quite do what I want.
> could reject some very good free apps then
That is a risk from this attitude. I'd wager that the savings from not ploughing through the dross outweigh the benefit of the few good ones that might be missed.
Especially considering the better ones with issues will hopefully come to our attention eventually by word of mouth (so we don't miss them, we are just a little late to the party), or attract competitors that fix those initial problems (or they themselves resolve those problems, which we then hear about through word of mouth and other sources).
That is a risk from this attitude. I'd wager that the savings from not ploughing through the dross outweigh the benefit of the few good ones that might be missed.
Especially considering the better ones with issues will hopefully come to our attention eventually by word of mouth (so we don't miss them, we are just a little late to the party), or attract competitors that fix those initial problems (or they themselves resolve those problems, which we then hear about through word of mouth and other sources).
Is the need for immediate usefulness of a free product a form of proof? I mean there is a lot of free crap out there, so are you trying to make a quick judgement with that? Why not the same demand of a paid product?
I think I see where you're coming from, but not sure.
I think I see where you're coming from, but not sure.
I know this is bound to get modded to oblivion but, what about customers who want utility based on real engineers and hackers and not magic marketing fluff. My day job is a diesel engine mechanic so im sure as shit not a "benefiter" or a runner or any of that. I dont have any kefir cultures or micro-greens unless somethings turned bad in the fridge.
Example: I own a ramnode VM, and it lets me do 90% of the studying and hacking i like because the people who make it happen are probably really interested in Linux like me. ramnode gives me space to really, really screw up a lot and learn how to recover or learn how to push forward. I get a good back-door to un-screw whatever it was i thought was a good idea (last week it was dd)
why not listen to the sysadmins and the SRE?
Example: I own a ramnode VM, and it lets me do 90% of the studying and hacking i like because the people who make it happen are probably really interested in Linux like me. ramnode gives me space to really, really screw up a lot and learn how to recover or learn how to push forward. I get a good back-door to un-screw whatever it was i thought was a good idea (last week it was dd)
why not listen to the sysadmins and the SRE?
I'm not sure I get your point. People creating products specifically for SRE and sysadmins definitely listen to them (or they should)
But not all products are for SRE or sysadmins (I'd venture to say most are not), so why would people listen to SRE and sysadmins specifically if they're not the target of the product ?
But not all products are for SRE or sysadmins (I'd venture to say most are not), so why would people listen to SRE and sysadmins specifically if they're not the target of the product ?
The Blog has its own domain but is actually part of Medium.com? I don't think I've seen this before.
It's quite common, and unfortunately awful given there's extra redirects (to medium.com and then back to the custom domain) to make their auth work. This is quite slow on a less than perfect internet connection.
It was a feature of medium until about a year ago when they stopped it, some old sites are grandfathered in.
Such a strong way to think about problems and products. Way better than segments and personas.
Writers: stop being so damned bossy.
The imperative title has had its run in the fussy etiquette pieces that so often pass as 'opinion' in newspapers. It wasn't any good there, and doesn't merit wider adoption.
The imperative title has had its run in the fussy etiquette pieces that so often pass as 'opinion' in newspapers. It wasn't any good there, and doesn't merit wider adoption.
> Writers: stop being so damned bossy.
Yes.
The article itself is very slightly more nuanced than its title, but it still describes a very targeted range of user ('hipster', 'geek'), that doesn't include 'employee' and 'tourist', for example.
> The imperative title has had its run in the fussy etiquette pieces
I agree that it is important to understand possible users, but the specific imperative of this title is not appropriate given the range of all the different types of possible users that developers may need to support.
Yes.
The article itself is very slightly more nuanced than its title, but it still describes a very targeted range of user ('hipster', 'geek'), that doesn't include 'employee' and 'tourist', for example.
> The imperative title has had its run in the fussy etiquette pieces
I agree that it is important to understand possible users, but the specific imperative of this title is not appropriate given the range of all the different types of possible users that developers may need to support.
> Writers: stop being so damned bossy.
This also holds for commenters :)
This also holds for commenters :)
I like it, it is direct and straight-forward.
Try not understanding such titles as commands and get outraged, but instead as advice or suggestions that you are free to take or leave.
Try not understanding such titles as commands and get outraged, but instead as advice or suggestions that you are free to take or leave.
I'll take "bossy" over "10 Reasons You Should Focus on the High-Expectation Customer, Number 8 will Astound You!!!!" any day of the week.
It appears the title has been changed. I wasn't going to read the article because of the old title. It was actually a great read!
> Writers: stop being so damned bossy.
My personal pet peeve: titles going "Why you should do X".
My personal pet peeve: titles going "Why you should do X".
Great article. When you design in that niche in your mind, it gives you a different perspective. It is a similar approach to what feature to have in the product is equally important to what features not to have there.
> It is a similar approach to what feature to have in the product is equally important to what features not to have there.
1000 times this. I used to work for a company that would add features if a customer asked for them and was willing to pay for them. Needless to say the product felt bloated, was hard to develop and maintain.
It was almost comical to see the Tech lead get incensed when a feature he'd lovingly crafted was completely and utterly unknown to the support team because no customer had used it, not even the customer that nominally had paid for it.
Unfortunately, this happened more than once.
edit:
I should add that our official day rate was comically low and sometimes would go lower to match what the sales person thought the customer would be willing to pay while nominally making a profit, I wish I were making this up.
1000 times this. I used to work for a company that would add features if a customer asked for them and was willing to pay for them. Needless to say the product felt bloated, was hard to develop and maintain.
It was almost comical to see the Tech lead get incensed when a feature he'd lovingly crafted was completely and utterly unknown to the support team because no customer had used it, not even the customer that nominally had paid for it.
Unfortunately, this happened more than once.
edit:
I should add that our official day rate was comically low and sometimes would go lower to match what the sales person thought the customer would be willing to pay while nominally making a profit, I wish I were making this up.
> You won’t just end with a product that solves real problems, you will win loyal customers who are vested in improving the product.
This is so true - but customers, especially the high expectations / nerd crowd, have grown incredibly tired of the industry trend that after product takeoff, sales/VC demand takes over and their (valuable) feedback is outright ignored. Just look how fucked up Twitter became over the years, the latest UI change is just another part of a string of shitload of management failures.
What this means: do not be sure this strategy will work out because customers have learned from other startups in history.
This is so true - but customers, especially the high expectations / nerd crowd, have grown incredibly tired of the industry trend that after product takeoff, sales/VC demand takes over and their (valuable) feedback is outright ignored. Just look how fucked up Twitter became over the years, the latest UI change is just another part of a string of shitload of management failures.
What this means: do not be sure this strategy will work out because customers have learned from other startups in history.
>A gig economy worker (startup founder, ...)
That made me chuckle a bit.
That made me chuckle a bit.
Hint: any app/tool/etc. that's "designed for the average user", will only help its user be(come) average and below average!
Now try imagining selling a product with the slogan "XYZ - Helping you stay mediocre, and even drop below the average! Use us every day, keep greatness away! ...if you're doing data-driven-product-design targeting the "average user", you're building just such a product!