Asking your customers what they want doesn't work(techbooks.substack.com)
techbooks.substack.com
Asking your customers what they want doesn't work
https://techbooks.substack.com/p/why-asking-your-customers-what-they
219 comments
The problem is that no one actually dug in, which is why I say 80% of product people are a net negative.
If someone asks for something, dig in.
Think about it like this.
I go to a mechanic and tell them to replace my alternator. They do. I'm unhappy with and tell them they did a bad job.
vs
I got to a mechanic and tell them to replace my alternator. They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B and I think they did a great job.
This is why senior developers often make better product people than product people. Too often you'll see PM's who will tell you the have 1-2, sometimes up to 5 years of experience as a developer. But quite often they don't actually understand anything because you can't beat that veteran with a guy who worked for a year or two then got a certificate for a product job.
people need to dig in, it doesn't matter what your assumption is, if you're not digging in and not having conversations you're making suboptimal decisions.
If someone asks for something, dig in.
Think about it like this.
I go to a mechanic and tell them to replace my alternator. They do. I'm unhappy with and tell them they did a bad job.
vs
I got to a mechanic and tell them to replace my alternator. They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B and I think they did a great job.
This is why senior developers often make better product people than product people. Too often you'll see PM's who will tell you the have 1-2, sometimes up to 5 years of experience as a developer. But quite often they don't actually understand anything because you can't beat that veteran with a guy who worked for a year or two then got a certificate for a product job.
people need to dig in, it doesn't matter what your assumption is, if you're not digging in and not having conversations you're making suboptimal decisions.
Absolutely.
95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding.
Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.
95% of the suggestions product creators receive are solutions. A product creator's job is to work out what problem their customer is trying to solve. It goes to the same motivation as root cause analysis when analysing an outage: the actual problem is nestled deep under layers of semantic shielding.
Whether your product is trying to solve that problem is another question, but at least you can understand how others perceive and try to use your product, which goes a long way to getting a product to be more broadly adopted.
> layers of semantic shielding.
I love this term. It describes perfectly something I encountered during my days as the sole technical support for a small ISP. I got really good at routing around it in my customers brains.
I would ask "have you installed anything?", they would say no.
I would ask "do you have any new programs or stuff?", they would say yes.
Because to them, installing something was like adding something under the hood of a car. Since putting in a new program didn't involve taking the cover off the computer, there wasn't anything "installed".
There was mismatch in our definitions of terms. I had to figure out how to route around it. I got really sensitive to things like that, and routing around it.
Semantic mismatch might be another term for it in my case.
I love this term. It describes perfectly something I encountered during my days as the sole technical support for a small ISP. I got really good at routing around it in my customers brains.
I would ask "have you installed anything?", they would say no.
I would ask "do you have any new programs or stuff?", they would say yes.
Because to them, installing something was like adding something under the hood of a car. Since putting in a new program didn't involve taking the cover off the computer, there wasn't anything "installed".
There was mismatch in our definitions of terms. I had to figure out how to route around it. I got really sensitive to things like that, and routing around it.
Semantic mismatch might be another term for it in my case.
semantic shielding is a word I have not heard before. But it perfectly summarizes most of the interactions with customers and stakeholders
I honestly made it up on the spot, so don't take it as proper nomenclature. However, to describe it another way: the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why.
However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.
However, asking that question without triggering a negative response is an art form within itself. Rarely can you be so direct, which is why it's often much easier to watch how a person interacts with a product rather than asking them why they did what they did.
> the unconscious mind synthesises its emotional choice, which the conscious mind presents as rational fact. If you want to know how the mind arrived at that conclusion, you've got to go on a fact-finding mission, i.e., asking why.
the more common name for it is post-hoc rationalization.
the more common name for it is post-hoc rationalization.
Thanks for that, I'll add that to my vocabulary.
Causal shielding feels like a better term in this case
Fully agreed.
Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.
Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.
The most successful company I ever worked out figured out a way to perform and get high quality feedback on low cost user experiments with a quick turnaround.
About 4/10 failed, 5/10 did ok and then with 1/10 they would absolutely hit it out of the park - usually on something that looked about as promising as the other 10. They did this frequently enough that they clobbered the competition, who were mostly just trying to do normal product management stuff like user surveys, etc.
The most interesting thing was that most people if you'd have asked them before would have gone "I don't think you can turn this into an experiment" and then immediately adopted a different strategy. Somehow they always figured out a creative way of injecting a low cost experiment where most people would have imagined that it wasnt feasible to run any experiment at all. It required quite a lot of pressure/leadership from above.
About 4/10 failed, 5/10 did ok and then with 1/10 they would absolutely hit it out of the park - usually on something that looked about as promising as the other 10. They did this frequently enough that they clobbered the competition, who were mostly just trying to do normal product management stuff like user surveys, etc.
The most interesting thing was that most people if you'd have asked them before would have gone "I don't think you can turn this into an experiment" and then immediately adopted a different strategy. Somehow they always figured out a creative way of injecting a low cost experiment where most people would have imagined that it wasnt feasible to run any experiment at all. It required quite a lot of pressure/leadership from above.
Concrete examples sound interesting here in so far as you’re able to share
One example was when they decided to test out the idea of sending particular kinds of price change notification emails to users. They created one checkbox on a form our users could click and set up a trigger to fire notify somebody in the Philippines who would construct the emails manually from the database. They then iterated on those emails, creating them manually the whole time.
Once the email was iterated upon and the idea was proven (i.e. that users actually wanted it in the form that existed), it was handed back to me to automate properly, which in that case took about 7-10 days of dev work.
Or not, if it turned out the customers simply weren't interested. There were plenty of experiments like that where I created a checkbox or something and then we quietly removed it 2 weeks later.
It was a refreshing change from past jobs where I'd spent weeks working on a feature asked for by users that we were so sure would be a game changer only to see 1 or 2 people actually use it.
Once the email was iterated upon and the idea was proven (i.e. that users actually wanted it in the form that existed), it was handed back to me to automate properly, which in that case took about 7-10 days of dev work.
Or not, if it turned out the customers simply weren't interested. There were plenty of experiments like that where I created a checkbox or something and then we quietly removed it 2 weeks later.
It was a refreshing change from past jobs where I'd spent weeks working on a feature asked for by users that we were so sure would be a game changer only to see 1 or 2 people actually use it.
It's the same advice as building an MVP, do everything manually first, then automate once you've proven the market, basically Paul Graham's advice of doing things that don't scale. The Doordash founders hand-delivered food first before building an app.
Obviously, that does not apply if the market already exists, which it usually does. In that case you have to be different and better enough than the alternatives.
Why doesn't it apply? Even if there were a lot of food delivery companies, it would still be good to gain traction through doing it manually instead of (or before) spending months building out a software solution. Even better, because one would personally deliver the food, they can talk to customers and ask what problems they have currently with other food delivery competitors, thereby learning what differentiating advantage would work well when creating the software solution.
In other words, doing things that don't scale is not just useful for validating the market, it's arguably even more useful for validating one's specific implementation of a product, and also derisking the business model as a whole rather than having high capex initially.
In other words, doing things that don't scale is not just useful for validating the market, it's arguably even more useful for validating one's specific implementation of a product, and also derisking the business model as a whole rather than having high capex initially.
If you're building in an established category, you should bring product intuition, honed by deep knowledge of the existing products, and confirmation of their weaknesses from their users. You are not going to win by rapidly cornering the market ("blitzscaling") because it's already cornered. You want to disrupt it with something better and different. I think the focus on "things that don't scale" takes away from this more important requirement.
Of course, you should try to validate assumptions as quickly and cheaply as possible. If "doing things that don't scale" means temporarily not automating things involved in validating assumptions, then fine. But don't manually do things that are not part of that calculus.
Of course, you should try to validate assumptions as quickly and cheaply as possible. If "doing things that don't scale" means temporarily not automating things involved in validating assumptions, then fine. But don't manually do things that are not part of that calculus.
thanks! Seems very pragmatic. It seems the secret ingredient is having a responsive userbase big enough to have statistical significance though. Something we've struggled with in a recent startup.
Would love to hear the examples and how they were turned into experiments.
It's a good old XY problem. Funnily I've heard customers that doesn't wanna bother getting asked why, they just want someone who do what they're told. Some junior engineers too, just wants the answer of what is asked instead of "the real problem".
The XY problem is poorly-framed.
First of all, it's often a false dichotomy: you can answer the X directly and dig deeper to find Y.
Second, it places the questioner in a "normal" bucket: surely they must have the same boring mundane needs as everyone else, and we just need to figure out which one it is (Y). But some people really are working on something interesting, and need to understand X to do so.
Thirdly, even if Y really is better for them, they still might benefit from an answer to X to avoid asking future variations of X.
First of all, it's often a false dichotomy: you can answer the X directly and dig deeper to find Y.
Second, it places the questioner in a "normal" bucket: surely they must have the same boring mundane needs as everyone else, and we just need to figure out which one it is (Y). But some people really are working on something interesting, and need to understand X to do so.
Thirdly, even if Y really is better for them, they still might benefit from an answer to X to avoid asking future variations of X.
> They ask me WHY I want the alternator replaced. I tell them my vehicle isn't running and I need it to transport me from A to B. They then start asking me questions. Turns out it was the solenoid, they replace it, my vehicle successfully transports me from A to B
An XY problem[0] about A-B!
[0] https://en.m.wikipedia.org/wiki/XY_problem
An XY problem[0] about A-B!
[0] https://en.m.wikipedia.org/wiki/XY_problem
Thank you for this link! I finally understand why one of my former coworkers' answers always frustrated me as much as they did.
I would always ask my Slack questions in XY format, but lead with the actual question, followed by a full paragraph explaining exactly why I believed X to be the solution for Y, and what other letters I had tried before concluding that X was the next likeliest solution for Y.
Something in her brain was programmed to see an XY question and immediately assume the asker was wrong about X. Not once did she read the following paragraph. I would have to reiterate it sentence by sentence as she asked as many "what abouts" to try to challenge my X as I had sentences in the paragraph. It drove me BONKERS.
But I never understood how there was such a disconnect between my frustration and how much customers actually apparently liked dealing with her. Her default approach to XY questions was probably very effective with people who actually did not know the product in-depth, but was profoundly aggravating to those of us whose job it was to be familiar with all the other letters, who really, truly only wanted the answer about X and did not need someone to rethink our entire process.
I would always ask my Slack questions in XY format, but lead with the actual question, followed by a full paragraph explaining exactly why I believed X to be the solution for Y, and what other letters I had tried before concluding that X was the next likeliest solution for Y.
Something in her brain was programmed to see an XY question and immediately assume the asker was wrong about X. Not once did she read the following paragraph. I would have to reiterate it sentence by sentence as she asked as many "what abouts" to try to challenge my X as I had sentences in the paragraph. It drove me BONKERS.
But I never understood how there was such a disconnect between my frustration and how much customers actually apparently liked dealing with her. Her default approach to XY questions was probably very effective with people who actually did not know the product in-depth, but was profoundly aggravating to those of us whose job it was to be familiar with all the other letters, who really, truly only wanted the answer about X and did not need someone to rethink our entire process.
I have such little patience for that kind of person. In slack (well mattermost, but it's essentially the same thing) you can copy the direct link to a message and it'll re-embed it if you link to it in a subsequent message. I'll do that if someone is asking questions I just answered, because really what's the point of a conversation if you're ignoring my half of it.
I started so many replies with, "As I mentioned," that I needed a keyboard shortcut for it.
I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing.
Most of the PMs come from non-tech background, more project-management types, and it shows.
Most of the PMs come from non-tech background, more project-management types, and it shows.
The challenge here can be often that even though the client doesn't really need it, they are convinced they do. Even after digging deeper you understand there are other issues, for instance marketing or sales, that might not even be related to your software.
But if they are a key client you might end up building it, understanding it won't solve their core issues but doing so in order to keep them happy
But if they are a key client you might end up building it, understanding it won't solve their core issues but doing so in order to keep them happy
That happens, then you need to figure out how to handle them. Sometimes when you show them what they really need 'the light goes on' and they don't care about what they asked for anymore (or worse someone else shows it to them and they don't buy from you at all despite your customer focus). Other times they remain convinced they need that thing and so you need to gike it to them lest they buy from someone else).
this it a hard problem to figure out, good luck.
this it a hard problem to figure out, good luck.
This is one reason why it's better to have lots of small clients than a few big clients, because over time, the few big ones will increasingly dictate your product strategy in ways you will not want to go. Jason Fried from Basecamp has a good article about this [0].
[0] https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL)
[0] https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL)
It's hard for me to say this without wondering if I am being rude, but did you mean to say "dig down"? At least to me, "to dig in" means to prepare for a long-drawn confrontation (like an argument or a battle). Maybe I am wrong, but my brain just wouldn't let me go on to the next comment without pointing it out.
> The classic example of selling cars when they were invented is that all customers ever asked for was faster horses.
I look at the Segway as a counter example. Maybe people really did just want a faster way to walk through a city. No offense to Dean Kamen —- he has a very impressive set of accomplishments.
I fully support performing user studies to better understand the problem domain and the feature space. I think your bullet points illustrate some of the challenges in finding the right balance. Unfortunately, I’ve run into way more Segway builders than I have car inventors. They build something based on founder intuition or just bad user studies and then glibly dismiss customer requests as calls for faster horses. I lack the time, energy, and desire to adapt to whatever custom workflow is added because I supposedly don’t know my domain well enough to know what I want.
There’s probably a B2C and B2B split in there, but I’ve never seen that distinction made in application of some of this advice. I know you aren’t advocating for the outright dismissal of user feedback, but I’ve seen that interpretation time and time again. I’d love for us to get a new metaphor or apocryphal story.
I look at the Segway as a counter example. Maybe people really did just want a faster way to walk through a city. No offense to Dean Kamen —- he has a very impressive set of accomplishments.
I fully support performing user studies to better understand the problem domain and the feature space. I think your bullet points illustrate some of the challenges in finding the right balance. Unfortunately, I’ve run into way more Segway builders than I have car inventors. They build something based on founder intuition or just bad user studies and then glibly dismiss customer requests as calls for faster horses. I lack the time, energy, and desire to adapt to whatever custom workflow is added because I supposedly don’t know my domain well enough to know what I want.
There’s probably a B2C and B2B split in there, but I’ve never seen that distinction made in application of some of this advice. I know you aren’t advocating for the outright dismissal of user feedback, but I’ve seen that interpretation time and time again. I’d love for us to get a new metaphor or apocryphal story.
People obviously wanted a Segway, they just didn't want it at that price point.
People even obviously wanted a Segway in Europe, where the cities have impressive support for bikes.
If People hadn't wanted a Segway (but way cheaper) we wouldn't have the streets littered with cheap electric scooters everywhere you go.
People even obviously wanted a Segway in Europe, where the cities have impressive support for bikes.
If People hadn't wanted a Segway (but way cheaper) we wouldn't have the streets littered with cheap electric scooters everywhere you go.
I don’t see how it’s obvious people wanted a Segway. Cost is one problem. They’re also large, making them difficult to store at either end of a destination. They’re a nuisance and safety risk for pedestrians. Riders kept toppling them. They’re an even bigger problem than scooters when the battery dies mid-journey. I’ll grant some people were really enthusiastic about them, but I don’t see that translating into mass market appeal.
Even if I’m dead wrong and there’s a throng of people just waiting for a Segway fire sale, it doesn’t invalidate my point. If your product solves the problem by ignoring the economics of your target customer base that’s just as problematic as building the wrong product.
Electric scooters have seen a lot more traction. Both teams can’t use the supposed Henry Ford quote to say the customer doesn’t know what they want. Or, rather they can, but that doesn’t mean they have any more of a clue than the customer does.
My point is maybe we should stop being so antagonistic to the customer. You’ll find no shortage of instances where the customer is wrong. But there’s plenty of others where the customer is right and the product team is wrong. I’m tired of dealing with products that think they know better than me because they think they’re inventing cars.
Even if I’m dead wrong and there’s a throng of people just waiting for a Segway fire sale, it doesn’t invalidate my point. If your product solves the problem by ignoring the economics of your target customer base that’s just as problematic as building the wrong product.
Electric scooters have seen a lot more traction. Both teams can’t use the supposed Henry Ford quote to say the customer doesn’t know what they want. Or, rather they can, but that doesn’t mean they have any more of a clue than the customer does.
My point is maybe we should stop being so antagonistic to the customer. You’ll find no shortage of instances where the customer is wrong. But there’s plenty of others where the customer is right and the product team is wrong. I’m tired of dealing with products that think they know better than me because they think they’re inventing cars.
> I don’t see how it’s obvious people wanted a Segway.
I assume what bryanrasmussen means is: Any city-dweller will see electric scooters, electric unicycles, 'hoverboards' and e-bikes from time to time.
So the makers of the Segway were correct in identifying a demand for an urban transit option other than walking, bicycles, cars, mobility scooters and public transit. They were correct in making it electric, about the speed of a fast leisure cyclist, with a range a little above 10 miles, and operated from a standing position.
However, they were incorrect about the price and size. Segways were 10x too expensive (even ignoring inflation) and at 100lbs+ were too large and heavy to carry inside or on public transit.
I assume what bryanrasmussen means is: Any city-dweller will see electric scooters, electric unicycles, 'hoverboards' and e-bikes from time to time.
So the makers of the Segway were correct in identifying a demand for an urban transit option other than walking, bicycles, cars, mobility scooters and public transit. They were correct in making it electric, about the speed of a fast leisure cyclist, with a range a little above 10 miles, and operated from a standing position.
However, they were incorrect about the price and size. Segways were 10x too expensive (even ignoring inflation) and at 100lbs+ were too large and heavy to carry inside or on public transit.
> My point is maybe we should stop being so antagonistic to the customer.
I don't see anyone being antagonistic. The attitude you are thinking of antagonism to me is more like: we're treating them like all other humans, namely lacking good articulation skills and rarely going in deeply analyzing what is that they truly want.
And it's not about customers being "right" or "wrong". It's about making a sale. And many customers will not give you several chances.
Hence, the strategy of "do your absolute very best to figure what they really need even if that means not immediately accepting what they say they want as the truth" is optimizing for the very limited amount of tries to get it right.
It's quite logical IMO and there's nothing antagonistic or demeaning in this process.
I don't see anyone being antagonistic. The attitude you are thinking of antagonism to me is more like: we're treating them like all other humans, namely lacking good articulation skills and rarely going in deeply analyzing what is that they truly want.
And it's not about customers being "right" or "wrong". It's about making a sale. And many customers will not give you several chances.
Hence, the strategy of "do your absolute very best to figure what they really need even if that means not immediately accepting what they say they want as the truth" is optimizing for the very limited amount of tries to get it right.
It's quite logical IMO and there's nothing antagonistic or demeaning in this process.
> Electric scooters have seen a lot more traction
Style is a big factor. Segway riders look awkward. Scooters—with the feet placed in front of each other—streamline the body and look more natural.
Style is a big factor. Segway riders look awkward. Scooters—with the feet placed in front of each other—streamline the body and look more natural.
How in gods name did we get Segways 20 years before kids could grab a simple electric scooter?
Somebody invested a lot of time and money with an incredibly single-minded focus.
> People even obviously wanted a Segway in Europe, where the cities have impressive support for bikes.
Maybe impressive by US standards but don’t underestimate us, we managed to transform perfectly walkable / cyclable cities and dense rail networks into car centric cities and highways everywhere in less than a century.
Maybe impressive by US standards but don’t underestimate us, we managed to transform perfectly walkable / cyclable cities and dense rail networks into car centric cities and highways everywhere in less than a century.
It wasn't just the price point, it was the bulk/footprint of the thing being fairly non-pedestrian friendly and difficult to transport/store. Scooters are a massive improvement in that regard.
it's pretty common that the first iteration of a piece of hardware is big.
Of course, but the problem is the lack of adoption didn't really push it to become smaller or substantially cheaper and more accessible. A modern Segway has a similar footprint.
In fact I’d even say that people didn’t need cars but that cars created so much opportunities of extending human cities that once we got there, we made ourselves dependent of cars.
And in retrospection, it was hardly a good direction to take for our future.
So, well, it seems plausible that what people really needed was just better bikes and trains but that they all bought into the car "freedom" marketing.
And in retrospection, it was hardly a good direction to take for our future.
So, well, it seems plausible that what people really needed was just better bikes and trains but that they all bought into the car "freedom" marketing.
It's not just marketing though. Cars do provide a level of freedom not given by other forms of transport. I say this as someone who started to drive relatively late in life, it completely changes what options are open to you on the weekend for example.
Ok, let's go back and change things as a thought experiment. How could this have played out differently (in America).
Are you suggesting that America could be as large and diverse as it is now just using bikes and trains?
Are you also suggesting most of the 230 million US drivers would prefer this as a better solution?
Are you suggesting that America could be as large and diverse as it is now just using bikes and trains?
Are you also suggesting most of the 230 million US drivers would prefer this as a better solution?
> just using bikes and trains
Some times it looks like nobody even know street-cars existed anymore.
Some times it looks like nobody even know street-cars existed anymore.
I completely agree with you. Sadly though, we inhabit a reality where the first semi-solution to a problem wins. That something is pervasive is IMO 95% of the time about whether it was first to market -- not if it was solving the problem perfectly.
Cars and many internet protocols (and software) are a perfect demonstration of this tendency.
Cars and many internet protocols (and software) are a perfect demonstration of this tendency.
I sometimes sum this up as:
Don‘t listen to your customer. Watch your customer.
Obviously needs to be taken with a grain of salt, but seeing how users behave is often more insightful than asking them what they want. You just need to setup the environment for watching in a way that you learn what you want to learn.
Obviously needs to be taken with a grain of salt, but seeing how users behave is often more insightful than asking them what they want. You just need to setup the environment for watching in a way that you learn what you want to learn.
We worked on a large overhaul of the customer support system for Big Grocery Store a couple years ago, and the PMs and designers spent a lot of time sitting down with the users and watching them walk through their current flow. They observed, asked about pain points, and then iterated on designs that the users could actually interact with. They had about 70% of the functionality fleshed out before we ever started implementation, which felt really good. We still hit plenty of roadblocks and gaps, but it felt much better in terms of understanding what the users actually needed
Great point. We have a customer who uses our tool in a sensitive environment - I'm not even allowed to watch them use it. This is mind bogglingly frustrating as I can only go by what they say, whereas half an hour actually seeing what they do with it would progress the tool and our relationship in leaps and bounds.
Can't you set up a test environment with fake data, and ask them to simulate their work there?
It's less than ideal, but it would allow youto see and understand their workflows
It's less than ideal, but it would allow youto see and understand their workflows
I often join the daily standup meeting of the support and deployment team so I can 'watch' them and it has been really valuable. Sometimes giving them tips & tricks, sometimes just listening to newcomers questions to learn what is not simple enough, learning some awful workaround they come up with instead of asking/opening a ticket, and also learning their bad habits.
Absolutely and I would also add: passively monitor and listen to them. What are they complaining or asking about in communities/social media? What are they talking about in conferences and industry events?
Another great example is video games.
Gamers will come up with all sorts of ideas that sound cool but have nothing fun to them except the initial novelty, particularly when it comes to simulation style games (eg "I should be able to walk around my spaceship and be able to do spacewalks to patch up the hull after micrometeorite impacts").
But on the other hand it is also very common for companies/developers to take this too far and blame the players for being wrong in not enjoying their game.
Gamers will come up with all sorts of ideas that sound cool but have nothing fun to them except the initial novelty, particularly when it comes to simulation style games (eg "I should be able to walk around my spaceship and be able to do spacewalks to patch up the hull after micrometeorite impacts").
But on the other hand it is also very common for companies/developers to take this too far and blame the players for being wrong in not enjoying their game.
"assuming that what your sales people say the customer wants is actually what they want or need. This one is tricky. I've had sales people go "unless you build X, I can't close the deal" and then you build X and it doesn't make a difference. Reason: the sales person's analysis was wrong."
this is SUPER common, and very hard for organization to counter. As salespeople usually interact the most with users, PMs tend to just do what they say.
this is SUPER common, and very hard for organization to counter. As salespeople usually interact the most with users, PMs tend to just do what they say.
I saw a head of sales literally kill a business by endlessly doing this, when in reality he was deflecting from his own lack of ability. There was always a clearly articulated reason why it was someone else's issue that he wasn't closing deals, and by the time that issue was fixed as a company emergency he had come up with two or three new ones.
This is a very common story. Unfortunately the incentives and general historical inertia around sales as a role don't always gel with the long term picture.
It's a very human story, but it's one I've had to try to put preventative structures around for my whole career.
The default, "your job is just to sell and your reward structures reflect that" creates an environment where the easiest path is to over-promise. Hence when that sales role sits too high in the org structure you naturally end up in the endless sell what you don't have -> scramble, sell -> scramble cycle.
It seems very obvious that the best salesman would sell the lowest number of features for the highest price, but the incentives are typically based on the top line figure instead which is nice for cash flow but not for profitability.
So far I've managed to solve it somewhat by building internal barriers, but they take constant maintenance.
I'm sure the better solution is to lean the incentives towards profitability but the implications are complex.
It's a very human story, but it's one I've had to try to put preventative structures around for my whole career.
The default, "your job is just to sell and your reward structures reflect that" creates an environment where the easiest path is to over-promise. Hence when that sales role sits too high in the org structure you naturally end up in the endless sell what you don't have -> scramble, sell -> scramble cycle.
It seems very obvious that the best salesman would sell the lowest number of features for the highest price, but the incentives are typically based on the top line figure instead which is nice for cash flow but not for profitability.
So far I've managed to solve it somewhat by building internal barriers, but they take constant maintenance.
I'm sure the better solution is to lean the incentives towards profitability but the implications are complex.
A land and expand strategy could maybe help mitigate it, what do you think? Keep the focus on small deals constantly closing, and then follow up to upsell them. Separate spiffs for each part of the sales motion.
On the SaaS side, yeah I think that's a good move.
In this case there's a large hardware component of the sale which incentivises the software over-promising. There's also a lot of competition (think a tender process).
It's really about shifting the small decisions, removing that marginal "yes, we can do that" which didn't need to be there at all for the sale to close.
In this case there's a large hardware component of the sale which incentivises the software over-promising. There's also a lot of competition (think a tender process).
It's really about shifting the small decisions, removing that marginal "yes, we can do that" which didn't need to be there at all for the sale to close.
You could have engineering estimate the cost of the new feature to deduct from the profit?
It's particularly common with big whale enterprise clients, where the salesperson is trying to close a very long sales process or the client has you by the short hairs in the contract. I remember one case where we had to implement a very complex and time-consuming custom SAML integration to a platform where we just had one client asking for it, because that client was too big to ignore. Once we integrated SAML, the number of end users actually using the SAML login option was in the single digits. It was just a checklist item for some purchasing officer flunky.
For SAML in particular I can definitely relate here. I will say though, that for SaaS products that you want large companies to use, you owe it to yourself to have an auth layer that is immensely flexible and pluggable. Auth is a huge mess and large companies nearly all have single-sign-on solutions, sometimes strange bespoke ones, and so you gotta expect to potentially build a zillion different auth integrations if you want to sell to large companies.
Sure, but if you are planning to go from SME to enterprise you need to think strategically for the long term. You'll probably need to have more developers to deal with the complexities and hand-holding you've touched on (auth is just one of the issues and not even the most complex) and probably non-technical roles for all the compliance and so on.
The danger of landing just one or two "whales" is that you bend your product backwards for these clients, but without thinking through the TCO it can cost you more in the long run and put your business in more jeopardy than when you rely on a few hundred SMEs.
The danger of landing just one or two "whales" is that you bend your product backwards for these clients, but without thinking through the TCO it can cost you more in the long run and put your business in more jeopardy than when you rely on a few hundred SMEs.
This is exactly why we built WorkOS. Check it out if you’re looking for SAML/SCIM for your app. (I’m the founder.)
https://workos.com/single-sign-on
https://workos.com/single-sign-on
The fact that no one used it doesn't mean that building it was a mistake. Maybe the purchase officer got it wrong, but the salesperson who requested it be built got it right, since the deal did in fact depends on it.
Perhaps. But then it's important to look at the total cost of ownership: was it worth building a complex feature for one client that adds to the technical debt of a code base and tied up developer resources that could have been better employed elsewhere? Could we have pushed back on this feature or was it really a deal-breaker?
In other words, perhaps landing this one client was important to that salesperson, and perhaps in the short term to the company, but in the long term it may have been better to have lost that one deal. Very often these decisions are made with little calculus about the TCO.
In other words, perhaps landing this one client was important to that salesperson, and perhaps in the short term to the company, but in the long term it may have been better to have lost that one deal. Very often these decisions are made with little calculus about the TCO.
> Reason: the sales person's analysis was wrong.
On the other hand, great sales people have a knack for understanding what customers really want, as well as non-technical obstacles to selling like procurement policies or management hierarchy. You ignore them at your peril.
On the other hand, great sales people have a knack for understanding what customers really want, as well as non-technical obstacles to selling like procurement policies or management hierarchy. You ignore them at your peril.
Also keep in mind that there are products out there were the real customer isn't the user, so giving users what they want is secondary to building the features that matter to the revenue stream. Obviously the major social media are guilty of this, but so are retail websites and airline booking apps. They may even employ dark patterns, which are clearly not in the users interests, and aren't even necessarily desired by the paying customers.
[deleted]
Majority of B2B SaaS too. It's the only reason SAP is what it is
Absolutely. The folks who make the decisions to buy aren't the ones that have to use it.
You know what literally no one asked for though? A faster horse controlled by a touchscreen, or a horse which spies on you to show you ads, or changes its crappy electron UI every 5 days thanks to corporate branding follies.
Yes those touchscreens in cars are just ridiculous distractions and should probably be limited in their use by legislation.
Instead we basically got legislation requiring their presence. At any rate, backup cameras are required now and probably no one is going to let all that screen space go unused when not backing.
Yeah, it's amazing how much this whole thread explains why modern software and tech products are such garbage which doesn't do anything that users want.
If I reuse the crappy car analogy from above: modern software engineers and product managers will look at your broken alternator and tell you that you need a new LCD screen on dashboard while gaslighting you that alternator isn't actually something that needs to work in a car. Despite you really needing it for the damn thing to run.
If I reuse the crappy car analogy from above: modern software engineers and product managers will look at your broken alternator and tell you that you need a new LCD screen on dashboard while gaslighting you that alternator isn't actually something that needs to work in a car. Despite you really needing it for the damn thing to run.
Salespeople are often weak and wrong. I was top 0.3% nationwide and my claim to fame was honing in on deals that I could tell were deals and finishing them. Most salespeople are either oblivious or too hopeful and will make you and spin your wheels with false hope. It's not that a salesperson that talks to users and buyers is worthless. But if you can't tell if your salesperson themselves isn't spectacular, but instead just average, you're going to have trouble.
> I've had sales people go "unless you build X, I can't close the deal"
For the benefit of younger devs, I'd like to add that this is a rookie sales mistake that indicates lack of software sales experience.
For the benefit of younger devs, I'd like to add that this is a rookie sales mistake that indicates lack of software sales experience.
Definitely not a rookie mistake but quite common. Especially if a competitor has X. Then it's up to sales to convince the client they don't need X, which makes it an even tougher proposition than if they just asked for X in a vacuum
Can you expand on this a bit, or recommend an article that does?
"unless you build X, I can't close the deal"
There are things where this is true, compliance, SSO, enterprise integrations.
But most of the time this signals the product has no USP and it also signals that you should get rid of your sales staff.
There are things where this is true, compliance, SSO, enterprise integrations.
But most of the time this signals the product has no USP and it also signals that you should get rid of your sales staff.
What's USP?
As mentioned in the other reply, "unique selling point" - something that makes your customers want to buy your product. If you take it away, customers won't buy.
Instead of working on their USP too many startups through everything at the wall and see what sticks, b/c they don't know why their customers buy or should buy their product.
Similiar, but not the same, is vision driven product development vs. checklist driven development.
Instead of working on their USP too many startups through everything at the wall and see what sticks, b/c they don't know why their customers buy or should buy their product.
Similiar, but not the same, is vision driven product development vs. checklist driven development.
As mentioned in the other reply, "unique selling point" - something that makes your customers want to buy your product. If you take it away, customers won't buy.
The "faster horses" comment is universally attributed to Henry Ford, but it appears he didn't actually say it. Here's an article that shows the results of researching the source, and has some interesting observations about Ford's innovations and the blinders that early success can cause.
https://hbr.org/2011/08/henry-ford-never-said-the-fast
https://hbr.org/2011/08/henry-ford-never-said-the-fast
> 2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs.
> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.
If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.
I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.
> You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.
If you have to build first in order to pitch and show it, then necessarily you've had to assume that what you were building is something they want. Maybe your point was to get new features quickly into the hands of users to test the assumption early, but that has its own significant downsides.
I like the way you phrased it though, in terms of "don't assume foo" instead of "do bar", because it implies that there's really no replacing good old-fashioned _thinking_ with blindly following a 5-step plan to success.
It argues for validating your assumptions as quick as you can. Which is why mvps, prototypes, and click demos can be a good thing. It doesn't always work though. Digging in and burning through a few million of investor money before your product encounters real users, is the expensive way to do it.
A good solution to #4 is to get the commitment in writing first. In the sales contract, say they will pay X upfront you will build F by Y date.
This solves many problems. Customer can’t back out. Gives sales person clear next steps. Clearly defines feature details and deadline.
Just make sure you set deadlines you can definitely hit.
This solves many problems. Customer can’t back out. Gives sales person clear next steps. Clearly defines feature details and deadline.
Just make sure you set deadlines you can definitely hit.
This problem often comes up and always ends with "it's an art" or some outright wrong or ymmv conclusions with a heady mix of variations on ford's faster horses metaphor.
One effective way to "get" the product is to be a real user. Not just pretend as one but to actually use the product.
This gives you a concrete foundation in one usecase. You can then branch out to other usecases by asking and observing others.
It's not as easy or sexy as collecting user data and plotting fancy graphs. And it's very very hard to justify time spent on this to your manager if they don't understand this inherently.
But it's very hard to fool yourself as a user of your own product.
One effective way to "get" the product is to be a real user. Not just pretend as one but to actually use the product.
This gives you a concrete foundation in one usecase. You can then branch out to other usecases by asking and observing others.
It's not as easy or sexy as collecting user data and plotting fancy graphs. And it's very very hard to justify time spent on this to your manager if they don't understand this inherently.
But it's very hard to fool yourself as a user of your own product.
I suppose the trick is knowing when to trust their judgement. The customer isn't always wrong, and often has a lot of context you'll never fully understand.
"Show me why you need this" can sometimes help, but not always.
"Show me why you need this" can sometimes help, but not always.
[deleted]
I will add one more case that's often overlooked:
5) assuming they are willing to pay what they want/need
5) assuming they are willing to pay what they want/need
1 and 3 is the same, if 4 then add 5) assume what devs say is actually what they want or need
They are similar but there's a difference between a customer explicitly asking for something / demanding it, and soliciting feedback.
tHE classic mistake is not asking the right person within the customer's corporate hierarchy.
Product Management should be about making it more efficient for end-users, low-tiered workers, and not the purchase manager nor even CTO.
Product Management should be about making it more efficient for end-users, low-tiered workers, and not the purchase manager nor even CTO.
Most people didn't want faster horses, they didn't even have slow horses.
What they wanted was time off and something to do with it.
What they wanted was time off and something to do with it.
Most potential customers then.
I don't understand.
Ford's introduced the 5-day work week (reduced from 6), and the "Five-Dollar Day" and reduced work days from 9 hours to 8.
No-one talked about horses.
Ford's introduced the 5-day work week (reduced from 6), and the "Five-Dollar Day" and reduced work days from 9 hours to 8.
No-one talked about horses.
The notion of a work week presumes the existence of work, which is enabled by a product for Ford to sell: cars. How they manage the company, and what benefits they confer to employees is a separate question.
I still don't understand what point you are trying to make, or how it relates to product development.
I'm saying you're mixing up the subject. We're talking about what people want in the context of product development, you are not. The work week has nothing to do with product.
Instead of faster horses, Ford's mass production process was the product. All those workplace changes were to expand the pie.
I do a lot of email support, and I find lots of examples of the XY problem masquerading as a feature request. [1]
Someone will ask for some feature - and usually its easy to add - but I try and understand the root problem first. Mostly they don't tell me the problem, they tell me their solution. This is often either a bad approach or a flat-out wrong approach. Implementing it "as asked" doesn't help.
The only way for me to add a feature elegantly, and to documentation in a way that will be useful to others, I to understand the root pain it is fixing.
This also makes it easier to sell. "Identify the pain. Make it go away" is a powerful sales technique.
Lastly, sometimes the pain is internal - the Sales team need it fixed, not the customer. Some features get added because -decision makers- think its important, and it demos well, although we know full well that customers will never actually use it.
[1] https://en.m.wikipedia.org/wiki/XY_problem
Someone will ask for some feature - and usually its easy to add - but I try and understand the root problem first. Mostly they don't tell me the problem, they tell me their solution. This is often either a bad approach or a flat-out wrong approach. Implementing it "as asked" doesn't help.
The only way for me to add a feature elegantly, and to documentation in a way that will be useful to others, I to understand the root pain it is fixing.
This also makes it easier to sell. "Identify the pain. Make it go away" is a powerful sales technique.
Lastly, sometimes the pain is internal - the Sales team need it fixed, not the customer. Some features get added because -decision makers- think its important, and it demos well, although we know full well that customers will never actually use it.
[1] https://en.m.wikipedia.org/wiki/XY_problem
There's also stuff that comes from inside organizations, and sometimes the business can't even say why they want something, other than "it checks a box we think we should check". Especially true when replacing legacy software, there's always pressure to port over cruft even when there's high confidence that it's not used any more and costs more to build than it's worth. Some business people just can't let go of, for example, generating reports that no one ever actually reads.
I like the article, HATE the title.
You should ask your customers lots of stuff, and take VERY LITTLE at face value.
Implementing features that customers ask for is a sure path to ruin; you have to keep asking questions and digging in beyond just "I want it to do X."
To be fair, that is basically what the article says, I'm just very tired of the cliched title.
Also, I second the recommendation for Christensen and Deming, and I will add Sidney Dekker, primarily "Field Guide to Human Error" but I'm sure the other books are also very good.
You should ask your customers lots of stuff, and take VERY LITTLE at face value.
Implementing features that customers ask for is a sure path to ruin; you have to keep asking questions and digging in beyond just "I want it to do X."
To be fair, that is basically what the article says, I'm just very tired of the cliched title.
Also, I second the recommendation for Christensen and Deming, and I will add Sidney Dekker, primarily "Field Guide to Human Error" but I'm sure the other books are also very good.
You should ask your customers lots of stuff, and take VERY LITTLE at face value.
Exactly. But a time when you can take it at face value is when the question is something along of the lines of "will you sign a purchase order for this right now?" or the like.
And to tie back to what someone in another post here said about validation: one of the best way to validate that your solution is real, and will actually sell to the customer (which is the only thing that matters, from a certain point of view) is exactly to ask your customer "will you buy this, right now?" or a close variant. If the answer is "yes, send the bill and get the order underway" then you've validated something. If you get hemming and hawing and "well, maybe, let me talk to the purchasing committee" or whatever, you're still just thrashing around.
And even if you don't go for the actual sale yet (maybe the product isn't ready yet) you can take the approach Steve Blank[1] talks about, and work up to a questions of the form "would you pay a million dollars for this right now" and "well, how much would you pay for it then?" and "if I offered this to you FOR FREE right now, would you start rolling it out immediately" etc. Those answers will really tell you something about where you really stand in your customer's eyes vis-à-vis actually selling your thing.
[1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
Exactly. But a time when you can take it at face value is when the question is something along of the lines of "will you sign a purchase order for this right now?" or the like.
And to tie back to what someone in another post here said about validation: one of the best way to validate that your solution is real, and will actually sell to the customer (which is the only thing that matters, from a certain point of view) is exactly to ask your customer "will you buy this, right now?" or a close variant. If the answer is "yes, send the bill and get the order underway" then you've validated something. If you get hemming and hawing and "well, maybe, let me talk to the purchasing committee" or whatever, you're still just thrashing around.
And even if you don't go for the actual sale yet (maybe the product isn't ready yet) you can take the approach Steve Blank[1] talks about, and work up to a questions of the form "would you pay a million dollars for this right now" and "well, how much would you pay for it then?" and "if I offered this to you FOR FREE right now, would you start rolling it out immediately" etc. Those answers will really tell you something about where you really stand in your customer's eyes vis-à-vis actually selling your thing.
[1]: https://www.amazon.com/Four-Steps-Epiphany-Steve-Blank/dp/09...
Even the purehase order isn't always enough. If the cost of developing that feature, inclueding long term maintenaece is less than they are willing to pay fine. However often they are buying from you to share costs wiht your other customers, and what they want is you to split the costs.
Listen to customers. Learn their business. Help their business be better. There is a difference in asking and doing what they want vs listening and synthesizing.
Thanks for the recommendation for Dekker, added it to my list!
Honestly, I'm not super with the title too :) It's hard to find something that's eye-catching but honest to the truth. What would you choose?
Honestly, I'm not super with the title too :) It's hard to find something that's eye-catching but honest to the truth. What would you choose?
As sibling comment states, the title is pretty good clickbait (not an insult). The problem is, the people you're trying to reach are clickbait connoisseurs. You need to hit another level of interest.
"What to do after just asking the customer fails"
"Why I didn't implement your excellent feature request"
"What to do after just asking the customer fails"
"Why I didn't implement your excellent feature request"
"Thinking like a customer."
But your title will probably get more clicks.
But your title will probably get more clicks.
From experience customers never know what they want.
There is a reason you, as an entrepreneur, are passionate about building something that’s hopefully better at solving the problem.
I really hate the advice of don’t build something before validating. That has literally never worked for me. That’s like asking a leading question and shooting yourself in the foot at the same time.
You should have some conviction why you’re doing something. Don’t one of those people who tries to do something in an industry they have zero clue about (99% chance of failure). If you know what you’re doing you should have a 60% plus chance of success.
It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
There is a reason you, as an entrepreneur, are passionate about building something that’s hopefully better at solving the problem.
I really hate the advice of don’t build something before validating. That has literally never worked for me. That’s like asking a leading question and shooting yourself in the foot at the same time.
You should have some conviction why you’re doing something. Don’t one of those people who tries to do something in an industry they have zero clue about (99% chance of failure). If you know what you’re doing you should have a 60% plus chance of success.
It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
> don’t build something before validating
It depends on what counts as validation. To me, it's the presence of the problem, and how many people are looking for some solution. This is why, I think, many validation-first sites are intentionally vague when describing the solution.
It depends on what counts as validation. To me, it's the presence of the problem, and how many people are looking for some solution. This is why, I think, many validation-first sites are intentionally vague when describing the solution.
To me, it's the presence of the problem, and how many people are looking for some solution.
I love how Steve Blank talks about the ideal situation being when the customer has already cobbled together a solution from an old vacuum cleaner, four dozen zip ties, an Arduino, a stepper motor, and some old coat hangers (or whatever). Why? Isn't it bad when the customer already has a solution? Well maybe sometimes.
But if the underlying problem is a high value problem, the customer has - by cobbling something together - validated A. that the problem exists, and B. that they need a solution.
And if they're smart, they know they don't want to be in the business of maintaining this cobbled together P.O.S. which works 63% of the time, violates half a dozen fire-code regulations, and isn't remotely close to being their core competency. No, they want somebody like you to come along and offer a proper solution and will probably purchase your solution as long as the price is right or you don't blow the sale in some other way.
I love how Steve Blank talks about the ideal situation being when the customer has already cobbled together a solution from an old vacuum cleaner, four dozen zip ties, an Arduino, a stepper motor, and some old coat hangers (or whatever). Why? Isn't it bad when the customer already has a solution? Well maybe sometimes.
But if the underlying problem is a high value problem, the customer has - by cobbling something together - validated A. that the problem exists, and B. that they need a solution.
And if they're smart, they know they don't want to be in the business of maintaining this cobbled together P.O.S. which works 63% of the time, violates half a dozen fire-code regulations, and isn't remotely close to being their core competency. No, they want somebody like you to come along and offer a proper solution and will probably purchase your solution as long as the price is right or you don't blow the sale in some other way.
> I really hate the advice of don’t build something before validating. That has literally never worked for me.
> It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
What am I missing? You did validate it. You were the (prototype) customer, were you not?
> It’s so easy to sell something that people just get at first glance because it’s actually good at solving their problem, because you had faced that same problem and decided to do something about it.
What am I missing? You did validate it. You were the (prototype) customer, were you not?
I meant the part about the 99% failure.
Every failed entrepreneurs I’ve met fit this category. They try to find validation, but it never works out that way. At least from what I have seen.
Every failed entrepreneurs I’ve met fit this category. They try to find validation, but it never works out that way. At least from what I have seen.
He did the validation by building the prototype, not before building the prototype.
He validated the idea to build the prototype by talking to himself, in the role of a customer ("faced that same problem and decided to do something about it").
As opposed to "here's a cool idea I have, let me build it because I'm sure somebody will pay me money for it".
As opposed to "here's a cool idea I have, let me build it because I'm sure somebody will pay me money for it".
The cliché quote of “if Henry Ford has asked people what they wanted, they’d have said a faster horse” is a cliché for a reason. Most people don’t know what they want - that’s why good product designers who can identify, synthesize, and execute products are worth big money.
There are 2 things to differentiate - product vision, and learning how to listen to feedback.
The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc.
The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc.
The two are very different skillsets, and it’s hard enough to be good at one, let alone both.
The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.
There are 2 things to differentiate - product vision, and learning how to listen to feedback.
The former, designing new products that solve people’s problems, is a craft that has no silver bullet. It requires a mix of experience, intuition, technical know how, observing the landscape of existing alternatives, knowing how to anticipate technical/economic/sociological evolutions, etc.
The latter is about making sure that what you designed does what you intend it to, identifying what confuses your users, what gets in their way, etc. This is where all the classical methods of user observation/testing/surveys/etc can be useful. This sounds easy and obvious, but it is anything but - i have met my fair share of designers who stick to their principles and are unwilling to budge when reality conflicts with their ideology, companies that inexplicably never fix bugs that most of their users encounter and rage about on the support forums/social media, etc.
The two are very different skillsets, and it’s hard enough to be good at one, let alone both.
The article uses Intuit as a case study; the dynamics of how to do genuinely great work when your business involves selling an antidote to a poison you lobby for is an exercise left to the reader.
And yet there is still a significant global industry for breeding faster horses. It's much smaller than the auto industry, but still a profitable niche.
But for a completely different customer segment too.
Their model names are outstanding as well.
> Here’s a classic example of trying to give the customers what they want, from Intuit [...]
CUSTOMERS: We just want to minimize the pain of tax return filing.
INTUIT: [lobbies government to keep that pain going strong]
CUSTOMERS: We just want to minimize the pain of tax return filing.
INTUIT: [lobbies government to keep that pain going strong]
Our product's history explores the full depth of this spectrum.
At the beginning, the only thing we were interested in was what our customers (banks) thought about their business and how our product might be able to improve it. We had no clue what we were doing but were accumulating ideas rapidly. We were tripping over ourselves in order to serve the customers' every last idle whim. We felt we were not worthy of their business.
Somewhere in the middle, we gained traction and realized that if we built our product to make 10+ different customers happy in their own unique ways that we would have nothing in the end.
Today, our product is more of a turn-key consulting package than it is any specific software or technology. Our customers look to us for guidance on how to run their businesses now. Once you are driving this kind of bus, you can normalize your software stack with much more confidence. The word "boring" has entered our lexicon recently.
One fun point about our kind of customer - they are very herd-like creatures. Once you get a few of them moving in a certain direction, you can push the rest along for the ride with virtually zero effort. I am beginning to think this isn't just applicable to risk-adverse bankers.
At the beginning, the only thing we were interested in was what our customers (banks) thought about their business and how our product might be able to improve it. We had no clue what we were doing but were accumulating ideas rapidly. We were tripping over ourselves in order to serve the customers' every last idle whim. We felt we were not worthy of their business.
Somewhere in the middle, we gained traction and realized that if we built our product to make 10+ different customers happy in their own unique ways that we would have nothing in the end.
Today, our product is more of a turn-key consulting package than it is any specific software or technology. Our customers look to us for guidance on how to run their businesses now. Once you are driving this kind of bus, you can normalize your software stack with much more confidence. The word "boring" has entered our lexicon recently.
One fun point about our kind of customer - they are very herd-like creatures. Once you get a few of them moving in a certain direction, you can push the rest along for the ride with virtually zero effort. I am beginning to think this isn't just applicable to risk-adverse bankers.
A common pitfall that isn't listed in the article is listening to a loud minority of customers.
If you had been reading Hacker News or any other tech-savvy platform, you'd have been well excused for thinking there's a huge demand for a capable iPhone with a smaller screen.
In reality, the sales numbers for iPhone minis were disappointing. It turns out that people spending a lot of time writing online about tech hardware are not representative of the iPhone customer base at large.
If you had been reading Hacker News or any other tech-savvy platform, you'd have been well excused for thinking there's a huge demand for a capable iPhone with a smaller screen.
In reality, the sales numbers for iPhone minis were disappointing. It turns out that people spending a lot of time writing online about tech hardware are not representative of the iPhone customer base at large.
> In reality, the sales numbers for iPhone minis were disappointing.
Disappointing by whos metric? It outsold most Android phones and massively outsold first few iPhone models released. Were iPhones 3G, 3GS, 4, etc. also disappointing?
Just because the PERCENT was low, it doesn't mean the SHIPPED UNITS were low.
In reality, any company you create will sell their product in VASTLY LOWER number than any iPhone Mini. Should you be fired and go bankrupt because your sales will be disappointing by Apple standards too? Should we just liquidate all companies that cater to less than 20 millions of unit sold? Should all other companies catering to small (< 20 million, the number of small iPhones shipped) audiences not exist and be replaced by average products for average people? No more Mac Studios, no more XDR displays, no more 15" 4000$ MacBooks?
Disappointing by whos metric? It outsold most Android phones and massively outsold first few iPhone models released. Were iPhones 3G, 3GS, 4, etc. also disappointing?
Just because the PERCENT was low, it doesn't mean the SHIPPED UNITS were low.
In reality, any company you create will sell their product in VASTLY LOWER number than any iPhone Mini. Should you be fired and go bankrupt because your sales will be disappointing by Apple standards too? Should we just liquidate all companies that cater to less than 20 millions of unit sold? Should all other companies catering to small (< 20 million, the number of small iPhones shipped) audiences not exist and be replaced by average products for average people? No more Mac Studios, no more XDR displays, no more 15" 4000$ MacBooks?
> Disappointing by whos metric?
By all metrics relevant to Apple's business, as evidenced by the fact that it was discontinued after just two iterations.
By all metrics relevant to Apple's business, as evidenced by the fact that it was discontinued after just two iterations.
> In reality, the sales numbers for iPhone minis were disappointing.
Disappointing for Apple, i.e. only a few tens of millions. I know a few people that are very happy with their iPhone minis. They have nothing to upgrade to now. But it's cheaper this way :)
Disappointing for Apple, i.e. only a few tens of millions. I know a few people that are very happy with their iPhone minis. They have nothing to upgrade to now. But it's cheaper this way :)
Right. I think the point of the article was to determine what's best for your business at large, not what would make a few customers happy at the expense of your overall success.
[deleted]
If people knew how to solve their own problems they wouldn't be giving you their money. I know there's a modicum of technical ability necessary to do certain things with computers, but for the most part, those can be solved by following rules and creative use of Excel.
The value comes from giving people a framework to solve their problems, doing the thinking for them while accounting for the edge cases that they didn't get to, and then compiling that system of rules into a program.
The value comes from giving people a framework to solve their problems, doing the thinking for them while accounting for the edge cases that they didn't get to, and then compiling that system of rules into a program.
Hilariously, asking them what they DON’T want actually does work in practice.
Asking your customers what they want is a form of designed by committee. What people want is the well thought out, self consistent vision of a single artist, minus a few things.
Asking your customers what they want is a form of designed by committee. What people want is the well thought out, self consistent vision of a single artist, minus a few things.
I often tell my wife my software job is like being a home builder, people think they know what they want, but it's not until they're standing in the thing trying to use it that they figure out what parts work and don't work well for what they actually need... and I spend quite a bit of iterating before we end up with the final working thing -- which is usually far removed from the initial design.
I completely agree, but it sure does help to listen to everybody. I always joke that I am a complaint sponge that just absorbs every little nit pick and bother anyone has with a product. Listening is the cheapest and easiest thing I can do to make someone feel better about whatever it is I end up having to do. An overwhelming amount of the time I am unable to fulfill a request because the backlog is filled to the gills with other requests. Listening to people, asking clarifying questions, and digging into their issue and how they feel about it almost always makes them feel better. Don't retread ground that has already been covered, but I have a much better time telling them their idea may not be implemented for a long time after taking thoughtful time with them to make them feel heard. I also try to disappoint upfront. No use telling them the idea is in the backlog if they have heard that 1000 times only to have the ticket sit there for years.
At worst you learn a little more what someone thinks while getting them to talk and complain, an act most people find comfort it. At best you get incredibly useful empathy on a nagging issue that can benefit others. So yes, people usually have no idea what they want, but good luck telling people that. It's the PMs job to get everybody on board for the vision of a thing and how it addresses the problems behind the problems otherwise a perfect implementation of something a customer did not feel heard on will land quite different that something that they did. My two cents for what it is worth.
At worst you learn a little more what someone thinks while getting them to talk and complain, an act most people find comfort it. At best you get incredibly useful empathy on a nagging issue that can benefit others. So yes, people usually have no idea what they want, but good luck telling people that. It's the PMs job to get everybody on board for the vision of a thing and how it addresses the problems behind the problems otherwise a perfect implementation of something a customer did not feel heard on will land quite different that something that they did. My two cents for what it is worth.
I think instead of viewing this with the "the customer doesn't understand themselves" lens, you could better view this problem as one of misaligned goals, where asking the customer gets you advice how to archive the customer's goals, not the companies'.
E.g. in the milkshake examples, customers probably were giving all kinds of advice how to make the milkshake taste better or how to streamline the buying process, etc. And this feedback would certainly improve the milkshake-buying/drinking experience of those who already decided to get themselves a milkshake. However that's not the goal of the company: The company wants to sell more milkshakes, not better ones - it probably couldn't care less what people do with their milkshakes once they bought them.
So the companies' goal is probably better served by tracking their customers and finding out how they get to the decision to buy a milkshake in the first place - but that's not really the customer's goal.
E.g. in the milkshake examples, customers probably were giving all kinds of advice how to make the milkshake taste better or how to streamline the buying process, etc. And this feedback would certainly improve the milkshake-buying/drinking experience of those who already decided to get themselves a milkshake. However that's not the goal of the company: The company wants to sell more milkshakes, not better ones - it probably couldn't care less what people do with their milkshakes once they bought them.
So the companies' goal is probably better served by tracking their customers and finding out how they get to the decision to buy a milkshake in the first place - but that's not really the customer's goal.
Well the compeny should care what someone does as repeat customers and recomendations matter.
When we were in startup / small business mode we had a founder who was absolutely incredible at turning customer feedback into actionable and well thought out “actually here’s a better solution”
He was out shortly after the acquisition, and now we get videos emailed to us by corporates UX team of them asking the worlds most inept users how things should work and given changes based directly on this feedback.
I swear agreeing to be in a test group is self selecting for people who don’t understand the most basic UI metaphor. It’s frankly been a race to the bottom.
He was out shortly after the acquisition, and now we get videos emailed to us by corporates UX team of them asking the worlds most inept users how things should work and given changes based directly on this feedback.
I swear agreeing to be in a test group is self selecting for people who don’t understand the most basic UI metaphor. It’s frankly been a race to the bottom.
Idk if I’m convinced by “HCI dogma disproven because sometimes customers are contradictory or unclear”. If you forgive the clickbait headline and actually read the (pre-promotion?) article, it’s good stuff - totally agree that it’s about asking customers questions that help you answer your questions, not just letting them design the product directly.
Also true the old adage "if you try to please everyone, you'll end up pleasing no one". Your most vocal complaints do not necessarily translate to the largest majority issue (I'd say often quite the opposite). Make sure any changes won't alienate your core demographic.
This is true to a large extent but if you let edge cases build up over a long time you end up with an n-dimensional long tail. A whole bunch of customers to whom you’re not providing the expected quality of service.
It depends on the type of good/service/commodity you supply.
It depends on the type of good/service/commodity you supply.
The article basically quotes this video clip of Clay Christensen.
https://www.youtube.com/watch?v=Stc0beAxavY
I included this video in a onboarding guide for my team and many enjoyed it.
https://www.youtube.com/watch?v=Stc0beAxavY
I included this video in a onboarding guide for my team and many enjoyed it.
Yeah, most of the article is direct quotes from his book 'Competing against luck'. I felt he tells it in an amazing way, so no need to ruin that :)
Clay Shirky told the same story in his excellent book `Cognitive Surplus: Creativity and Generosity in a Connected Age`
https://witandwisdomofanengineer.blogspot.com/2010/07/engine...
TLDR: McDonald's customers buy milkshakes. Marketing people ask customers how they can make milkshakes better... to sell more. They make changes with zero change in sales.
A researcher asks people who buy milkshakes: what is the job that the shake fills for you? Why do you "hire" the shake?
Answer: early morning commuters want something to eat while driving to work. A shake isn't a good breakfast, but it's quick and easy to buy then consume while driving to work. Satisfying.
The point is making a shake "better" won't help anyone! "How can we make it better" is the wrong question!
https://witandwisdomofanengineer.blogspot.com/2010/07/engine...
TLDR: McDonald's customers buy milkshakes. Marketing people ask customers how they can make milkshakes better... to sell more. They make changes with zero change in sales.
A researcher asks people who buy milkshakes: what is the job that the shake fills for you? Why do you "hire" the shake?
Answer: early morning commuters want something to eat while driving to work. A shake isn't a good breakfast, but it's quick and easy to buy then consume while driving to work. Satisfying.
The point is making a shake "better" won't help anyone! "How can we make it better" is the wrong question!
Making it easier to drink on the road, easier to buy, etc. would make it better for this use case. So "better" is contextual.
Great podcast on the subject from some product people from Basecamp: https://demandthinking.com/episodes/2017/7/23/episode-1-thin...
One thing I wish happened more often was an iterative approach to features vs time to delivery. (Speaking of having been both a customer and PM-like roles)
e.g.
Customer: this is a list of features I would like
PM: Ok, we reviewed that list and here is a "menu" of the features with how long they will take
Customer: Great! I reviewed that list and I would rather have multiple quick to market features rather than wait for that "big" feature.
Asking customers what they want with no "price discovery" on either side is just people dreaming up ideas.
e.g.
Customer: this is a list of features I would like
PM: Ok, we reviewed that list and here is a "menu" of the features with how long they will take
Customer: Great! I reviewed that list and I would rather have multiple quick to market features rather than wait for that "big" feature.
Asking customers what they want with no "price discovery" on either side is just people dreaming up ideas.
That's more like the cost. You could also ask them what they would be willing to pay for each feature. Good idea, though!
While I think there's some truth to this idea, modern companies and the software industry in particular has taken it to the absolute extreme. We're not just no longer asking people what they want, we're ignoring the existence of anything that a person could want aside from a momentary dopamine boost.
It's also really pretentious. Go read Shit User Stories for some particularly amusing/egregious examples.
It's also really pretentious. Go read Shit User Stories for some particularly amusing/egregious examples.
Though not immediately relevant, it's pertinent to bring up "The Mom Test" (https://www.momtestbook.com/) book. This book offers insights into conducting customer interviews without inadvertently guiding them towards giving the answers you want to hear, or asking them to forecast whether they'll use your product.
I searched the thread to make sure someone mentioned this because I found it very useful. It encourages you to ask customers about real experiences instead of opinions, and gives you ways to identify things they care enough about to invest time/money into.
In my case, I’ve found it effective to ask a user what they want to do, as opposed to what they want.
Both internal stakeholders and external customers don't know what they want. Recent conversation I had with a customer went...
Me: Do you want X?
Customer: Yes, absolutely.
Me: What about Y?
Customer: That too.
Me: X and Y are mutually exclusive.
Customer: Oh, ok. What should I ask for?
As pointed out by a few posters here, your job is to tell your customers what they want.
Me: Do you want X?
Customer: Yes, absolutely.
Me: What about Y?
Customer: That too.
Me: X and Y are mutually exclusive.
Customer: Oh, ok. What should I ask for?
As pointed out by a few posters here, your job is to tell your customers what they want.
But wouldn't this also be an opportunity to dive deeper?
Ok, so at a basic level you want both X and Y, but those are mutually exclusive. Why do you want both? Is one a "must" and the other a "nice to have"? Are X and Y needed in different situations/by different departments? Etc...
As a concrete example, a customer demand of "I want the light be on but I also want it to be off" sounds nonsensical, but maybe they really just want to have a light switch.
Ok, so at a basic level you want both X and Y, but those are mutually exclusive. Why do you want both? Is one a "must" and the other a "nice to have"? Are X and Y needed in different situations/by different departments? Etc...
As a concrete example, a customer demand of "I want the light be on but I also want it to be off" sounds nonsensical, but maybe they really just want to have a light switch.
I've had similar experiences with internal stakeholders.
about 10+ years ago I was asked to make a system that would give users the ability to get an email alert "whenever something happened on their server" Well users said they wanted it and welp when a user turned the feature on as asked they got a lot of emails... I think the disconnect isn't that we should give users what they ask but try and make something that can help their problem from their perspective. I've also been on product teams that would per se "we'll just make sure they won't need to be alerted if something happens on their server - we won't let it happen"
One of the most pop-culture (AKA "memed") examples of this is dresses with pockets, you find so many comments from women saying they want them, and then fail to buy then once a company is born that focus on that feature, and is not that they are purposely lying, I bet some really would like to be the kind of person who values pocket/utility over other factors, but in front of the mirror some other factors impose a bigger influence; it's just human nature, the vast majority of people in general are not what they want to be and that is just one more of those cases.
> "What job were you trying to do for yourself that caused you to come here and hire that milkshake?"
"hire"? This makes the text look like synonym converter output.
"hire"? This makes the text look like synonym converter output.
It's either a non-native english speaker or a marketer so far up their own ass they can see daylight again ... but I repeat myself.
What people say they want is usually a stone's throw from what they already have.
If you radically want to change what people have, asking people what they want won't get there.
If you radically want to change what people have, asking people what they want won't get there.
For the last 5 or so years, I'm building mobile POC/MVP apps for my clients. I also launched several startups myself (all failed eventually). 2/3 generated some revenue. Main lessons learned and pits fallen into:
- Collect feedback from the user. Once all feedback is collected, try to find patterns and understand, will solution really solve anything and if it will - how much work it takes vs how much value overall biz gets. If it doesn't bring any value/revenue - might even consider scraping feature out to not bring more tech debt along the way
- Focus on only things that matter. Pretty much every single client I work with ends up implementing features that seems nice, look good, but brings little to no value to the overall biz. Feature just was built in just for the sake of having a `bigger and more functional product`
- Be aware if feedback comes from payed vs free user. It's very easy to focus on wrong things as ^
Overall, I keep seeing feedback collection going well. However the conclusion from it - just getting messy.
- Collect feedback from the user. Once all feedback is collected, try to find patterns and understand, will solution really solve anything and if it will - how much work it takes vs how much value overall biz gets. If it doesn't bring any value/revenue - might even consider scraping feature out to not bring more tech debt along the way
- Focus on only things that matter. Pretty much every single client I work with ends up implementing features that seems nice, look good, but brings little to no value to the overall biz. Feature just was built in just for the sake of having a `bigger and more functional product`
- Be aware if feedback comes from payed vs free user. It's very easy to focus on wrong things as ^
Overall, I keep seeing feedback collection going well. However the conclusion from it - just getting messy.
It does but you need to ask them more vague questions. Like, with the car vs horse thing, depending on the way the question is asked, they'll either say "a faster horse" or "a way to get home faster so I can spend more time with my kids"
This involves actually getting to know your customers and not just treating them as pawns to make more money.
You want to find the underlaying wants.
This involves actually getting to know your customers and not just treating them as pawns to make more money.
You want to find the underlaying wants.
Reminds of the story about commuters saying they want a toaster in their car when what they really want is to spend less time commuting so they have time to make toast at home.
In consumer apps this is true. In B2B and especially enterprise it’s less true. Especially if you sell to tech companies.
If your customer says they need an Okta integration with SCIM provisioning, they probably actually do need an Okta integration with SCIM provisioning, and not having that will impact your sales and retention metrics.
If your customer says they need an Okta integration with SCIM provisioning, they probably actually do need an Okta integration with SCIM provisioning, and not having that will impact your sales and retention metrics.
Only clicked this to see how many people would mention 'faster horse', I was not dissapointed.
Happy new year ya'll.
Happy new year ya'll.
I wonder how many of your customers secretly don't want to be your customer but have to be for some reason or another. If this is the case, then asking these customers for what they want may illicit a response to create satisfaction from their unsatisfactory circumstance.
I experienced this when I ran a moderately popular open source tool for other developers. Users have no idea what they want. The only way to know with any kind of certainty is to be both a user (customer) and the developer expert and have enough authority to tell them what they want.
When you have those three ingredients selling to new users becomes much easier and well as reengaging relationships with existing users (customers). Nobody cares otherwise even if you have the best product and value on the market.
When you have those three ingredients selling to new users becomes much easier and well as reengaging relationships with existing users (customers). Nobody cares otherwise even if you have the best product and value on the market.
I wish understanding what the customers actually want (or even better, what they will want) were more valued in the tech world. I have a peculiar knack for it, which has extended from web design to data analysis and even tough medical conversations. One would think it to be something valuable, but instead bosses seem to value a slavish "drive into a brick wall" conformation to their orders over foresight and insight.
Sounds like you should start a company :)
“Chapter 1: The Milkshake Dilemma” from “Competing Against Luck” (Christensen 2016) cited in the article is one of my favorite nonfiction book chapters of all time. The milkshake case study perfectly illustrates the jobs-to-be-done concept that the vertical axis of the disruptive innovation graph measures.
Coincidentally, I listened to the Competing Against Luck audio book on a long walk today. Fun to see it on HN.
Coincidentally, I listened to the Competing Against Luck audio book on a long walk today. Fun to see it on HN.
Asking customers what they want - or rather what their problem is - doesn’t work but it’s the best method we have
I remember being a dev lead for a small internal product. I think 80% of the requests were "add custom behavior guarded by a checkbox".
Fortunately we could just walk over to the (internal) customers, discuss the requirements and avoid creating a single huge function with logic determined by 37 checkboxes.
Fortunately we could just walk over to the (internal) customers, discuss the requirements and avoid creating a single huge function with logic determined by 37 checkboxes.
Conversely, I've had designers who I was asking for a way to more nicely represent 37 checkboxes keep insisting that we may find a way to reduce them, even though I kept explaining that these are all features in some external protocol that we are modeling and that we can't go and ask the IETF to please reduce the options they offer.
My point being that it's important to distinguish between fundamental and incidental complexity, which isn't always so clear cut. I think that's one of the hardest skills in making good products of any kind.
My point being that it's important to distinguish between fundamental and incidental complexity, which isn't always so clear cut. I think that's one of the hardest skills in making good products of any kind.
[deleted]
Hot take, People have spent wayyyy too long assuming they know better than their customers what they want, and oftentimes use this as an excuse to justify ignoring what customers want.
Asking your customers what they want is a really good first step in figuring out what they want. You're not always going to be able to just magically intuit what your customers want. Sometimes you need to put in the hard work to figure out what they're doing and how you can make it better.
I hate XY problems, because as often as I'm the person wanting to figure out what question someone is actually trying to ask, I'm the person on the other side asking an actually well-thought-out question and getting told I don't want that.
Asking your customers what they want is a really good first step in figuring out what they want. You're not always going to be able to just magically intuit what your customers want. Sometimes you need to put in the hard work to figure out what they're doing and how you can make it better.
I hate XY problems, because as often as I'm the person wanting to figure out what question someone is actually trying to ask, I'm the person on the other side asking an actually well-thought-out question and getting told I don't want that.
I'm biased, but I think FullStory is really useful for seeing where people are hitting hiccups when trying to use your software, and you can often tell what they were trying to do, e.g. clinking thr visa icon instead of the credit card button in a checkout form.
I was going to look this up, but it seems at least one of the people that maintain my pihole's lists have already blocked the domain. In any case, I like not being monitored in real time.
The whole concept of real user monitoring is that it allows you to detect erroneous patterns in how they specifically use your product, so that you can ideally fix said problems if they're common enough. I'm not wildly excited over the idea of being tracked either, and ideally this is something driven via the site offering the service, but it can be a very valuable tool for FE devs to figure out why customers are having a negative experience without having to tell you explicitly, which is great.
If Henry Ford asked his customers what they wanted they would say faster horses.
And faster horses would have made a fortune if he could have produced them.
Not really because horses are expensive. They eat even on days you don't use them. Miles per hay bale needs to be asked about. Those using a horse already wanted a faster one. Most people would not have found a fast horse better. Henry Ford gave the people faster transport that they could afford.
You can still, to this day, make considerable money selling faster horses.
Asking what job was the product hired to do is similar to my favorite question: What pain are they trying to remove with the product?
Talking to customers is still important to understand the motives for their actions and the problems they have. Sometimes they even don't tell you directly that they have a problem. The action is actually normal for them and only an outsider who tries to understand what they do sees this problem.
An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable.
The pain of always untwisting the cable and making sure it ran nice under your jacket was real.
Talking to customers is still important to understand the motives for their actions and the problems they have. Sometimes they even don't tell you directly that they have a problem. The action is actually normal for them and only an outsider who tries to understand what they do sees this problem.
An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable.
The pain of always untwisting the cable and making sure it ran nice under your jacket was real.
> An example of this are AirPods. Everyone was used to headphones with cable. Non one identified the cable as a problem. That's why at first AirPods felt strange when you saw them. But as soon as you had your own wireless headphones you immediately noticed the problem you had with the cable.
Surely you're not implying that Apple invented this? Wireless headphones and Bluetooth earpieces existed and saw widespread use long before AirPods were relevant.
What Apple did was miniaturize the guts into a stylish form factor. Their branding and market share did the rest.
Surely you're not implying that Apple invented this? Wireless headphones and Bluetooth earpieces existed and saw widespread use long before AirPods were relevant.
What Apple did was miniaturize the guts into a stylish form factor. Their branding and market share did the rest.
> Wireless headphones and Bluetooth earpieces existed
Afaik you had either full headphones with a headband, in-ears with the battery hanging off a cable between them and the one-ear standalone things that were good only for calls.
Also the little charging box that you could keep in your pocket was nowhere to be seen.
So yes, airpods were a lot more convenient when launched. Has little to do with branding. Everyone is cloning it now :)
Afaik you had either full headphones with a headband, in-ears with the battery hanging off a cable between them and the one-ear standalone things that were good only for calls.
Also the little charging box that you could keep in your pocket was nowhere to be seen.
So yes, airpods were a lot more convenient when launched. Has little to do with branding. Everyone is cloning it now :)
J2BD is my fave framework. That and GTFO. I was just lamenting to some Clients over drinks how the tech industry has spent the last 20 years stuck in confirmation bias hell...
What works better is asking them what their problems are.
What also works is I ask myself, what do I want? Since I'm a programmer, pleasing myself goes a long way towards pleasing the users.
What also works is I ask myself, what do I want? Since I'm a programmer, pleasing myself goes a long way towards pleasing the users.
Can be summed up nicely as sung by the Stones: identifying what your customers need is better than giving what they want
First you ask what they want; then you ask what problem they are trying to solve. It’s that second one that’s important.
Whenever I see stuff like this I think of Steve jobs:
In 2007, right before the first iPhone launched, Steve Jobs was asked the obvious question: The design of the iPhone was based on discarding every physical interface element consumers were used to except for a touchscreen. Would consumers be willing to give up the then-dominant physical keypads with tactile feedback for a more clumsy experience with a touch screen keyboard?
His answer was brusque: “They’ll learn.”
In 2007, right before the first iPhone launched, Steve Jobs was asked the obvious question: The design of the iPhone was based on discarding every physical interface element consumers were used to except for a touchscreen. Would consumers be willing to give up the then-dominant physical keypads with tactile feedback for a more clumsy experience with a touch screen keyboard?
His answer was brusque: “They’ll learn.”
And I still long for physical keys on my "smartphone" as I miss every 3rd letter or so on that flat surface with zero tactile feedback...
Steve was prescient. He's so knowledgeable about consumers he knew that consumers would willingly take UI/UX design and back pedal by several decades just to accept the novelty of a dynamic touch screen.
As much as you as a consumer hate the touch screen... consumers as a whole are the ones who chose to go this direction.
As much as you as a consumer hate the touch screen... consumers as a whole are the ones who chose to go this direction.
I think this is a misunderstanding of the UX of phones. The fact that keyboard input is harder on a touchscreen than a physical keyboard is of course a disadvantage. But it is a much smaller disadvantage than the UX gains from having more screen space for content when you're not typing. Also, a touchscreen is much better for input than a keyboard for various navigation features - panning, zooming, selection, not to mention many styles of games are all more suited to touchscreen input then keyboard input.
So, the choice is between a phone with a good keyboard but half the screen size (horrible for the web, maps, photos), or a phone with a subpar but still functional keyboard with a full screen. The UX is clearly overall much much better on the second one.
So, the choice is between a phone with a good keyboard but half the screen size (horrible for the web, maps, photos), or a phone with a subpar but still functional keyboard with a full screen. The UX is clearly overall much much better on the second one.
Yeah that's one perspective of the tradeoff. I'm neutral on this actually. I think both perspectives are correct depending on your angle.
The mouse and keyboard still haven't been replaced by a touch screen.
The mouse and keyboard still haven't been replaced by a touch screen.
> The mouse and keyboard still haven't been replaced by a touch screen.
That is very much in line with what I'm saying. Where you don't have a space problem, having a keyboard and a mouse and a big screen is ideal.
But just as no one is seriously considering putting a mouse on a phone, I don't see why they'd consider a keyboard as mandatory either.
That is very much in line with what I'm saying. Where you don't have a space problem, having a keyboard and a mouse and a big screen is ideal.
But just as no one is seriously considering putting a mouse on a phone, I don't see why they'd consider a keyboard as mandatory either.
Some people had had PalmPilots for years when Jobs launched the iPhone and were wondering why no one puts a cell phone on them...
Also some people (looks in mirror) had noticed that you could press buttons in apps with your thumbs even on the resistive Palm touch screens and were hoping they enlarge the scroll bars so you can at least view data without taking out the stylus.
Yes, there was the Treo, but mobile internet was still crap and expensive. If i recall correctly, they even added a keyboard back because their customers thought they needed better Blackberrys?
Also some people (looks in mirror) had noticed that you could press buttons in apps with your thumbs even on the resistive Palm touch screens and were hoping they enlarge the scroll bars so you can at least view data without taking out the stylus.
Yes, there was the Treo, but mobile internet was still crap and expensive. If i recall correctly, they even added a keyboard back because their customers thought they needed better Blackberrys?
When he said that, he knew well how much prior work had gone into touch- and multitouch-based interfaces, including lots of work outside Apple such as technical developments and a long tradition of HCI research into such interfaces with end users. However, "they'll learn" sounds much more catchy and visionary than "based on doing our homework thoroughly, we have built a grounded theory on how culture and technology have developed to the point where we can sell a newly and nicely packaged thing - and where we are able to mass produce it".
In other words: Apple's thinking process about what to build when and how to shape it are not prescience at all - they are science. They very carefully look at as much context as possible, including - but not limited to - what users (say they) want. Jobs was great at making those processes look visionary and magical which was (very) good for internal and external marketing.
In other words: Apple's thinking process about what to build when and how to shape it are not prescience at all - they are science. They very carefully look at as much context as possible, including - but not limited to - what users (say they) want. Jobs was great at making those processes look visionary and magical which was (very) good for internal and external marketing.
Obviously prescience doesn't exist. I just used the term to illustrate his instinctive ability to predict things beyond the typical data driven way we worship nowadays.
It's not science either. Science requires data and the data overwhelming showed that consumers preferred physical keyboards.
Puahing the iPhone requires one to actually go against the science and against the consumer data. It's unlikely any internal marketing or design team led the way here as their approach would likely be science based. Jobs most likely led the way by intuiting how consumers would change based off of his own experience with the prototypes.
Certainly not super human, but a bit more smarter than your average consumer research scientist to be able to make an analysis that not only goes above science, but against it.
People worship science as the one and only infallible method to answer questions. That's not true. Science needs data and many questions just don't have data available to build an answer. For this kind of thing you need to use induction.
It's not science either. Science requires data and the data overwhelming showed that consumers preferred physical keyboards.
Puahing the iPhone requires one to actually go against the science and against the consumer data. It's unlikely any internal marketing or design team led the way here as their approach would likely be science based. Jobs most likely led the way by intuiting how consumers would change based off of his own experience with the prototypes.
Certainly not super human, but a bit more smarter than your average consumer research scientist to be able to make an analysis that not only goes above science, but against it.
People worship science as the one and only infallible method to answer questions. That's not true. Science needs data and many questions just don't have data available to build an answer. For this kind of thing you need to use induction.
I think our views are not too dissimilar and I agree with Jobs being exceptional. I also agree that the kind of (only) quantitatively driven science you are describing is not sufficient to predict innovation. However, there are also other, more qualitative, branches of science that work in different ways (I've chosen the phrase "grounded theory" which comes from sociology for that reason).
There has been prior work into multi-touch interfaces and all sorts of things related to ubiquitous computing long before the iPhone. Jobs/Apple was aware of this and built on it at the right time - just like they were aware and built on the work at Xerox PARC before.
There has been prior work into multi-touch interfaces and all sorts of things related to ubiquitous computing long before the iPhone. Jobs/Apple was aware of this and built on it at the right time - just like they were aware and built on the work at Xerox PARC before.
I found "Creative Selection: Inside Apple’s Design Process During the Golden Age of Steve Jobs" worthwhile reading on this matter.
The correct term for this recurring abuse of end users is "Stockholm Syndrome".
Finns have an age-old saying about the same thing. Loosely translated... At first it hurts. Then you get used to it. And then you start to like it.
Finns have an age-old saying about the same thing. Loosely translated... At first it hurts. Then you get used to it. And then you start to like it.
Unfortunately it's not abuse when your alternatives are Windows [1] on the desktop and Android on mobile :(
It's sad that Apple has no meaningful competition. Not because they're the best, but because they suck the least.
[1] I make a living on Linux but where's that consistent experience desktop? I think I won't live to see it.
It's sad that Apple has no meaningful competition. Not because they're the best, but because they suck the least.
[1] I make a living on Linux but where's that consistent experience desktop? I think I won't live to see it.
The truly sad thing is, there was a killer form factor for phones. N900. Full touchscreen, with a slide-out physical keyboard.
It wasn't a perfect device, far from it. The details of the form factor were still off: the device was too thick, and the keyboard was part of a heavy "base". It slid out too little for the keyboard to be properly useful. The screen was the wrong size, with an awkward aspect ratio. But nonetheless, N900 had the right idea. With three or four hardware revisions it could have become something magnificent.
Instead what we have right now is like the Zork opening from an alternate universe - "you are in a maze of twisted options, all equally shitty."
Btw, the consistent desktop experience exists right now. It's called "i3" or "sway", depending on your display tech.
It wasn't a perfect device, far from it. The details of the form factor were still off: the device was too thick, and the keyboard was part of a heavy "base". It slid out too little for the keyboard to be properly useful. The screen was the wrong size, with an awkward aspect ratio. But nonetheless, N900 had the right idea. With three or four hardware revisions it could have become something magnificent.
Instead what we have right now is like the Zork opening from an alternate universe - "you are in a maze of twisted options, all equally shitty."
Btw, the consistent desktop experience exists right now. It's called "i3" or "sway", depending on your display tech.
“Sway is a wayland compositor”. Does that give a consistent experience across applications? Or at least a taskbar that doesn’t visibly add and remove icons every time they refresh, recalculating sizes and shrinking and growing all the time? Which was kde’s state last time I used Linux as my main deskop…
In a way, yes. It stays out of the way - in fact, there is no desktop. i3 is a tiling window manager, and rather minimalistic at that. Sway is a wayland-native reimplementation of i3, with the same (lack of) appearance, and i3 configs work with sway pretty much out of the box.
To launch a program you either hit a hotkey combo of your choice or use <win>-d to bring up a top-of-screen text menu bar with full text search to find (and launch) your desired software.
Stating the obvious: I've never been a fan of desktop environments. I found them confusing even back in the GEOS (C-64) and windows 2.x days.
To launch a program you either hit a hotkey combo of your choice or use <win>-d to bring up a top-of-screen text menu bar with full text search to find (and launch) your desired software.
Stating the obvious: I've never been a fan of desktop environments. I found them confusing even back in the GEOS (C-64) and windows 2.x days.
Steve Jobs also thought the phones don't need apps despite customers telling him otherwise. The customers were right.
He also thought they don't need 3G despite what customers told him. The customers were also right. He also thought that they don't need copy/paste. The customers were, again, right.
Cherry picking data is great, isn't it?
Cherry picking data is great, isn't it?
Relax man. He's not right about everything but he's right about keyboards.
There's no cherry picking data here because Im not using the data to support some point about Steve Jobs being some sort of god like prophet. I didn't even make a point. I just said that it made me think about this.
My thoughts on consumer data is that some data is valid some isn't. It's like asking a woman for dating advice. Sometimes she gets it but a lot of the time it's better to ask for advice from a man who fucked a lot of women.
Just to spell it out. Consumers are women. Steve jobs is the man who fucked a lot of women.
There's no cherry picking data here because Im not using the data to support some point about Steve Jobs being some sort of god like prophet. I didn't even make a point. I just said that it made me think about this.
My thoughts on consumer data is that some data is valid some isn't. It's like asking a woman for dating advice. Sometimes she gets it but a lot of the time it's better to ask for advice from a man who fucked a lot of women.
Just to spell it out. Consumers are women. Steve jobs is the man who fucked a lot of women.
I think the question isn't what customers want. It's rather what customers are going to buy.
100% - the roles of user and purchaser being different are a good chunk of the reason most enterprise-targeted software is compete shit. The user has no choice, and the person purchasing doesn’t care provided it’s cheaper by a couple of pennies on the dollar.
Which means it's your job to educate the buyer about your product's value, not cost. If you merely want to save money, buy nothing.
""If I'd asked my customers what they want, they'd have said a faster horse.
" - Henry Ford" - Steve Jobs
1) assuming the user understands what they want/need - this is rarely the case. Figuring out what they really need is your job.
2) assuming that what you are building is something the user wants - until people use it, you have no proof for this. Lots of startups fall into the trap of building stuff that nobody wants or needs.
3) assuming what users ask for is actually what they need - always figure out why they are asking for this, whether they are actually going to use it if you build it (I've had cases where we built stuff that was never used), and what it is worth to them.
4) assuming that what your sales people say the customer wants is actually what they want or need. This one is tricky. I've had sales people go "unless you build X, I can't close the deal" and then you build X and it doesn't make a difference. Reason: the sales person's analysis was wrong.
Especially with new products, figuring out if it is something users want is tricky. Do users actually like the new thing? They won't be asking for it because it is a new thing. You have to pitch and explain the thing to them and even then they still might not get it. Only when you show them the thing and they like it will you get some confirmation that this might be something they want/need.
The classic example is selling cars when they were invented is that all customers ever asked for was faster horses.