I do not think design, engineering, and operations should be treated as separate conversations if the goal is to build something durable. The more commercial context the builder has, the more likely the product is to make decisions that help the business instead of just pleasing the roadmap.
Margin changes product priorities
If you know where margin is won or lost, you make different calls. You pay more attention to admin compression, failure states, handover quality, and reporting clarity. You stop fetishising novelty and start protecting the business.
Context creates better trade-offs
When you understand the business model, you can decide what deserves precision now and what can wait. That is one of the biggest advantages of having the same person close to product, code, and operations.
Build for the thing after launch
A lot of software is designed as if launch is the finish line. It isn't. The real test is whether the product helps a team operate better one month later, six months later, and once the edge cases start arriving.