> if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution I think you're on the right track here, but from the wrong

> if you aren't coding the solution to the problem, you shouldn't be allowed to define the solution I think you're on the right track here, but from the wrong direction. You pretty much stated it earlier: > the only way you can avoid that is by almost annoyingly probing to find the root of problem I approach this as: if someone brings a solution, mostly ignore it and start asking "why?" until you're back at a root answer like "so my business can make money". I can't even count the number if times someone has proposed a solution where I've done this and not only ended up with something simpler and faster to build, but a better or more complete solution. This often comes in like "just build a button to export this data to csv", which if you probe is actually "..So I can get it into Excel easier" ... "So I can reformat it to bring to this other system". The result is something like "what if we push the data to their API, that we already have integrated with, once every hour?" Sometimes it's software, sometimes it's not, mostly it ends up being a mix -- but importantly if you don't ask "why" enough, you'll solve the wrong or at best only an intermediate problem.