This article is outlining when the feature is done (as clarified in the first paragraph), not when the software is done. The difference is the feature is a product problem, rather than an implementation of software problem. The software problem is done when the requirements are properly implemented and bugs are fixed or non-existant.
If the question is if the user is liking it, that's a product problem. It's a different domain than the software implementation.
Hmmm. That's an understandable perspective, but I don't think that splitting things up between product and engineering is of much benefit or interest to the end user.
That's fair, and increasingly true as we have AI tools that blur the line more and more. Personally I'd still make the distinction, even though I know the industry likes to blur these two as much as possible, but that's just my preference. I think each of these roles have a chance to specialize in ways that if you're splitting your time between them, that specialization might not happen.
This article is outlining when the feature is done (as clarified in the first paragraph), not when the software is done. The difference is the feature is a product problem, rather than an implementation of software problem. The software problem is done when the requirements are properly implemented and bugs are fixed or non-existant.
If the question is if the user is liking it, that's a product problem. It's a different domain than the software implementation.
Hmmm. That's an understandable perspective, but I don't think that splitting things up between product and engineering is of much benefit or interest to the end user.
That's fair, and increasingly true as we have AI tools that blur the line more and more. Personally I'd still make the distinction, even though I know the industry likes to blur these two as much as possible, but that's just my preference. I think each of these roles have a chance to specialize in ways that if you're splitting your time between them, that specialization might not happen.