4 ms·

I disagree. Users generally have no idea what they want, especially related to novel things. If you waste time listening to the masses and have no initial visi

I disagree. Users generally have no idea what they want, especially related to novel things. If you waste time listening to the masses and have no initial vision of your own you'll end up with a Frankenstein project. Build something great and they will come.

onion2k 3y ago
Build something great and they will come. They won't stay though, because their opinion is unlikely to be the same as your opinion, and people only spend money on things that they think are good. You might believe your app is the greatest thing in the world, but that doesn't matter at all. You're not trying to persuade yourself to buy; you need to persuade your customer that the app is good. Clue: They're not looking at the code. Also, 'good' is a measure of usefulness rather than quality. People will spend a lot of money on absolute trash if it solves a problem that's costing them more money or time than your app, no matter how bad your app is.
- MrOwnPut 3y ago
  I'm not specifically talking about code quality, but usually that goes hand in hand with the product. An engineer that makes quality code will usually also care about the product quality overall as well. Good code quality makes that quality product maintainable and fun to work in. That being said, your product's traits are phenotypes of your code design. Its performance characteristics, its capable features, how it scales, everything is intertwined. Involve your developers more in the product planning, don't try to plan it for them and just hand them a spec. I've seen too many "product managers" and officers try to be engineers... That's like a real estate tycoon making blueprints for an architect. You will probably fail if you want to "do high quality code later" as your product will be shit because it's DNA is trash. And yes, you are trying to persuade yourself, you should be user #1 and your ultimate fan. Find a problem you have or recognize, and develop a solution you believe in. Others can barely even recognize there is a problem in the first place, let alone find the optimal solution. You can listen to others for minor adjustments after the fact, but your product vision is solely on you.
  - preommr 3y ago
    Another day, another argument on "If I asked my customers what they wanted they would've said faster horses" vs "Move fast and break things".
    - MrOwnPut 3y ago
      I wasn't saying "move fast break things", at all. Nearly the opposite in fact. Take your time and build something you know is great.
    - JohnFen 3y ago
      > "If I asked my customers what they wanted they would've said faster horses" The thing about this saying is that it ignores what the customers actually said they wanted. People who have a need will generally have a solution in their head. Saying they want "faster horses" is saying two things: what they want (faster travel) and their stab at a solution (horses). Ignoring what a customer says they want is a recipe for missing the mark. Accepting the solution they have in their mind at face value is also a recipe for missing the mark. What should be done is to listen to the customers and take them seriously, then work out a solution. That solution might, indeed, be "faster horses", or it might be something else entirely. But you won't get to a great solution by pretending people don't know what they want.
      - MrOwnPut 3y ago
        You're ignoring the part of how obvious the request is overall. Everyone wants faster travel, you don't need to ask anyone for that, it's not a vision.
bluGill 3y ago
You are both right, because you are talking about very different parts of the development cycle. When you are coming up with product ideas users have no idea what they want. When you show the user what they really want though they can see many useful improvements that can take you from "great idea but useless in the real world" to "great idea that I can't wait to use". You have to go through both phases, first figure out what the users really want and deliver, second figure out what else the user needs in order to make it useful. You learn different levels of detail from the different parts, both are critical.
Mawr 3y ago
talking to users != blindly implementing what they say Users are amazing at indentifying issues, but poor at coming up with solutions to them. User feedback often needs converting to be usable. "I'd like my horse to be faster" -> "I'd like to get to my destination faster".
dahart 3y ago
> Build something great and they will come. Have you done this successfully yourself? You’re saying the opposite of what many people with startup experience recommend. I found out why ‘build something great and they will come’ is usually not true, the hard way, by blowing my own savings along with other people’s investments doing it. Great products almost never go viral on their own, they need tons of iteration and feedback. Most developers who have a truly great idea, including yours truly, don’t understand that their great idea doesn’t appeal to most people, or like in my case that people like the idea but they each have 3 different things they consider much more important, and you can only find out which great ideas have mass appeal by talking to a lot of people. Normally, the wise startup advice is to listen deeply to a lot of people, to not jump to implement exactly what they’re asking for, but hear more broadly what their problems are and what they need. The advice is not to stop listening and ignore them, and it is not to consider listening a waste of time, the advice is to listen first and then read between the lines. ‘Build it and they will come’ is practically an anti-meme in the startup world, you can find tons and tons of examples of this failing to work, and tons of examples of wise people with experience advising to get this idea out of your head ASAP.
- deleted 3y ago
  [deleted]
- MrOwnPut 3y ago
  I'm not saying don't market it. But I'm also saying you should have a better vision than "well gee what should we make, world?" That's pretty pathetic. Have passion in what you want to do, it should be personal. If you have a problem, there's countless others with that same problem. Showing it to them and pointing out the problem is hard, yes.
  - dahart 3y ago
    This isn’t what @onion2k was talking about, so straw man, no? You’re also talking in platitudes. Having a passion for what you do isn’t a recipe for good business, and isn’t necessary. It might be great for you, if you want. But people with actual experience have learned this repeatedly.
JohnFen 3y ago
> Users generally have no idea what they want, especially related to novel things. This gets uttered like a mantra, and there is a kernel of truth to it, but people often take the idea too far -- so far that it becomes false. People generally know what they want to accomplish. People generally know what workflows work for them. Around the edges, they may not be aware that a particular change will improve their lives -- but in the main, they're pretty good at telling that. > If you waste time listening to the masses and have no initial vision of your own You need both. > Build something great and they will come. This is not generally true, and I've seen many, many ventures fail because they believed this. History is jam-packed with objectively great things that were build but were rejected by the masses. I think this mostly happens because the great thing did not address what people really wanted, and the company did not properly determine what people wanted. You can build the greatest doohicky ever made, but if it doesn't actually meet a real need in people, nobody will come.

onion2k 3y ago

Build something great and they will come. They won't stay though, because their opinion is unlikely to be the same as your opinion, and people only spend money on things that they think are good. You might believe your app is the greatest thing in the world, but that doesn't matter at all. You're not trying to persuade yourself to buy; you need to persuade your customer that the app is good. Clue: They're not looking at the code. Also, 'good' is a measure of usefulness rather than quality. People will spend a lot of money on absolute trash if it solves a problem that's costing them more money or time than your app, no matter how bad your app is.

MrOwnPut 3y ago
I'm not specifically talking about code quality, but usually that goes hand in hand with the product. An engineer that makes quality code will usually also care about the product quality overall as well. Good code quality makes that quality product maintainable and fun to work in. That being said, your product's traits are phenotypes of your code design. Its performance characteristics, its capable features, how it scales, everything is intertwined. Involve your developers more in the product planning, don't try to plan it for them and just hand them a spec. I've seen too many "product managers" and officers try to be engineers... That's like a real estate tycoon making blueprints for an architect. You will probably fail if you want to "do high quality code later" as your product will be shit because it's DNA is trash. And yes, you are trying to persuade yourself, you should be user #1 and your ultimate fan. Find a problem you have or recognize, and develop a solution you believe in. Others can barely even recognize there is a problem in the first place, let alone find the optimal solution. You can listen to others for minor adjustments after the fact, but your product vision is solely on you.
- preommr 3y ago
  Another day, another argument on "If I asked my customers what they wanted they would've said faster horses" vs "Move fast and break things".
  - MrOwnPut 3y ago
    I wasn't saying "move fast break things", at all. Nearly the opposite in fact. Take your time and build something you know is great.
  - JohnFen 3y ago
    > "If I asked my customers what they wanted they would've said faster horses" The thing about this saying is that it ignores what the customers actually said they wanted. People who have a need will generally have a solution in their head. Saying they want "faster horses" is saying two things: what they want (faster travel) and their stab at a solution (horses). Ignoring what a customer says they want is a recipe for missing the mark. Accepting the solution they have in their mind at face value is also a recipe for missing the mark. What should be done is to listen to the customers and take them seriously, then work out a solution. That solution might, indeed, be "faster horses", or it might be something else entirely. But you won't get to a great solution by pretending people don't know what they want.
    - MrOwnPut 3y ago
      You're ignoring the part of how obvious the request is overall. Everyone wants faster travel, you don't need to ask anyone for that, it's not a vision.

bluGill 3y ago

You are both right, because you are talking about very different parts of the development cycle. When you are coming up with product ideas users have no idea what they want. When you show the user what they really want though they can see many useful improvements that can take you from "great idea but useless in the real world" to "great idea that I can't wait to use". You have to go through both phases, first figure out what the users really want and deliver, second figure out what else the user needs in order to make it useful. You learn different levels of detail from the different parts, both are critical.

Mawr 3y ago

talking to users != blindly implementing what they say Users are amazing at indentifying issues, but poor at coming up with solutions to them. User feedback often needs converting to be usable. "I'd like my horse to be faster" -> "I'd like to get to my destination faster".

dahart 3y ago

> Build something great and they will come. Have you done this successfully yourself? You’re saying the opposite of what many people with startup experience recommend. I found out why ‘build something great and they will come’ is usually not true, the hard way, by blowing my own savings along with other people’s investments doing it. Great products almost never go viral on their own, they need tons of iteration and feedback. Most developers who have a truly great idea, including yours truly, don’t understand that their great idea doesn’t appeal to most people, or like in my case that people like the idea but they each have 3 different things they consider much more important, and you can only find out which great ideas have mass appeal by talking to a lot of people. Normally, the wise startup advice is to listen deeply to a lot of people, to not jump to implement exactly what they’re asking for, but hear more broadly what their problems are and what they need. The advice is not to stop listening and ignore them, and it is not to consider listening a waste of time, the advice is to listen first and then read between the lines. ‘Build it and they will come’ is practically an anti-meme in the startup world, you can find tons and tons of examples of this failing to work, and tons of examples of wise people with experience advising to get this idea out of your head ASAP.

deleted 3y ago
[deleted]
MrOwnPut 3y ago
I'm not saying don't market it. But I'm also saying you should have a better vision than "well gee what should we make, world?" That's pretty pathetic. Have passion in what you want to do, it should be personal. If you have a problem, there's countless others with that same problem. Showing it to them and pointing out the problem is hard, yes.
- dahart 3y ago
  This isn’t what @onion2k was talking about, so straw man, no? You’re also talking in platitudes. Having a passion for what you do isn’t a recipe for good business, and isn’t necessary. It might be great for you, if you want. But people with actual experience have learned this repeatedly.

JohnFen 3y ago

> Users generally have no idea what they want, especially related to novel things. This gets uttered like a mantra, and there is a kernel of truth to it, but people often take the idea too far -- so far that it becomes false. People generally know what they want to accomplish. People generally know what workflows work for them. Around the edges, they may not be aware that a particular change will improve their lives -- but in the main, they're pretty good at telling that. > If you waste time listening to the masses and have no initial vision of your own You need both. > Build something great and they will come. This is not generally true, and I've seen many, many ventures fail because they believed this. History is jam-packed with objectively great things that were build but were rejected by the masses. I think this mostly happens because the great thing did not address what people really wanted, and the company did not properly determine what people wanted. You can build the greatest doohicky ever made, but if it doesn't actually meet a real need in people, nobody will come.