On campus? Ask Stu instead. Stu already knows our methodology, so you can skip the setup and just describe your situation. Available to UC Berkeley staff, faculty, and students.
When to use it
You know something needs fixing but the ask is vague. A good problem statement describes the gap between current and desired state without smuggling in a solution. Use this before you write objectives, scope, or anything else.
A problem statement is the foundation of any project charter. It names the gap between where things are now and where they need to be, in language a sponsor can approve and a team can act on. Get it right and everything downstream (objectives, scope, success measures) has something solid to build on. Get it wrong and you spend the project solving the wrong thing.
Make it better
Your first result is a draft, not an answer. Two follow-ups worth asking:
"Which version would a skeptical sponsor find most compelling, and why?"
"Quantify the problem using these numbers: [paste any data you have]."
Additional guidance
If the first results aren't quite right, add more detail, break the request into smaller steps, or have the tool interview you first. Try: "Ask me questions, one at a time, to gather anything you need before you start."
AI output is a starting point, not a finished product. Always review it against your own context, campus policies, and judgment before you use or share it.
Put it to work
A finished problem statement goes straight into your Project Charter. Get the template on the Initiate Project with Sponsor activity page.
