Decision-making Work & ambitions

How to find the right problem to solve

Describe the observable problem before choosing a solution.

Compare plausible explanations, inspect evidence that can distinguish them and test a bounded correction. The booking example below shows why a software request is not yet a diagnosis of the problem.

Want new features first?

Start with three things you can do today

A starting goal

I want to get better at solving messy problems. Help me separate symptoms from causes, question assumptions, and test a promising explanation before choosing a solution.

Change any word so it fits your situation. The course is built from what you type and a few setup questions.

Start today

Three things you can do before the course exists.

Useful on their own. The course is for when you want the whole skill, not just the first move.

Rewrite the proposed fix as an observable problem
Original example: 'We need a new booking app' becomes 'Three bookings this week had the wrong room.' The second statement can be checked without assuming software replacement is the answer.
Compare possible explanations
The room names may be unclear, a saved template may be outdated, or a manual change may not have reached the calendar. Inspect the affected records and the actual workflow before choosing one explanation.
Test a bounded correction
If an outdated template is confirmed, correct it through the authorized process and inspect subsequent bookings. Record what changed and whether the problem recurred. One successful case does not prove every booking error has the same cause.

Best for: Decision-making
Prerequisites: None. Bring the situation you have.
Course length: 7 to 30 lessons
Pace: Yours. One lesson at a time, as often as you like.
Format: Read it, or play the audio
Access: Available on the App Store and Google Play, with an optional early testing list

Before the course is built

Setup asks about your situation first.

Lesson 1 opens on the moment you describe, and the examples use your role. For this request, expect questions like these.

What kind of problems do you face: operational, people, technical, or personal?
Do you tend to jump to solutions, or get stuck analyzing?
Is there a recurring problem that keeps coming back after being fixed?

Right for now

If any of this sounds familiar, start here.

The same problem keeps returning

You fix it, it comes back, and each fix treats a different symptom.

You solve fast and wrong

Your first solution is quick, confident and aimed at the wrong thing.

The problem statement came from someone else

You inherited a framing and have never checked whether it is right.

Course arc

Where the course goes, in order.

Cadence writes the lessons for you, so the exact path follows your answers. This is the ground a course built from this sentence covers.

01 / 06

Why we solve the wrong problem

Speed, familiarity and the comfort of a problem we already know how to fix.

Symptoms and causes

Asking questions to generate possible explanations, then checking them against evidence.

The hidden assumptions

Reading a problem statement for what it takes for granted.

Several explanations

Holding more than one hypothesis so the first one does not win by default.

Cheap tests

Finding out which explanation is right before building the solution.

Fixing the cause

Choosing an intervention that addresses what you found, and checking it held.

What changes

What you will be able to do, and what you will stop believing.

You will be able to

Tell symptoms from causes

Trace what you can see back to what is producing it.

Question the framing

Find the assumptions hidden in how the problem was described.

Test before you fix

Check a likely explanation cheaply before spending on a solution.

Ideas this course corrects

Asking why a fixed number of times finds the cause

Questions help generate explanations. Evidence must distinguish among them.

The first plausible explanation is the root cause

Keep alternatives open until the observed facts support a conclusion.

Course questions

What to know before you start.

How to find the right problem to solve: what can I do today?

Rewrite the proposed fix as an observable problem. Original example: 'We need a new booking app' becomes 'Three bookings this week had the wrong room.' The second statement can be checked without assuming software replacement is the answer. Compare possible explanations. The room names may be unclear, a saved template may be outdated, or a manual change may not have reached the calendar. Inspect the affected records and the actual workflow before choosing one explanation. Test a bounded correction. If an outdated template is confirmed, correct it through the authorized process and inspect subsequent bookings. Record what changed and whether the problem recurred. One successful case does not prove every booking error has the same cause.

Is this a fixed course?

No. Cadence builds the course when you type the sentence and answer a few setup questions, so the lessons follow your situation. This page describes what a course built from this request covers. You see the whole path before Lesson 1.

Who is this course for?

Compare plausible explanations, inspect evidence that can distinguish them and test a bounded correction. The booking example below shows why a software request is not yet a diagnosis of the problem. It sits under Decision-making in the Work & ambitions part of the library.

Do I need any prior experience?

No. Setup asks what you already know and where you want to use it, and the course starts from there. Bring a real situation if you have one; the examples are built around it.

How long does it take?

Most courses run 7 to 30 lessons. The course length is sized to what you asked for. You set the pace: one lesson at a time, as often as you like. Lessons can be read or played as audio.

Does this course award a certificate or degree?

No. Cadence is for practical self-learning and does not award accredited degrees or professional certification.