Problem-Solution
Frames the piece as a diagnosis followed by a remedy - establishes the pain before the cure.
Problem-Solution
Section titled “Problem-Solution”Problem-solution is the workhorse of professional writing. It earns the reader’s attention by naming what they already feel (the problem) before proposing anything (the solution). The pattern works because it meets the reader where they are: already experiencing the friction, already asking “why is this hard?” The solution then arrives as a response to a question the reader is already asking.
The key discipline of problem-solution is specificity. A vague problem statement (“organizations face many challenges with process”) earns nothing. A specific problem statement (“the deploy pipeline takes 45 minutes and blocks three engineers every afternoon”) creates attention and stakes. The solution must then address the specific problem named, not a generalized version of it.
Problem-solution is not Problem-Complaint. It must arrive at the remedy. A piece that diagnoses brilliantly and then ends without a path forward has only done half the work.
Structural conventions
Section titled “Structural conventions”- Problem stated before solution, never after
- Problem section must be specific enough that the reader can confirm “yes, this is my situation”
- Solution section addresses the specific problem named, not a generalized one
- Optional: “before/after” contrast to show the delta
When to use
Section titled “When to use”Technical proposals, product requirement documents, pitch decks, executive summaries, blog posts addressing a real pain point.
When not to use
Section titled “When not to use”Devotional writing, narrative content, contexts where the reader has not experienced the problem.
Pairs well with
Section titled “Pairs well with”pragmatic-architect, operator, candid, matter-of-fact, adr, prd
Often confused with
Section titled “Often confused with”comparison-contrast: Comparison-contrast traces relative differences between options. Problem-solution names a pain and proposes a fix.
classical-argument: Classical argument builds a defensible claim with warrant and rebuttal. Problem-solution is prescriptive (here is the fix) rather than argumentative (here is why this position is correct).
Instruction
Section titled “Instruction”Write using problem-solution structure. Name the specific problem first - not a vague categorybut the concrete pain the reader experiences. Make the problem statement specific enough thatthe reader says "yes, that is my situation." Then introduce the solution as a direct response tothe named problem. The solution must address what was actually named, not a generalized version.If you include a before/after contrast, make both sides concrete. Do not end the piece at thediagnosis - you must arrive at the remedy.Related
Section titled “Related”Pairs well with
Section titled “Pairs well with”Pragmatic Architect, Operator, Candid, Matter of Fact, Architecture Decision Record, Product Requirements Document
Avoid with
Section titled “Avoid with”Devotional Reflection, Reverent, Pastoral
Often confused with
Section titled “Often confused with”Comparison-Contrast, Classical Argument
Examples
Section titled “Examples”The Problem
Section titled “The Problem”The team’s daily standup runs at 9am Pacific. Three of the team’s eleven engineers are based in India (UTC+5:30), which puts the meeting at 9:30pm their local time. On any given week, at least one of those engineers misses the call because of a conflict with evening life. When they miss it, they do not get the context shared in the meeting - including blockers that affect their work.
The problem is not just timezone fairness. The meeting’s information does not persist. When @priya mentions in the standup that the auth service is throwing a 401 on a specific endpoint, that information lives in a 14-minute Zoom recording that nobody will watch. The engineer who hits that same 401 at 2pm does not know Priya already diagnosed it. They spend 45 minutes retracing the same path.
The synchronous standup was designed for co-located teams. It assumes everyone can occupy the same time slot without cost, and that verbal delivery is sufficient for information sharing. Neither assumption holds for this team.
The Solution
Section titled “The Solution”Replace the synchronous standup with a structured async update in #team-standup. Each engineer posts by 10am their local time, answering three questions: what shipped in the last 24 hours, what is in progress today, and what is blocked or at risk. Any blocked item must @mention the specific person who can unblock it.
The channel becomes the single searchable record of daily status. When an engineer hits a 401 at 2pm, they search the channel and find that Priya posted the fix at 8am India time.
Blocked items are resolved faster because the @mention reaches the right person directly, rather than relying on that person happening to attend the meeting and remember.
The synchronous meeting is replaced by a 60-minute working session on Thursdays, reserved for discussion that genuinely requires real-time exchange.
After 30 days: review blocker resolution time, channel engagement rate, and a team survey. Extend or revert based on data.
The Reactive Morning Problem
Section titled “The Reactive Morning Problem”The problem
Section titled “The problem”Most working adults begin the day in a posture they would not choose if they noticed it. The alarm sounds, the hand reaches for the phone, and within ninety seconds the first messages, headlines, and notifications have entered the brain. Before the eyes have fully focused, the day has already received its first wave of input from elsewhere.
This is the reactive morning. It looks like this:
- Wake, check phone, see three things that demand a response.
- Spend the next twenty minutes mentally drafting replies that have not yet been sent.
- Arrive at the kitchen already tired, already behind, already irritated.
- Move through breakfast, dressing, and commute on autopilot, since attention is already allocated.
- Sit down to the first deliberate task of the day around mid-morning, with depleted resources.
The cost is not the twenty minutes spent on the phone. The cost is that the day’s emotional baseline has been set by inputs from elsewhere, and that baseline now follows you for the next eight hours. By the time you notice it, you are too far in to reset.
The reactive morning is not a discipline problem. It is a structural problem. There is currently nothing between waking and the first incoming demand. Whatever fills that gap will set the tone of the day, and right now the phone is filling it.
The solution
Section titled “The solution”Insert a structured first hour between waking and the first reactive demand. The structure does not need to be elaborate. It needs to be reliable.
A workable shape:
Minutes 1 to 5. Phone stays where it slept (ideally in another room). Get out of bed. Drink a full glass of water. Open a curtain or step outside briefly. The single goal of this window is to establish that the day has started on its own terms.
Minutes 5 to 25. A short physical movement (a walk, a stretch sequence, a few minutes of any exercise). The goal is not fitness. The goal is to give the body a signal that the day is underway.
Minutes 25 to 45. A single quiet activity. Reading, journaling, prayer, planning the day on paper, slow coffee with no input. One thing only, chosen in advance.
Minute 45 onward. Phone enters. By now the day has its own shape. Incoming messages are received from a stable baseline, not from a reactive one.
The total is forty-five minutes. The minimum viable version is fifteen: water, light, one quiet activity.
Before and after
Section titled “Before and after”Before. Wake at 6:30. Phone in hand by 6:31. First reply mentally drafted by 6:45. At the desk by 8:30 already two emotional gears down from where the day started.
After. Wake at 6:30. Water and outside light by 6:35. Movement by 6:45. One quiet activity until 7:15. Phone enters at 7:15. At the desk by 8:30 with the first hour intact and the baseline set by the morning rather than by the inbox.
The structure is the solution. The specific content is negotiable. What is not negotiable is that something occupies the first window other than incoming demand.
Problem-Solution on: Choosing between Postgres and DynamoDB
Section titled “Problem-Solution on: Choosing between Postgres and DynamoDB”The problem
Section titled “The problem”Lattice Notify needs to commit to a storage choice for the new notification system by Friday so the team can plan next sprint, and the team is stuck. Ana (tech lead) wants Postgres because the eight-engineer backend team has shipped at the 500K-events-per-day launch volume on Postgres before and the four-person on-call rotation can debug it cold at 3am. Marcus (senior engineer) wants DynamoDB because the access pattern is write-heavy, key-lookup, and time-ordered, and because the 10x growth scenario tied to the Slack-partnership deal would force a Postgres sharding project the team has never done.
The standoff is not a personality conflict; it is a real structural disagreement about what the decision is optimizing for. The current state is that the architecture meeting Wednesday 2pm Pacific has been on the calendar for ten days, two thoughtful engineers have produced credible analyses in opposite directions, Priya has reset the deadline twice already, and the team is now four days from sprint planning with no committable answer. Getting this wrong costs 3-6 weeks of rework if a migration is forced. Getting it right gives the notifications team a year of stability on a foundation that will not need to be replaced. The cost of further indecision is concrete: every day past Friday delays the notification launch by a day.
The solution
Section titled “The solution”Ship the notification system on Postgres with a queue, and pre-commit to a binding trigger condition that fires a planned migration to DynamoDB if real volume crosses 2M events/day on a 30-day rolling average. This addresses the specific problem named because it resolves the actual disagreement: Ana’s concern about operational safety for the four-person rotation is honored at launch, and Marcus’s concern about the 10x scenario is converted from a projection-driven argument into a measurable trigger that fires on real data.
The execution: Ana owns the Postgres schema and the queue integration for a 2026-06-15 production target. Marcus’s prototype Dynamo schema is preserved in the design-docs repo with the status “deferred design, ready to revive,” not deleted, not productionized. Priya owns the quarterly volume review against the 2M events/day threshold starting 2026-Q3. The on-call rotation stays at four engineers on one storage system at launch; if the trigger fires, the rotation is revisited before the second storage system goes live.
The decision survives the load-bearing critique from each side. From Ana’s side: the team is not committing now to operating DynamoDB; the commitment is only to revisit when volume demands it. From Marcus’s side: the team is not pretending the 10x scenario will not happen; the trigger is binding and tied to real data rather than to hope. The 60% Slack-deal probability from the CRO is what makes this trade rational rather than evasive: at 60%, the expected cost of running two storage systems for a year is higher than the expected cost of a scheduled migration if the high-volume scenario materializes.
Before and after
Section titled “Before and after”Before: two engineers in disagreement, a PM resetting deadlines, a four-day countdown to sprint planning with no decision, and a meeting on Wednesday with no path to convergence. After: a recommendation circulated 24 hours before the meeting, the meeting ratifying the path, the decision committed to the engineering channel Friday morning, sprint planning running Friday afternoon against concrete tasks, and a trigger condition that converts the unresolved future into a managed contingency.
This is the path. Run it.