Training Data
Defining a Problem: The Ticket That Taught Me About It
Four drafts. One alert ticket. A lesson about why understanding the problem — really understanding it — has to come before anything else. And why drawing it out on paper first was not a waste of time.
On my first week, I was given a task: write a ticket for an alert that would flag Sales Orders sitting unshipped for too long. It sounded clear enough. Orders were getting stuck in the warehouse for more than 3 days and are not picked up by the courier. No one was noticing. Write the ticket so the team can build something to fix it.
What followed was four drafts — each one exposing a different mistake in my thinking. By the time I had a version worth submitting, I had learned something I could not have been handed directly: that the way you name a problem determines whether the solution is useful or just busy work.
What Drucker Really Meant in Practice
A slide from training introduced Drucker’s data principles: Effective, Reliable, and Rapid. I initially thought these were code guidelines. In reality, they apply before writing a single line — at the moment you define the problem.
Effective
Start with why. A problem is defined when you explain why the gap matters to the business.
Reliable
Use evidence, not guesses. Support your problem statement with real data and checked examples.
Rapid Iteration
Improvement in each cycle. Timebounding deliverables and ensuring continuous improvement with each cycle of iteration.
The intern lesson: Before writing a ticket or building a tool, evaluate your problem statement against Drucker’s three test questions:
1. Effective: Is this ticket effective in covering the problem and leading an engineer to a fix?
2. Reliable: Is it backed by concrete evidence rather than assumptions?
3. Rapid: Am I making progress towards actually solving the problem, or is this draft getting me nowhere?
Start With Paper, Not a Screen
Before typing a ticket, draw the process on paper. I mapped out the order lifecycle and listed every delay cause — customer, courier, warehouse, and system. Notes felt messy, but paper forced me to see where I was tangling distinct issues.
Writing down the process flow of a sales order from when the customer starts an order till its delivered; Writing out the Reality vs Expectations and mapping it. This helps to identify any gaps in the system.
Writing down every possible cause before deciding what belongs in the problem, then separating responsibility to what VATICO needs to be concerned about
Instead of asking, “What can delay shipping?” (which gives too many answers), ask: “What part of this process should VATICO see, but currently cannot?” This boundary isolates the true gap — packed orders waiting invisibly for courier handover — separating background noise from core scope.
Main takeaway: Do not start by writing the ticket — start by drawing the process. A messy map reveals what you understand, what you assume, and where the real gap lies.
Don’t Only Stop At Symptoms
My first draft listed every symptom: sync errors, courier API glitches, wrong customer addresses, and warehouse documentation gaps. It was comprehensive, but unhelpful. I was mistaking downstream symptoms for the core problem.
Listing downstream symptoms provides valuable context — but stopping there without naming the core problem is the mistake.
Define the main problem first. Once the core problem is clear, sub-issues naturally emerge, allowing you to open focused sub-tickets instead of dumping everything into a single solution.
Every symptom on my list was true, but none answered the real question: what single issue makes all of these failures invisible? The problem wasn’t the operational glitches themselves — it was that no alert existed to flag them when they occurred.
Reality vs. Expectation — and Why It Is Easy to Write Both About the Same Thing
Vatico’s ticket framework asks you to state a Reality and an Expectation. My early drafts wrote both sides about the same thing — the absence of measurement.
❌ V1 framing
Reality
We don’t have an alert system to detect when orders stall past the 3-day SLA.
Expectation
We have an alert system to detect when orders stall past the 3-day SLA.
Both sentences say the same thing. Neither describes what is actually happening in the system versus what should happen.
→
✓ Final framing
Reality
Orders 7**44 and 7**43 were created on May 11 and sat packed and ready at the warehouse for 48 hours. Nothing in our system flagged this. They were discovered manually — after the delivery deadline had already been missed.
Expectation
An automated alert flags any packed order that has not been handed to the courier after 72 hours, giving the team time to intervene before the deadline is breached.
Reality describes the system state today. Expectation describes the desired system state. The gap between them is the problem.
The rule of thumb: if you can collapse your Reality and Expectation into a single sentence — “we don’t have X, we need X” — you have described a capability gap, not a system state. Push one level deeper. Ask why no one noticed. The answer to that is your Reality. The state in which someone would have noticed is your Expectation.
Expectationwhat should be
−
Realitywhat is
=
Problemthe gap
What Changed Across Four Drafts
The four drafts did not just improve the wording. Each draft showed me a different mistake in how I was defining the problem. The examples below show the real shift: from broad, solution-heavy thinking to a clearer problem statement.
V1
Before
Problem: Orders are delayed because of customer issues, system issues, courier issues, and warehouse issues.
After
Problem: Packed orders can wait too long for courier handover without anyone noticing.
Lesson: Listing every possible cause is not the same as defining the problem.
V2
Before
Problem: Sync failures across systems may be causing orders to stall.
After
Problem: Orders 7**44 and 7**43 were packed, ready, and still not handed to the courier.
Lesson: A real example is clearer than a guessed root cause.
V3
Before
Reality: We do not have an alert system.
After
Reality: Two packed orders stayed at RT_SHIP for more than 48 hours and were only found manually.
Lesson: Reality should describe what is happening today, not just what tool is missing.
V4
Before
Expectation: Create an alert when orders pass the 48-hour SLA.
After
Expectation: Flag orders at 72 hours, so the team sees confirmed severe delays without too many false positives.
Lesson: A good threshold needs a reason. Otherwise, the alert may create noise instead of action.
The overall shift: I started with “many things can delay shipping.” I ended with “these packed orders waited too long for courier handover, and the delay was invisible until someone found it manually.”
That second version is clearer because it names the gap, gives evidence, and explains why the business needs visibility.
Ask Questions Before You Think You Understand
Trying to make sense of everything alone leads to unverified assumptions that drift the ticket away from the real problem. Asking questions early is how you stop yourself from staying lost.
Main intern takeaway: Ask many questions early — especially in the morning. Not asking questions rarely means you understand everything; it usually means you haven’t uncovered what you misunderstand yet.
Every question sharpens the problem scope, strips away assumptions, and builds a clear foundation reviewers can trust.
