Problem Before Solution
Why a proposal should establish the problem before presenting the solution, and how to show that your idea is a relevant response to real friction, causes, and stakes.
Solution-first makes a proposal sound like a sales pitch
“We propose building a platform,” “we want to launch a campaign,” or “we recommend a redesign” all begin with what you want to do.
The reader often begins elsewhere: why do I need this?
Problem gives meaning to everything that follows
If the problem is unclear, Why Now weakens, Insight loses weight, Value becomes vague, and the Ask is harder to accept.
Framework: Actor → Friction → Cause → Cost → Desired Change
Actor — who is affected?
Friction — what blocks them?
Cause — what drives the friction?
Cost — what happens if nothing changes?
Desired Change — what better state should exist?
Actor should be specific
“Customers,” “users,” and “the team” are often too broad.
Define the group that actually experiences the problem.
Friction should describe blocked behavior
Do not say only “the experience is poor.”
Say what cannot happen efficiently, clearly, or reliably.
Cause prevents solving the wrong problem
Visible friction is not always the root cause.
Low conversion may come from confusing pricing rather than weak interface design.
Cost creates stakes
What continues to be lost if nothing changes? Revenue, time, trust, conversion, capacity, speed, consistency, or opportunity.
Desired Change gives the solution a test
Define the better state before showing the idea.
Then the solution can be judged by whether it moves the actor from current state to desired state.
Applying this on Forwork
A Forwork Proposal can include a structured Problem block: Actor, Friction, Cause, Cost, Desired Change.
Relevant Project proof can show that the problem pattern exists in real work.
Conclusion
Do not begin with “what we want to build.”
Begin with what is not working, for whom, why, and what it costs to leave it unchanged .
Actor → Friction → Cause → Cost → Desired Change.