How One Problem Travels

What you'll learn

See the full chain a business problem travels, from boardroom to measured result
Know what a hand-off is, and why most projects fail at one
Place your own job somewhere in the chain

Ten desks, one problem. Nobody in this chain can succeed alone, and each one inherits the decisions made before them.

There is a story people tell about artificial intelligence at work, and it goes something like this: a company has a problem, a clever data scientist builds a model, and the problem goes away. It is a tidy story. It is also wrong in a way that costs real companies millions, because it leaves out the nine other people whose decisions determine whether that model is any good, whether anyone is allowed to use it, and whether anybody ever finds out if it helped.

This course follows one problem — a real-shaped one — through every desk it lands on. You will not be asked to run the project. You will be shown, step by step, what each person is actually deciding, why they decide it that way, and what they pass to the person after them. By the end you will be able to look at any data or AI project in your own organisation and say, with confidence, this is where we are, this is who is waiting on whom, and this is the hand-off that is about to go wrong.

The problem we will follow

One company, one decline, one project — for all twelve modules. The specifics matter, because vague problems produce vague projects.

Meet Northwind. They sell workflow software to 400 other businesses. Last year they booked $11.3m; this year they are tracking to $9.6m. That is a fall of about 15%, and it is not because they stopped selling — it is because customers keep cancelling. Roughly 18% of accounts left in the last twelve months, against a normal year’s 9%.

That is the sum total of what anyone knows on the Monday morning our story starts. Notice what is missing: nobody knows which customers are leaving, or why, or whether anything could have been done about it. The executives each have a theory. Sales says the product is stale. Product says the pricing is wrong. Marketing wants a bigger discount budget. All three might be right; all three might be noise.

The most important sentence in this course

The company’s problem is not that customers are leaving. The problem is that nobody knows why, so every proposed fix is a guess. Almost every good decision in the next eleven modules comes from someone insisting on that distinction.

What a hand-off actually is

A hand-off is not a meeting. It is a piece of finished work with a name on it, moving from one desk to the next.

Ask people how work moves through a company and most will describe meetings. Meetings are where hand-offs get discussed, but the hand-off itself is always a thing: a one-page mandate, an approved budget, a requirements document, a labelled spreadsheet, a data table, a model, a written approval, a released system, a set of logged actions, a result.

Each of those things has three properties worth watching all the way through this course. It has an author — one person accountable for it. It has constraints baked in — decisions someone else already made, which the next person inherits whether they like it or not. And it has assumptions that are invisible unless someone says them out loud — which is exactly how a project can look healthy for five months and then collapse in week twenty-three.

Four words you will hear at every desk

Hand-off: The moment finished work moves from one role to the next, along with responsibility for it. Good ones are written down; bad ones happen in a corridor.
Deliverable: The actual artefact being handed over — the document, the dataset, the deployed system. If you cannot name it, the hand-off has not happened yet.
Constraint: A limit inherited from an earlier decision — a budget, a deadline, a rule, a definition. Constraints travel downstream and are rarely revisited.
Downstream: Everyone after you in the chain. “It’s a downstream problem” usually means “it will be someone else’s problem, later, and worse.”

The ten jobs, and the question each one owns

Each desk exists to answer one question the previous desk could not.

Here is the whole chain in one pass. Each role is a job to be done, not a job title — in a small company one person might hold three of these, and in a large one each might be a department of forty.

The chain, in order

Chief Information Officer: Why are we doing anything? Turns a falling number into priorities, and decides where money goes before anyone writes code.
Finance Business Partner: Is it worth it? Converts an ambition into a spending limit and a minimum acceptable result.
Product Manager: What exactly are we building — and what are we refusing to build? Turns goals into requirements a team can act on.
Customer Success Lead: What is actually happening out there? Supplies the human truth the data cannot see, and says which customers are genuinely at risk.
Data Analyst: Where and when did this start? Finds the problem’s shape in the history — which segments, which moments, which behaviours.
Data Engineer: How does this data arrive, reliably, every night? Turns a one-off analysis into plumbing that works unattended.
Data Scientist: Who is at risk right now? Builds the model that turns past patterns into a forward-looking estimate.
Risk & Governance Lead: Should we use it this way? Decides what the model is allowed to do, who may see it, and who owns it when it drifts.
ML Engineer: How does this become something people actually use? Turns a prototype into a system that runs at 2am without anyone watching.
CS Operations Manager: What do we do about it? Converts a ranked list into human action — the only step that saves an actual customer.
Product Analytics Lead: Did it work, or did we just get lucky? Designs the comparison that separates real impact from wishful thinking.
The board: What now? Weighs the result against the original promise and decides what to scale, fix, or stop.

Read that list again and notice something: only one of those twelve entries mentions a model. The AI is a single link in a chain of twelve, and it is entirely dependent on the four links before it and useless without the four after it.

The software this chain runs on

Four families of software, one problem — and most people only ever see one of them.

The same problem, four different rooms. Almost nobody in a company sees more than one of these screens.

Software follows the same chain the work does, and each family answers a different question. Reporting tools such as Power BI or Tableau turn thousands of rows into a picture, which is how problems get noticed at all. Spreadsheets and planning tools — Excel, Anaplan — are where the money argument actually happens, whatever the slide deck says afterwards. Data platforms such as Azure Data Factory, Databricks and dbt move and clean the information so it can be trusted unattended. And operational systems — Salesforce, Gainsight, ServiceNow, Outlook — are where a decision finally becomes something a customer experiences.

The pattern worth remembering is the last one. Every module in this course ends with output landing in a tool somebody already uses. That is not a technical detail, it is the difference between a project that changes behaviour and one that produces a dashboard nobody opens. When you hear an engineer say the scores will be “written into the CS platform”, they are describing the single design decision most likely to determine whether any of this works.

The four families, and what each is for

Reporting and BI tools: Power BI, Tableau, Looker. Turn many records into a picture people can argue about. Where problems are noticed.
Spreadsheets and planning: Excel, Anaplan. Where business cases, budgets and scenarios are actually built — including the ones presented as slides.
Data platforms: Azure Data Factory, Databricks, Snowflake, dbt. Move, clean and test data on a schedule so nobody has to do it by hand.
Operational systems: Salesforce, Gainsight, ServiceNow, Outlook. Where work actually happens, and therefore where any output has to land to matter.

The chain is not a relay — it is a rope

In a relay, once you have passed the baton your race is over. In a real project, your decision keeps acting on people months after you have forgotten making it.

This is the idea the whole course is built to demonstrate, so it is worth stating plainly before we start.

When the CIO decides in module 2 how to split the budget, he is not just funding teams. He is deciding whether a training budget exists — which decides, in module 11, how many customers the support team can realistically help in a week. When Finance sets a spending limit in module 3, that number is still binding in module 10, when an engineer is choosing between a simple nightly job and an elegant real-time system. When the Product Manager chooses which warning signs to track in module 4, she is writing the vocabulary the data scientist is allowed to think in five months later: a signal nobody chose to collect is a signal the model can never use.

None of those people intend to constrain anyone. They are just doing their jobs. But their decisions travel, and by the time the consequence shows up, the person who caused it has moved on to something else. That is not a failure of individuals; it is the normal physics of organisations. Understanding it is most of what “being good at working across teams” actually means.

Where these chains usually break

Four places, in order of how often they cause damage. One: the business goal was never defined, so every later decision is arbitrary. Two: two teams use the same word for different things — “churn”, “active user”, “done” — and nobody notices for months. Three: a hand-off happens verbally, so the constraints and assumptions vanish. Four: the last step — proving whether it worked — gets skipped, so the organisation learns nothing and repeats itself.

Where your own work sits

You are already in this chain somewhere, even if your job title appears nowhere in it.

You do not need to be in a data team to be in this story. If you set budgets, you are at desk one. If you write requirements, or define what a word means in a report, you are at desk three. If you talk to customers and know things the dashboards do not, you are at desk four, and the quality of what you write down determines the quality of a model you will never see. If you run a team whose week gets filled by an automated list, you are at desk eleven, where all the value in the project is finally created or lost.

As you go through the remaining modules, keep one question running: what did the person before me assume, and does it still hold? That single question, asked out loud in a meeting, prevents more expensive failures than any piece of technology in this course.

The bottom line

A business problem does not get solved by a specialist — it travels through ten jobs, each answering a question the last one could not, each handing over a named deliverable with constraints baked into it. The model is one link. The chain is the project, and the chain is where projects break.

Who owns which question?

Read each question and decide which desk owns it, then tap a card to flip it and check.

Quick check

1. In this course, what is Northwind's actual problem on day one?

2. A hand-off is best described as…

3. Why does the course call the chain "a rope, not a relay"?