9 ms·

Focus on the high-expectation customer

• crispinb 7y ago
  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.
  • KineticLensman 7y ago
    > 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.
  • azangru 7y ago
    > Writers: stop being so damned bossy. My personal pet peeve: titles going "Why you should do X".
  • amelius 7y ago
    > Writers: stop being so damned bossy. This also holds for commenters :)
  • apatters 7y ago
    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!
  • Ensorceled 7y ago
    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.
  • pferde 7y ago
    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.
• vladojsem 7y ago
  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.
  • reallydontask 7y ago
    > 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.
• mschuster91 7y ago
  > 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.
• nnq 7y ago
  Hallelujah! Maybe this will put a dent in the current dumbification trend of all apps/UIs etc. that's probably due to 'designing for the lowest common denominator'. 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!
  • gtirloni 7y ago
    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.
    • vinceguidry 7y ago
      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.
  • ako 7y ago
    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.
    • high_5 7y ago
      Yet, there's Apple that is the exception to this rule
      • deleted 7y ago
        [deleted]
• antisemiotic 7y ago
  >A gig economy worker (startup founder, ...) That made me chuckle a bit.
• gatestone 7y ago
  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.
  • barking 7y ago
    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.
    • dspillett 7y ago
      > 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).
    • GrinningFool 7y ago
      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.
  • phkahler 7y ago
    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.
• deltron3030 7y ago
  >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..
  • bluGill 7y ago
    > 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.
    • deltron3030 7y ago
      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.
• snain 7y ago
  Such a strong way to think about problems and products. Way better than segments and personas.
• nimbius 7y ago
  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?
  • Majestic121 7y ago
    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 ?
• barking 7y ago
  The Blog has its own domain but is actually part of Medium.com? I don't think I've seen this before.
  • Nextgrid 7y ago
    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.
  • lpellis 7y ago
    It was a feature of medium until about a year ago when they stopped it, some old sites are grandfathered in.
• arvidkahl 7y ago
  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.
  • playpause 7y ago
    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").
    • hammock 7y ago
      "customer need"
    • phkahler 7y ago
      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.
      • balfirevic 7y ago
        So, "power customer" (analogous to power user)?
        • 7y ago
• javajosh 7y ago
  If you take this advice, you'll run straight into the famous Innovators Dilemma (https://en.wikipedia.org/wiki/The_Innovator%27s_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.
  • cjblomqvist 7y ago
    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.
    • bluetwo 7y ago
      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.
• josefrichter 7y ago
  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.
  • ben509 7y ago
    > 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.
• jrochkind1 7y ago
  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).
• asdfman123 7y ago
  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.
  • bluetwo 7y ago
    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.