zlacker

>>martin+(OP)
I'd argue 2 types of users are

* People using it as a tool, aware of its limitations and treating it basically as intern/boring task executor (whether its some code boilerplate, or pooping out/shortening some corporate email), or as tool to give themselves summary of topic they can then bite into deeper.

* People outsourcing thinking and entire skillset to it - they usually have very little clue in the topic, are interested only in results, and are not interested in knowing more about the topic or honing their skills in the topic

The second group is one that thinks talking to a chatbot will replace senior developer

>>Punchy+xO
I started to outsource thinking at my job as my company made it very clear that they do not want/cant afford thinking engineers. Thinking requires time and they want to deliver quickly. So they cater towards the very realistic deadlines our PMs set for features (/s). Funnily enough the features have to be implemented ASAP according to the customers, but the customer feedback takes like 6 months due to them using the new feature for the first time 6 months after delivery. I just dont care anymore. Gonna leave the learning part up to my time off, but getting generally tired of the industry as a whole, so just putting in minimal effort to pay my bills until things explode or get better. So for me its definitely outsourcing thinking at work.

>>sevenz+dQ
As a product manager, this makes me think the features you're building are not the things your customers need or want most. I'm curious if you were to ask your product manager about that six-month timeframe, and just ask the open-ended question of is there anything on the backlog that we can build that the product manager thinks users would pick up within days instead of months?

>>Schien+Zw1
As a product manager, this feels like they're in the pretty typical B2B SaaS trap of building the stuff that the people who pay for the product insist they need but the people using the product don't necessarily want, so they've gotta invest a bunch of time and effort getting usage/feedback.

Could be for good reasons (e.g. they're security features that are important to the business but add friction for the user) or just because management is disconnected from the reality of their employees. Either way, not necessarily the wrong decision by the PM - sometimes you've gotta build features fast because the buyer demands them in a certain timeframe in order to get the contract signed. Even if they never get used, the revenue still pays the bills.

>>idopms+6E1
If they were building the stuff the people paying for the product insist they need, it seems unlikely that they'd take 6 months to use it once built. Unless it's some API that takes a ton of work to build to. It didn't sound like they were getting feedback for those six months.

Security features that add friction for the user are usually forced, aren't they?

Contract requirements do make sense, but I get the idea that this user would know that.

What are you imagining that would be actual value but not used for six months?