3 ms·

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

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.

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.