intermediateProblem Framing

The Dashboard That Must Be "Live"

Work from the brief alone. Write what you would produce — actors, requirements, data, a first slice, your unknowns — before opening anything below it; the exercise stops working if you read the reality first.

The brief you were given

The sales team asks for a "live" analytics dashboard of revenue, orders and top products for the online store. The proposed design streams every order event through a processor into a real-time store. Frame the problem before evaluating the design: what does "live" mean, to whom, and what does it cost at each answer?

Your attempt

Nothing here is checked. It exists so that the reveal below is a comparison rather than a reading.

The trap — the move that looks like progress and is not

Building the streaming pipeline because "live" was in the request. It produces an impressive architecture with numbers that update every second, and the first time the CFO compares the dashboard with the finance report they differ — because the stream counted an order that was later refunded and nobody defined what revenue means — and the problem that was never framed arrives as a credibility incident.

Read this even if you are confident. It is here rather than behind a button because it is the move most people actually make, it produces things that look like a project, and its cost arrives when the first hard requirement has nowhere to go.