7 ms·

Classic mistakes in product management: 1) assuming the user understands what they want/need - this is rarely the case. Figuring out what they really need is y

Classic mistakes in product management: 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.

xkcd1963 3y ago
1 and 3 is the same, if 4 then add 5) assume what devs say is actually what they want or need
- jillesvangurp 3y ago
  They are similar but there's a difference between a customer explicitly asking for something / demanding it, and soliciting feedback.
nirvdrum 3y ago
> 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.
- pjerem 3y ago
  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.
  - pdimitar 3y ago
    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.
  - beezlewax 3y ago
    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.
  - mlrtime 3y ago
    Ok, let's go back and change things as a thought experiment. How could this have played out differently (in America). Are you suggesting that America could be as large and diverse as it is now just using bikes and trains? Are you also suggesting most of the 230 million US drivers would prefer this as a better solution?
    - marcosdumay 3y ago
      > just using bikes and trains Some times it looks like nobody even know street-cars existed anymore.
- bryanrasmussen 3y ago
  People obviously wanted a Segway, they just didn't want it at that price point. People even obviously wanted a Segway in Europe, where the cities have impressive support for bikes. If People hadn't wanted a Segway (but way cheaper) we wouldn't have the streets littered with cheap electric scooters everywhere you go.
cratermoon 3y ago
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.
- passwordoops 3y ago
  Majority of B2B SaaS too. It's the only reason SAP is what it is
  - cratermoon 3y ago
    Absolutely. The folks who make the decisions to buy aren't the ones that have to use it.
- deleted 3y ago
  [deleted]
- esafak 3y ago
  https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...
PH95VuimJjqBqy 3y ago
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.
- AntonZ234 3y ago
  I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing. Most of the PMs come from non-tech background, more project-management types, and it shows.
- FridgeSeal 3y ago
  Fully agreed. Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.
  - hitchstory 3y ago
    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.
AntonZ234 3y ago
"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.
- j4yav 3y ago
  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.
  - jddj 3y ago
    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.
    - j4yav 3y ago
      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.
talldatethrow 3y ago
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.
- herodoturtle 3y ago
  Your top sales tip for a solo SaaS founder? Happy holidays! ^_^
  - deleted 3y ago
    [deleted]
CipherThrowaway 3y ago
> I've had sales people go "unless you build X, I can't close the deal" For the benefit of younger devs, I'd like to add that this is a rookie sales mistake that indicates lack of software sales experience.
- j4yav 3y ago
  Can you expand on this a bit, or recommend an article that does?
- passwordoops 3y ago
  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
Baldbvrhunter 3y ago
Most people didn't want faster horses, they didn't even have slow horses. What they wanted was time off and something to do with it.
- esafak 3y ago
  Most potential customers then.
  - Baldbvrhunter 3y ago
    I don't understand. Ford's introduced the 5-day work week (reduced from 6), and the "Five-Dollar Day" and reduced work days from 9 hours to 8. No-one talked about horses.
    - esafak 3y ago
      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.
      - Baldbvrhunter 3y ago
        I still don't understand what point you are trying to make, or how it relates to product development.
        esafak 3y ago
        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.
        Baldbvrhunter 3y ago
        Instead of faster horses, Ford's mass production process was the product. All those workplace changes were to expand the pie.
daanlo 3y ago
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.
- altdataseller 3y ago
  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?
- champtar 3y ago
  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.
- somewhereoutth 3y ago
  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.
  - TuringTest 3y ago
    Can't you set up a test environment with fake data, and ask them to simulate their work there? It's less than ideal, but it would allow youto see and understand their workflows
- phatskat 3y ago
  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
jen20 3y ago
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.
- beezlewax 3y ago
  Yes those touchscreens in cars are just ridiculous distractions and should probably be limited in their use by legislation.
  - thfuran 3y ago
    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.
- izacus 3y ago
  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.
laboratorymice 3y ago
> 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.
- jillesvangurp 3y ago
  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.
egberts1 3y ago
tHE classic mistake is not asking the right person within the customer's corporate hierarchy. Product Management should be about making it more efficient for end-users, low-tiered workers, and not the purchase manager nor even CTO.
deleted 3y ago
[deleted]
mark-r 3y ago
The "faster horses" comment is universally attributed to Henry Ford, but it appears he didn't actually say it. Here's an article that shows the results of researching the source, and has some interesting observations about Ford's innovations and the blinders that early success can cause. https://hbr.org/2011/08/henry-ford-never-said-the-fast https://hbr.org/2011/08/henry-ford-never-said-the-fast
KingOfCoders 3y ago
"unless you build X, I can't close the deal" There are things where this is true, compliance, SSO, enterprise integrations. But most of the time this signals the product has no USP and it also signals that you should get rid of your sales staff.
- chmod600 3y ago
  What's USP?
  - alluro2 3y ago
    https://en.m.wikipedia.org/wiki/Unique_selling_proposition https://en.m.wikipedia.org/wiki/Unique_selling_proposition
  - KingOfCoders 3y ago
    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.
  - KingOfCoders 3y ago
    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.
mv4 3y ago
I will add one more case that's often overlooked: 5) assuming they are willing to pay what they want/need
dotnet00 3y ago
Another great example is video games. Gamers will come up with all sorts of ideas that sound cool but have nothing fun to them except the initial novelty, particularly when it comes to simulation style games (eg "I should be able to walk around my spaceship and be able to do spacewalks to patch up the hull after micrometeorite impacts"). But on the other hand it is also very common for companies/developers to take this too far and blame the players for being wrong in not enjoying their game.
tyingq 3y ago
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.
a13n 3y ago
A good solution to #4 is to get the commitment in writing first. In the sales contract, say they will pay X upfront you will build F by Y date. This solves many problems. Customer can’t back out. Gives sales person clear next steps. Clearly defines feature details and deadline. Just make sure you set deadlines you can definitely hit.
gofreddygo 3y ago
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.

xkcd1963 3y ago

1 and 3 is the same, if 4 then add 5) assume what devs say is actually what they want or need

jillesvangurp 3y ago
They are similar but there's a difference between a customer explicitly asking for something / demanding it, and soliciting feedback.

nirvdrum 3y ago

> 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.

pjerem 3y ago
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.
- pdimitar 3y ago
  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.
- beezlewax 3y ago
  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.
- mlrtime 3y ago
  Ok, let's go back and change things as a thought experiment. How could this have played out differently (in America). Are you suggesting that America could be as large and diverse as it is now just using bikes and trains? Are you also suggesting most of the 230 million US drivers would prefer this as a better solution?
  - marcosdumay 3y ago
    > just using bikes and trains Some times it looks like nobody even know street-cars existed anymore.
bryanrasmussen 3y ago
People obviously wanted a Segway, they just didn't want it at that price point. People even obviously wanted a Segway in Europe, where the cities have impressive support for bikes. If People hadn't wanted a Segway (but way cheaper) we wouldn't have the streets littered with cheap electric scooters everywhere you go.

cratermoon 3y ago

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.

passwordoops 3y ago
Majority of B2B SaaS too. It's the only reason SAP is what it is
- cratermoon 3y ago
  Absolutely. The folks who make the decisions to buy aren't the ones that have to use it.
deleted 3y ago
[deleted]
esafak 3y ago
https://en.wikipedia.org/wiki/Principal%E2%80%93agent_problem https://en.wikipedia.org/wiki/Principal%E2%80%93agent_proble...

PH95VuimJjqBqy 3y ago

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.

AntonZ234 3y ago
I can relate to the senior developers in PM roles. I only worked with one such PM, but he was amazing. Most of the PMs come from non-tech background, more project-management types, and it shows.
FridgeSeal 3y ago
Fully agreed. Once worked in a place that hired a design researcher and they were amazing, they took the time to dig in to what you’re talking about here: the actual issues, not the words that came out of people’s mouthes. Had a lot of good insights, which were ultimately wasted on that particular business, but that’s for different reasons.
- hitchstory 3y ago
  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.

AntonZ234 3y ago

"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.

j4yav 3y ago
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.
- jddj 3y ago
  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.
  - j4yav 3y ago
    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.

talldatethrow 3y ago

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.

herodoturtle 3y ago
Your top sales tip for a solo SaaS founder? Happy holidays! ^_^
- deleted 3y ago
  [deleted]

CipherThrowaway 3y ago

> I've had sales people go "unless you build X, I can't close the deal" For the benefit of younger devs, I'd like to add that this is a rookie sales mistake that indicates lack of software sales experience.

j4yav 3y ago
Can you expand on this a bit, or recommend an article that does?
passwordoops 3y ago
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

Baldbvrhunter 3y ago

Most people didn't want faster horses, they didn't even have slow horses. What they wanted was time off and something to do with it.

esafak 3y ago
Most potential customers then.
- Baldbvrhunter 3y ago
  I don't understand. Ford's introduced the 5-day work week (reduced from 6), and the "Five-Dollar Day" and reduced work days from 9 hours to 8. No-one talked about horses.
  - esafak 3y ago
    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.
    - Baldbvrhunter 3y ago
      I still don't understand what point you are trying to make, or how it relates to product development.
      - esafak 3y ago
        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.
        Baldbvrhunter 3y ago
        Instead of faster horses, Ford's mass production process was the product. All those workplace changes were to expand the pie.

daanlo 3y ago

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.

altdataseller 3y ago
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?
champtar 3y ago
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.
somewhereoutth 3y ago
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.
- TuringTest 3y ago
  Can't you set up a test environment with fake data, and ask them to simulate their work there? It's less than ideal, but it would allow youto see and understand their workflows
phatskat 3y ago
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

jen20 3y ago

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.

beezlewax 3y ago
Yes those touchscreens in cars are just ridiculous distractions and should probably be limited in their use by legislation.
- thfuran 3y ago
  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.
izacus 3y ago
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.

laboratorymice 3y ago

> 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.

jillesvangurp 3y ago
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.

egberts1 3y ago

tHE classic mistake is not asking the right person within the customer's corporate hierarchy. Product Management should be about making it more efficient for end-users, low-tiered workers, and not the purchase manager nor even CTO.

deleted 3y ago

[deleted]

mark-r 3y ago

The "faster horses" comment is universally attributed to Henry Ford, but it appears he didn't actually say it. Here's an article that shows the results of researching the source, and has some interesting observations about Ford's innovations and the blinders that early success can cause. https://hbr.org/2011/08/henry-ford-never-said-the-fast https://hbr.org/2011/08/henry-ford-never-said-the-fast

KingOfCoders 3y ago

"unless you build X, I can't close the deal" There are things where this is true, compliance, SSO, enterprise integrations. But most of the time this signals the product has no USP and it also signals that you should get rid of your sales staff.

chmod600 3y ago
What's USP?
- alluro2 3y ago
  https://en.m.wikipedia.org/wiki/Unique_selling_proposition https://en.m.wikipedia.org/wiki/Unique_selling_proposition
- KingOfCoders 3y ago
  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.
- KingOfCoders 3y ago
  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.

mv4 3y ago

I will add one more case that's often overlooked: 5) assuming they are willing to pay what they want/need

dotnet00 3y ago

Another great example is video games. Gamers will come up with all sorts of ideas that sound cool but have nothing fun to them except the initial novelty, particularly when it comes to simulation style games (eg "I should be able to walk around my spaceship and be able to do spacewalks to patch up the hull after micrometeorite impacts"). But on the other hand it is also very common for companies/developers to take this too far and blame the players for being wrong in not enjoying their game.

tyingq 3y ago

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.

a13n 3y ago

A good solution to #4 is to get the commitment in writing first. In the sales contract, say they will pay X upfront you will build F by Y date. This solves many problems. Customer can’t back out. Gives sales person clear next steps. Clearly defines feature details and deadline. Just make sure you set deadlines you can definitely hit.

gofreddygo 3y ago

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.