Asking your customers what they want doesn't work
techbooks.substack.com
techbooks.substack.com
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.
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 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.
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.
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 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.
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.
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.
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.
Cars and many internet protocols (and software) are a perfect demonstration of this tendency.
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?
Some times it looks like nobody even know street-cars existed anymore.
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.
Most of the PMs come from non-tech background, more project-management types, and it shows.
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.
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.
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.
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.
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.
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.
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 more common name for it is post-hoc rationalization.
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.
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.
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
this it a hard problem to figure out, good luck.
[0] https://www.inc.com/magazine/201206/jason-fried/huge-account... (Archive link: https://archive.is/IHmwL)
An XY problem[0] about A-B!
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.
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.
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.
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 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.
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.
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.
Happy holidays! ^_^
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.
What they wanted was time off and something to do with it.
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.
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.
It's less than ideal, but it would allow youto see and understand their workflows
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.
> 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.
Product Management should be about making it more efficient for end-users, low-tiered workers, and not the purchase manager nor even CTO.
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.
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.
5) assuming they are willing to pay what they want/need
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.
"Show me why you need this" can sometimes help, but not always.
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.
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.
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.
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.
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...
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?
But your title will probably get more clicks.
"What to do after just asking the customer fails"
"Why I didn't implement your excellent feature request"
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.
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.
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.
> 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?
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".
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.
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.
CUSTOMERS: We just want to minimize the pain of tax return filing.
INTUIT: [lobbies government to keep that pain going strong]
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.
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.
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 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?
By all metrics relevant to Apple's business, as evidenced by the fact that it was discontinued after just two iterations.
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.
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 learn unforeseen faults in my house, but the faults don't get fixed.
Good software fixes its problems where the home builder metaphor lacks that concept.
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.
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.
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.
It depends on the type of good/service/commodity you supply.
https://www.youtube.com/watch?v=Stc0beAxavY
I included this video in a onboarding guide for my team and many enjoyed it.
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!
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.
It's also really pretentious. Go read Shit User Stories for some particularly amusing/egregious examples.
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.
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.
"hire"? This makes the text look like synonym converter output.
If you radically want to change what people have, asking people what they want won't get there.
- 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.
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.
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.
Happy new year ya'll.
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.
Coincidentally, I listened to the Competing Against Luck audio book on a long walk today. Fun to see it on HN.
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.
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.
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.
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.
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.
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 :)
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.
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.”
As much as you as a consumer hate the touch screen... consumers as a whole are the ones who chose to go this direction.
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.
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?
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.
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.
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 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.
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.
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.
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.
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.
Cherry picking data is great, isn't it?
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.