Gathering requirements is the cornerstone of every problem, be it a task, project, or whatever you want to call it. And arguably, this is the most important step. Well, if you fail to plan, you plan to fail.

But here is what I have seen after years of working on software projects: the biggest issue is not technical complexity or lack of tools. It is when expectations do not match reality.

So here is what I do now, and honestly, it has saved me countless headaches: I always get the actual result/output sample from the client upfront. This basically eliminates the expectation mismatch. You will deliver at least 80% or more of what they actually wanted, which is way better than hearing “what I expected is completely different” three weeks in. That would be a disaster.

The Simple Truth #

Over time, I have boiled this down to something simple:

Work Completable ⟺ (Input Sample ∧ Output Sample)
Where:⟺ means "if and only if" (necessary AND sufficient)∧ means "AND" (both must be true)

That is it. Both need to exist. Both need to be clear. If either is missing, you cannot complete the work properly. It sounds obvious when you say it out loud, but you would be surprised how many projects kick off without one or both of these.

Think about it: you cannot transform undefined inputs into undefined outputs. You need the source, sample input, structure, format, the whole thing. And you need to know what success looks like. It is like two sides of a coin. You need both to make it work, fair and square.

If you have this input/output combination locked down, you basically skip most of the problems that derail projects. You will be sure you are on the right track from day one.

Let me show you what I mean with real examples.

Example 1: API Integration Gone Sideways #

What the client said: “We need to integrate with the payment gateway.”

What was missing:

  • Input Sample: Which endpoints? What authentication? What data format?
  • Output Sample: What response should our system expect? How do we handle failures?

Result: Work Completable = FALSE

What should have happened:

Input Sample (Request Data): POST request to /api/v2/payments, Bearer token auth. Actual payload example:

{  "amount": 99.99,  "currency": "USD",  "customer_id": "cust_abc123",  "payment_method": "card_xyz789"}

Output Sample (Expected Response): Success returns HTTP 200 with:

{  "transaction_id": "txn_456def",  "status": "completed",  "timestamp": "2024-11-04T14:30:00Z"}

Plus sample failure response: HTTP 402 with error code.

Result: Work Completable = TRUE

With both of these? You are on the right track. Without them? You are building something, but who knows if it is the right thing.

Example 2: Report Generation Feature #

Vague ask: “Users need to export their data as reports.”

Input Sample: Not provided

Output Sample: Not provided

Work Completable: FALSE

Complete ask:

Input Sample: User clicks “Export” button on dashboard showing their last 30 days of activity. Actual data structure from test account:

{  "user_id": "usr_123",  "transactions": [    {"date": "2024-10-15", "description": "Payment received", "amount": 150.00, "status": "completed"},    {"date": "2024-10-18", "description": "Refund issued", "amount": -25.00, "status": "completed"}  ]}

Output Sample: PDF file with company logo, table format showing Date, Description, Amount, Status. Grouped by week. Actual mockup or sample PDF showing fonts, spacing, colors.

Input Sample: Provided

Output Sample: Provided

Work Completable: TRUE

One is a philosophical discussion. The other is a checklist.

Example 3: File Upload Feature #

What kills projects: “Let users upload their documents.”

Input Sample: What file types? What size? Sample files? Output Sample: Where stored? What feedback? Error handling? Work Completable: FALSE

What saves projects:

Input Sample: User uploads via drag-and-drop. Three actual test files provided:

  • valid_doc.pdf (2MB, properly formatted)
  • corrupted_file.docx (intentionally broken)
  • oversized_image.jpg (15MB, exceeds limit)

Output Sample: Screenshots showing progress bar at 45% with “Uploading…” message, success state showing “File uploaded successfully” with thumbnail preview, error state showing “File exceeds 10MB limit” with red border.

Input Sample: Provided Output Sample: Provided Work Completable: TRUE

Both sides of the coin, again.

Making This Stick #

This is not just about being thorough. It is about changing how we think about requirements.

Before starting any work, verify both conditions:

  1. Input Sample exists? Actual examples, actual format, actual edge cases including failure scenarios.
  2. Output Sample exists? Mock-ups, screenshots, sample files showing what “done” looks like.

If either is FALSE, then Work Completable = FALSE. Do not start coding.

The Reality Check #

Most software disasters I have seen happen because someone violated this equation. We started work when one or both sides were undefined. We assumed the data format. We assumed what the client meant. We assumed “high priority” meant the same thing to everyone.

This equation kills assumptions. It forces everyone (clients, stakeholders, product managers, your own team) to get specific upfront.

And yeah, sometimes clients push back. “Cannot you just start and we will figure it out?” That is when you explain: you cannot transform undefined inputs into undefined outputs. You will definitely create something, but probably not what anyone wanted.

The Bottom Line #

This applies to most tasks in software development. It addresses the biggest issue we face: unclear requirements. Whether it is a client, a product manager, or another team, we need both input and output samples as complete as possible before starting.

We are all probably doing some version of this already. But making it explicit, making it your non-negotiable starting condition, keeps everyone happier and gets the job done right.

Two sides of the coin. Both matter. Always.