Most projects go sideways in the first conversation, not the last one. The team starts with a feature list and discovers the real problem halfway through.
Before writing any code, ask these five questions.
1. Who feels the pain?
Name the person, not the department. When a request says “we need a dashboard”, the useful question is: who opens it every morning, and what decision are they making? Products that survive are the ones with a named user who wins when the software works.
2. What happens if we do nothing?
The cost of inaction is the baseline every feature must beat. If the current process works at two hours per week, a tool that saves ten minutes is a nice-to-have, not a project. Be honest about the size of the problem before you size the solution.
3. What is the smallest version that changes the behavior?
Find the one behavior shift that matters. A “portal for clients” usually reduces to: clients stop emailing for status updates. That smaller version is buildable in weeks and tells you whether the bigger one is worth building at all.
4. What does done look like, in one sentence?
Write it before you write code. “Done means a client can see the latest report without asking” is a contract. If the team cannot agree on that sentence, they are not ready for a spec.
5. What are we willing to stop doing?
Every new system absorbs maintenance time. The question exposes whether the team is adding capability or trading it. A project that cannot name what it replaces is a project that quietly doubles the workload.
Turning answers into a plan
Write the answers as a single page. If the answers conflict, resolve the conflict before scheduling work. A one-page answer sheet beats a fifty-page spec because it stays true long after the details drift.
This is the scoping practice we use at Folta Studio on every engagement. It keeps the first conversation short and the first delivery useful.