Focus on the high-expectation customer
uxdesign.cc
uxdesign.cc
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!
If you make things simpler/easier/clearer, conversion rates will almost always improve.
The "dumbification" trend you describe is simply driven by capitalism.
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.
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.
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.
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").
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.
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.
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.
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.
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.
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.
When they keep doing what worked for them yesterday, they run into trouble.
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 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.
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..
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 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 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 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.
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).
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.
I think I see where you're coming from, but not sure.
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.
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.
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?
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 ?
That made me chuckle a bit.
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.
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.
My personal pet peeve: titles going "Why you should do X".
This also holds for commenters :)
Try not understanding such titles as commands and get outraged, but instead as advice or suggestions that you are free to take or leave.