This is a really good take, especially the “solution-first vs problem-first” part.
Something I’ve been running into though is that even when you start with a real problem, there’s still another layer people underestimate: what actually happens after you “solve” it.
We hit this with messaging infrastructure. On paper the problem was clear, the implementation was correct, everything looked fine from the application side. But behavior still varied in ways we couldn’t explain at first.
That’s when it clicked that solving the problem at the interface level isn’t the same as understanding the execution behind it.
Feels like a lot of AI use cases will run into the same thing. You can build something that works in a controlled setup, but once it’s part of a real system, you’re dealing with hidden constraints, data quality issues, timing, external dependencies…
So even “boring AI” can get unpredictable if that layer isn’t visible.
Curious if you’ve seen that as well when moving from prototype to something closer to production.