Still in that first Riverside conference room. Dana's just walked you through the operation, and now you ask for everything at once: the throughput, the product, the building, all of it, now. Here's what comes back.
"Throughput. Our current peak is 18 cartons per minute across all three doors combined. I want the new system designed for 20 cartons per minute. That gives us headroom for the growth I am projecting over the next three years."
"Volume split at the doors. Carrier A at Door 1 gets about 55 percent of our outbound volume. Carrier B at Door 2 gets 35 percent. Door 3 is the remaining 10 percent."
"Product mix. I will have my team pull a WMS report and send you the exact data."
"The building. 28 foot clear height. Sealed concrete floor in good condition. We have 480 volt three phase power available at two panel locations. One in the northwest mechanical room and one near the southeast corner. Zone A picking is on the second floor. The mezzanine deck is at 16 feet above finished floor."
Four categories of engineering input, clean, in one pass. That didn't happen because Dana is unusually organized. It happened because you asked for all of it and gave her room to lay it out. The quality of the answer traces straight back to the quality of the question. That's the craft of discovery, and this lesson is how you build it.
By the end of this lesson you can walk into a discovery meeting prepared instead of blank, run the conversation across all six categories of information an engineer needs, and turn what you heard into a requirements document the customer will sign off on before you design a thing.
Discovery isn't a form you make the customer fill out. It's a conversation, and there's a skill to it beyond knowing which questions to ask. How you show up decides whether the customer opens up or shuts down. Five things carry the room.
Michael's first real question in a discovery meeting is almost always the same one: "What made you reach out to us?" Sit with why that beats "what do you need?" One asks the customer to hand you a diagnosis they aren't qualified to make, and most will answer it with a product. The other asks them to describe the pain that made them pick up the phone, and pain is a symptom you can trace to a problem. Write down what each question actually asks the customer to do. The difference is the lesson.
A complete discovery covers six categories of information. Miss one and you carry a hole into every calculation and drawing that follows. You won't ask these in order like a checklist, that's the fastest way to make it feel like an interrogation, but by the time you leave you need all six filled in. Each one comes down to two or three questions that do the real work.
What are you moving, and what are the biggest and smallest packages in it? How many SKUs do you carry, and what's the A, B, C rotation? Any special handling: temperature, fragility, hazmat?
How many orders and units ship per day, per hour, and at peak, and what does peak actually look like? How do goods come in: pallets, loose cartons, mixed? How do orders leave: full pallets, split case, parcel, LTL, truckload, and which carrier handles each of those?
How many people work this area, across how many shifts? Which manual tasks eat the most labor, and where are people working hardest? Is the plan to grow the team, hold it steady, or shrink it through automation?
What WMS and ERP are you running? What conveyor, sortation, or automation is already in place, and what would a new system have to connect to? Get the names and write them down. The deep dive comes later, in Part V. Today you just need to know what's there.
What are the building dimensions, the column spacing, and the clear height? How many dock doors, inbound and outbound, and where are they? What's in the way: mezzanines, floor drains, sprinkler drops, utility runs, and is there room set aside to expand? And treat the floor itself as a design input, not a detail: how flat is the slab, since flatness drives conveyor leg-leveling and alignment over a long run, and what's its load rating, whether the slab or the mezzanine can carry the equipment plus the product on it?
What's the real driver: labor reduction, throughput, accuracy, capacity? Is there a hard go-live date behind it, a lease or a contract or a peak season? And the one that matters most: what does success look like to you in year one, and in year three?
Holding back a question because you're afraid it'll make you look uninformed. New engineers do this constantly, and it's one of the most expensive habits in the field. They walk out of a meeting missing something critical because they were embarrassed to ask for it. The customer will never respect you less for a thoughtful question. They'll respect you less for the proposal you build on a guess you could have just checked.
If the customer says "we want to automate everything," then ask what success looks like in year one before you get excited with them. Tradeoff: it slows the momentum in the room, and it can feel like you're throwing water on their enthusiasm. Verify: the answer tells you appetite from ambition. A concrete year-one picture means they're ready to invest. A vague one means they like the idea of automation more than they've thought through the reality of it, and you design accordingly.
A customer will happily answer a hundred questions from an engineer who clearly wants to understand their operation. What they won't forgive is a proposal built on assumptions, because they can feel the guesses in it. Early in my career I was terrified that asking too much would make me look green. I had it backwards. The questions are the credential. Nobody has ever walked me out for asking one more. Plenty have quietly stopped trusting the engineer who pretended to already know.
Every discovery meeting ends with one deliverable, and it isn't a proposal. It's a written statement of requirements: a summary of what you learned and what engineering has to achieve. You write it, you share it, and you get the customer to confirm it before you design anything. It reads back their operation in your words, so any gap between what they meant and what you heard surfaces now, on paper, instead of six months later on the floor.
The document does something a handshake can't: it protects both sides when the scope moves. A customer who approves a requirements document has agreed to a shared understanding of the problem. That's not paperwork, it's scope control. When someone asks in month four for something that was never in the document, you have a dated record of what you both agreed the problem was, and a calm place to start. Skip the sign-off and every later disagreement becomes your word against theirs.
Strip away the categories and the deliverable and here's what discovery is actually for. Somewhere in that building is a person who's tired of firefighting the same problem, and your whole job is to hand that person a process they can stop babysitting. You're not there to sell them the most system you can. You're there to understand them well enough to give them peace in their own operation. Get the discovery right and the rest of the engineering exists to deliver exactly that, and nothing they didn't need.
You've now been through all of Part I with Riverside. The voicemail, the operation Dana walked you through, what you read off the floor for yourself, and the answers you just pulled on throughput, volume split, product, and the building. It's time to make it a document.
Open your Riverside note and draft requirements document v1. Walk the structure above and fill every section you can from what you've gathered so far. Where you're still missing something, don't fake it, write it into Open Questions. This draft is the deliverable Part I has been building toward. Everything after this designs against it.
This is the only lesson in Part I without a calculator, a spec, or a drawing, and it's the one the other thirty-four stand on. The product you capture here feeds the package analysis. The throughput feeds the rate work. The interfaces you name feed the controls design. The appetite you read shapes how you scope and present the whole solution. A weak discovery produces weak inputs to every calculation, selection, and drawing downstream, and no amount of clever engineering later recovers what you didn't ask for now. Understand before you engineer, and the rest of the program feels almost obvious, because you already know the problem you're solving.