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.
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"
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.
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.
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 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.
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.
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?
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.
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.
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?
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.
“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.
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.
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.
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.
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.
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.
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.
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 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?
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".
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.
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.
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!
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.
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.
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.
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.
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.
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"
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.
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.
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.
> 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.
> 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 :)
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.
> 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.
> 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.
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.
> 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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".
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.
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
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 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].
> 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
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 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.
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.
"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.
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.
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.
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.
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.
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.
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.
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.
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
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'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.
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.
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?
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.
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.
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
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
219 comments
[ 2.9 ms ] story [ 240 ms ] threadIt depends on the type of good/service/commodity you supply.
If you radically want to change what people have, asking people what they want won't get there.
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.
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
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.
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.
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.
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.
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.
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!
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.
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"
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.
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 :)
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!
[0] https://en.m.wikipedia.org/wiki/XY_problem
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.
https://workos.com/single-sign-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.
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.
https://hbr.org/2011/08/henry-ford-never-said-the-fast
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.
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.