One great addition to this article would be to propose some pragmatic examples and explain ways where people with different engineering philosophies would appro

One great addition to this article would be to propose some pragmatic examples and explain ways where people with different engineering philosophies would approach each example. This can be a risky thing to do because readers in their heads, and people in the comments section "out loud", may end up debating the minutiae of the specific example instead of the broader philosophy. But it's also very pragmatic, which is, like, the point, right. Give us some worked examples of times where the product-minded engineering approach becomes relevant and we'll be readers who are more likely to understand your vision. Let me pick a few examples, I'm not sure all are good/bad, but they're all cases where different kinds of engineers might do different things: (1) We're building a web store. Do we insta-fail all orders that fail a fraud check, or do we let them go through but cancel within 24 hr (before fulfillment) if they haven't been manually reviewed, or what? If the fraud vendor has an outage what do we do with orders we get during the outage? (2) We're building a feature which mirrors something provided by a direct competitor and should really exist. The UI the PM has specified is ugly and he knows it and I know it but we have no design resources committed to the project and timelines are pretty tight. Should I just build what he specced and move on, or what? Is it my job to make sure the business has accepted the limitations of this UI? (3) I was glancing at a pull request that shipped last week and I found a bug in our product which could expose user data to third parties. It's not my code (I used to own this product area on a former team two years ago) and I have other sprint work to ship. Also it's pretty obscure so I doubt anyone is using it, but what should I do with this knowledge? (4) I'm building an internal tool that is supposed to speed up development work. We wrote a spec for the tool based on what the hard parts of the process feel like to us, so, great, right? We're just gonna announce it? Does this feel a little hollow, should we maybe have interviewed some of our peers or colleagues first, or measured their work, to make sure we're building what they need? How do we even do that and how much time should we spend getting good at that before we go full steam ahead on the tooling? (5) A friend showed me a pretty bad bug in our product where sometimes we show a blank screen instead of the data you requested. I checked and it turns out no one is measuring how often that bug happens to anyone, the product is kind of messy in terms of how we gather customer feedback, and it's not on anyone's roadmap to fix. Should I do something about that? What? Just some thoughts.