I think having a good understanding of your problem space results in higher quality & more valuable software.
People say “We write our code in DDD”, which is a bit strange, because DDD is about problem space, not about solution space.
I mostly agree with this. But as seen in baking domain concepts into code and ddd & naming, you can also take some of these concepts with you to the codebase (solution space)
Ubiquitous language, domain, bounded contexts, aggregate, event storming are all about problem space.
Product Engineers
Gergely suggests that product minded engineers should be in tune
with what makes the business tick:
Understand how and why your company is successful. What is the business model? How is money made? What parts are most profitable, what parts of the company are expanding the most? Why? How does your team fit into all of this?