3 ms·

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

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

MrOwnPut 4y 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 4y 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 4y 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 4y 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 4y 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.