Building AI that works requires three types of understanding:
- Understanding the user's reality and what value means to them
- Understanding what AI systems can and can't do, what approaches fit what problem shapes
- Understanding the domain mechanics well enough to judge correctness
Traditionally, the first is "product." The second is "engineering." The third is neither — or both.
But these don't live neatly in separate roles. The work happens at the intersection. You can't shape the problem well from only one side.
The failure modes of splitting it
If product owns problem-shaping alone:
- The problem gets defined in user-value terms but not in technically precise terms
- "We need AI to make procurement easier" — sounds clear, means nothing to build against
- No understanding of what's actually feasible given the data and the state of AI
- Evaluation criteria are vague or unmeasurable
- The spec describes a wish, not a buildable system
If engineering owns problem-shaping alone:
- The problem gets defined in technically convenient terms
- The system optimizes for something measurable but not valuable
- Edge cases that matter to users get ignored because they're hard
- "It works" means "it runs" not "it solves the problem"