Sometimes you have a problem and no solution.
Other times you start with a solution, but you haven't yet worked backward to the problem.
The reality is that it’s not a linear process but a moving back-and-forth motion between problem (demand) and solution (supply).
Example Scenario
Let’s imagine you have the germ of an idea for a new product that automatically **records and transcribes customer calls **for busy sales teams.
Demand Side (Problem)
> **“We always forget important client details from our calls, and it’s awkward typing notes during the call. We want an automatic way to capture calls and quickly find what was said.”**
1. **Initial Observation:**
- Sales reps complain they can’t fully focus on the conversation because they’re juggling note‐taking.
- Managers suspect many follow‐up tasks get dropped because nobody can remember all the action items.
2. **Research/Questions:**
- “Are reps already recording calls in some way? If so, do they listen back?”
- “How many calls do they have per day? 3–4 or 20+?”
- “Would they want full‐length recordings or just a summary of key points?”
3. **Finding:**
- 80% of calls are <15 minutes.
- The biggest pain is that reps don’t want to sift through a 15‐minute replay for one detail. They just want quick highlights or text search.
Supply Side (Solution Directions)
> **“We could build a call‐recording and transcription service baked into our existing chat app or as a stand‐alone product.”**
1. **Initial Idea:**
- **Idea:** Integrate call recording + AI transcription so reps can replay or read a transcript anytime.
- **Constraint:** Building an in‐house transcription engine is huge. Might need a third‐party transcription API.
2. **Prototyping & Feasibility:**
- “Let’s do a small experiment with an off‐the‐shelf speech‐to‐text API to see if the accuracy is good enough.”
- **Discovery:** The API costs $X per minute. For high volume, that might get expensive.
3. **Refinement:**
- “Because the main pain is *finding what was said*, we don’t need an ultra‐fancy audio interface. A robust text search might do 90% of the job.”
- “We can keep actual audio recordings for a limited time (e.g. 30 days) to save storage costs.”
Reflects a Messy Reality, and That’s Ok
1. **Starting with a Fuzzy Problem:** You begin on the demand side: “Our sales teams can’t keep track of key info from calls.”
2. **Jumping to a Possible Solution:** Next, you hypothesize: “What if we record and transcribe calls automatically?”
3. **Going Back to Validate the Problem:** Before building anything, you go back to ask real users: “Do you truly want whole‐call playback, or is searching transcripts enough?”
4. **Prototyping to Explore Feasibility (Supply):** You try an off‐the‐shelf transcription API to see how accurate it is and weigh costs.
5. **Refining the Scope:** The new knowledge (costs, user desire for quick search) shapes a narrower solution: you **prioritize text search** as the key feature, with optional audio access for a limited time.
Throughout, each demand‐side question sets up a new supply‐side prototype or research, and each supply‐side insight triggers further questions on the demand side. This is exactly the iterative shaping process: you **bounce back and forth **until the scope and solution match the real need.
The back and forth between the supply side and demand side defined a context that made it clear at each step what the question was, why I was asking it, and how the answer affected the work-in-progress solution.
This also shows Kidlin's Law in action. That the problem and the solution are much closer in kind than we think.