DISCRETE SUB OPPORTUNITY
> ```
> Dev shop owners need a way to keep project work moving toward billable milestones without manually chasing team members for updates. Under tight time pressure and uneven cash flow, even one completed task sitting unnoticed for days can delay the next step and push out client billing. The system should automatically notify the right person when work is ready to move forward.
> ```
>
> ```
> User: dev shop owner
> ```
>
> ```
> Struggle: keep project momentum visible
> ```
>
> ```
> Context: tight time pressure + uneven cash flow
> ```
>
> ```
> Current behavior: manual status chasing
> ```
>
> ```
> Breakdown: completed work sits idle unnoticed
> ```
>
> ```
> Consequence: billing milestone delayed
> ```
>
> ```
> Desired capability: notify the right person when work is ready for the next step
> ```
————
**Ineffective Design Language:**
**Current situation:** Chase after people.
**Current solution:** Kanban.
**Desired outcome:** Hit milestones.
**Why this is the bad structure:**
This sounds reasonable at first, but it mixes up the levels.
**“Chase after people” is not the current situation.** It is the old workaround. It is what the owner does because the real situation is uncomfortable: projects are under time pressure, cash flow is stop/start, and work needs to keep moving so the business can bill incrementally.
**“Kanban” is not the current solution.** It is the requested new solution. The person is saying, “I think I need Kanban,” but that does not yet explain the actual progress they are trying to make.
**“Hit milestones” is too broad as the desired outcome.** It is a business result, not the specific workflow progress the owner needs. The more precise outcome is something like: Get notified when work is ready for the next step, so I can bill clients incrementally and smooth out cash flow.
————
COMPRESSION (HUMAN-SPECIFIC CRITERIA)
[constraint/anxieties/habits] Because this happens in the context of time pressure and highly sensitive, start-and-stop cash flow, a good solution must ensure **continuous, visible momentum on billable work** to smooth out revenue cycles.
[pain/trigger/design misfit] Because the current approach breaks down when completed work sits idle for days because no one realizes it is ready to be advanced, a good solution must **eliminate handoff latency between team members**.
[desired outcome] Because the person wants to get notified instantly when work is ready for the next step, a good solution must **proactively push status updates or alerts to the exact right person the moment a task state changes**.
[current approach/workaround] Because the person currently relies on spending their own time and energy physically or digitally chasing people down for updates, a good solution must improve on it by decentralizing project status so the **owner is no longer the bottleneck or primary information router**.
[rejected alternative or previous way] Because they rejected the habit of manual check-ins because it inevitably failed to catch idle work in real-time, a good solution must **avoid reliance on human memory or periodic management check-ins** and instead make work readiness immediately self-evident.
There are various other types of criteria, e.g., various '-ilities', costs, risks, compatibility and complexity, purpose-built, etc. These are the four key customer criteria to capture before defining and making trade-offs among alternative solution paths. You might use fit checks to judge your solution path aspects: [https://github.com/mattlane66/planning-skills-for-agents-and-humans/blob/main/skills/shaping/SKILL.md#fit-checks](https://github.com/mattlane66/planning-skills-for-agents-and-humans/blob/main/skills/shaping/SKILL.md#fit-checks) (a more precise approach if needed here: [https://github.com/mattlane66/fit-check-prioritizer/blob/main/skills/fit-check-topsis/SKILL.md](https://github.com/mattlane66/fit-check-prioritizer/blob/main/skills/fit-check-topsis/SKILL.md)
_____
**High-level summary of the approach to correctly collecting the opportunity data from the dev shop owner:**
- Let’s assume we want to answer the question of how dev shops are organizing their work that’s in progress.
- Let’s assume the customer is the owner of a dev shop.
- The owner recently bought a Kanban software tool (Path X).
- We do not know Point A, and we do not know Point B.
- So, remember, we need to know Point A, which is in the past. So, we go back in time and ask the owner: “When did you buy the Kanban tool?” “When did you have the first thought that you might need something like this?”
- Let’s say the owner responds that he needed it ~6 months earlier than he bought it.
- If 6 months went by from when he first thought he had a problem until when he bought the tool, there must have been some kind of struggle…something that was not sufficient in that period of time.
- We continue to investigate by asking the owner: “What were you doing in that period before adopting the Kanban tool?”
- Let’s assume the owner says: “I was chasing after people trying to get status updates.”
- This sounds like the struggle. But actually, it is a substitute for the Kanban tool, and that sounds more like Path Y. It is not Point A yet.
- We need to ask the owner: “Why did you not just continue chasing people? It seemed to “work” for 6 months (between the thought of the problem and the adoption of the Kanban tool).“
- Let’s assume the owner says: “A day came when I found a piece of work that had been sitting there for 3 days. If I had known sooner, I could have billed the client.”
- Once you find what seems to be the Point A situation, ask another question: “What is bad about billing the client 3 days later?”
- Let’s assume the owner says: “If I can only bill at the end of the project, cash is coming in at big starts and stops, but if I could hit incremental milestones along the way, then I can bill steadily in little bits and smooth out my cash flow.”
- Now we have Point A data: Time pressure and cash flow start/stop. This is different from what originally presented itself as the struggle, i.e., chasing people.
- Now we need Point B data.
- We cannot say this Kanban software is responsible for hitting these cash flow company milestones alone. Remember: Most solutions are not the sandwich; they are just the mustard. We need something specific. So, this is not Point B data yet.
- We have to ask the owner: “Before you used/bought the Kanban tool, what were you picturing would be different after you purchased it?”
- Let’s assume the owner says: “I thought I would have a system in place so I could get notified when work is ready.”
- Ah! So, Point B, what the Kanban tool would enable, is to get notified when work is ready.
- To summarize our discovered frame: When the owner is under time pressure, and the company is not moving fast enough to hit its goals, a system is required to make sure the people on the team get notified whenever a piece of work is ready for them to do the next step.