><i>Their suggestion on emergency incidents is 30 minutes response 24/7.</i><p>Why 30 minutes? Why not 29 minutes? Why not 31 minutes?<p>We worked on a project with a client to predict a certain event which, if it happened, would result in a loss of about $100MM (that's a hundred million dollars).<p>During that conversation, the client said they'd like us to predict the event 48 hours before it occurs. My question right off the bat was: Why 48 hours? There was some answer.<p>My next question was: at what point is it too late to notify you?<p>The client said: never too late. Even if you predict it two minutes before it occurs, we have ways to mitigate the damage and procedures. We can do something to save the situation.<p>It went from 48 hours to 2 minutes, and the ML team was happy because these are really two different things to tackle.<p>Therefore, it is useful to ask about what they are trying to do? What systems are impacted? Where's the urgency?<p>One must be careful not to take client's solutions as a problem statement, but to discover the underlying problem they are trying to solve.<p>Here's another example of an informal conversation with a friend: the friend asked me "How do you solder a copper wire to a thin metallic plate"?<p>I could have just answered the question, but instead I asked "What are you trying to do?"<p>He said he had this fuse but the wire in the fuse melted, so he wanted to use a thicker wire for the fuse. I replied that it's the job of the fuse to die to save downstream equipments, and if he did that, he'd save a fuse but ruin costly equipment. The fuse did its job.<p>"Solder a thicker wire to a metallic plate" was what he thought the problem was, but it was his solution. A poor solution to the underlying problem.<p>Here's another example:<p>One project was stuck before we were involved and doomed to fail because "of the client". We went there. Big table with a bunch of people from legal, security, data, etc. They said there was no way they'd do what our company asked.<p>So we slid a sheet of paper and a pen and asked them "What are we asking? Can you draw the data flow?". We were hunched on each part of the big table over that piece of paper. Their security engineer drew the flow (VMs and different systems, our system). We smiled and said it's really not what we're proposing. We drew the actual thing, and he said "Oh, if that's the case then I don't have any objection". Unanimous sigh.<p>That was a mid six figure project unlocked just like that.<p>Asking questions and digging deeper and helping people figure out what they actually are trying to do really is a good way to find better solutions.