If you happen to work with engineers and they’re mostly unhappy with the way they’re being asked about potential projects, or if you’re an engineer in this very situation and your colleagues don’t seem to get it, here’s a simple how-to:
Step 1: Describe what the product or service is like when it’s finished, as precisely as you can, from A to Z. Put in the effort to sketch out the interface (if there is one), who does what in which particular order, who needs to know when something has happened, etc. Imagine how people will use it and what their expectations might be. Try to put yourself in every party’s shoes and walk through the whole thing. Think of legal constraints. Write everything down. (Use flowcharts whenever possible. Engineers love flowcharts.) Yep, that’s a lot, but believe me, it’s worth it.
Step 2: Define process boundaries. What is supposed to happen, what must not happen under any circumstance?
Step 3: Define development constraints. What is the budget? How much time is there to get this done?
Step 4: Have a meeting with the engineer(s) and give them all of what you have worked out so far, and they should be able to tell you what you need to know (can we do this in the quality proposed, considering all boundaries and constraints?) on the spot.
Bonus: How to delight engineers and non-engineers alike
Say Thank You, even if the answer you get is not what you were expecting.