Lesson 2: Start With the Problem

In Lesson 1 you unhooked from the tool. Good. Now the obvious question: if the tech isn't the starting point, what is? The answer is almost always a person with a problem — and finding the real problem is a skill most people are surprisingly bad at.

People can't always name their own problem

Before DoorDash was DoorDash, its founders did something simple and a little weird: they asked small business owners, "Can we follow you around for a day?" Pack boxes, do the accounting, live the actual day. Why? Because asking people to describe their problems usually fails.

"Sometimes it's very, very hard for any customer to tell you exactly what is inside their brain when you ask them what problems they have."

— Tony Xu, DoorDash CEO (Y Combinator)

It was only by hanging around a macaroon shop that they spotted it: a thick booklet of delivery orders the owner had turned down because she couldn't fulfill them. Nobody said "I have a delivery problem." The problem revealed itself to people who showed up and paid attention. That booklet became a multi-billion-dollar company.

The lesson: The stated request is rarely the real problem. "I need a chatbot / a dashboard / an app" is a guess at a solution. Your job is to find the pain underneath it.

Fall for the need, not your solution

Bezos built Amazon's entire strategy on a sneaky-powerful insight: technology changes fast, but what customers want changes slowly. So anchor on the need, and let the tools come and go.

"One of the things that changes very slowly is customer needs. And so you can build a strategy around customer needs that will have durability."

— Jeff Bezos, Italian Tech Week 2025

Customers will never wish Amazon delivered slower or charged more. Those needs are stable for decades. The technology to satisfy them? That's allowed to change constantly. Which is why Bezos's other famous line works so well:

"Be stubborn on the vision and flexible on the details."

— Jeff Bezos

Stubborn on the outcome the customer needs. Flexible on the tool, the feature, the implementation. He even said he'd "rather lose a sale than lose a customer" — because the relationship (the long-term need) matters more than any single transaction.

This is literally the most important skill in systems analysis: requirements gathering. When a stakeholder says "build me X," a weak analyst builds X. A strong analyst asks why until the real need appears — then often delivers something better and cheaper than what was requested. "Stubborn on the vision, flexible on the details" is the systems analyst's motto. The requirement that lasts is the business need; the software to meet it is the detail you stay flexible on.

Quick check

A manager says: "Build me a report that shows every sales number, daily." What's the best next move?

"Every number, daily" is a solution guess. The real need is usually one decision ("Which regions should I call this week?"). Find the decision, and you'll often build something simpler that's far more useful.

Start small — one real problem at a time

Once you've found a genuine problem, resist the urge to boil the ocean. Sabrina's advice for adding AI to a business is the same advice that applies to any tech project:

"Do not try to make your entire business AI on the first shot. You will be overwhelmed… Just start with like one task."

— Sabrina Ramonov

DoorDash launched with a static web page, eight restaurant menus saved as PDFs, and a Google Voice number that rang all four founders' phones. It took under an hour to build and it was held together with tape. But it tested the one thing that mattered: will real people pay to have food delivered? Answer the real question with the smallest possible thing first. Fancy comes later.

🧠 Think like an MIS consultant

The "we need a mobile app" request

A gym owner is convinced she needs a custom mobile app. It'll cost $40,000 and six months. She wants you to start tomorrow. What's your move?

Find the outcome hiding under "app." Why an app? "So members can book classes and stop calling the front desk." That's the real problem — front-desk overload and missed bookings. Now you can test it for almost nothing: a simple booking page link in her existing Instagram bio, this week. If bookings jump and calls drop, you've proven the need before spending $40k. If they don't, you just saved her a fortune. Stubborn on the outcome (easy booking), flexible on the detail (maybe never a custom app at all).

✍️ Your turn

Pick something you use daily (an app, a campus service, a job). What's one problem the people who built it clearly understood — and one they clearly missed?

Someone asks you to "build a website." Write the first question you'd ask to uncover the real outcome they need.

Key takeaway: Start with a person and their real problem — not your favorite solution. Watch, ask "why" until the true need shows up, stay stubborn on the outcome and flexible on the how, and test it with the smallest thing that could possibly work.

← Previous1 · Don't Marry the Tool Next →3 · Stay Tech-Smart Anyway