Most software projects don't fail because the developers were bad. They fail because nobody could agree on what success looked like. Vague goals lead to vague scope, vague scope leads to padded quotes, padded quotes lead to disappointed founders. The fix starts at the goal.
The vague vs specific gap
Vague goals look like:
- "We want to grow the business."
- "We want to be more efficient."
- "We want a website that converts."
- "We need to modernise our tech stack."
None of those tell a developer what to build, what to test, or when to stop. Specific goals look like:
- "Reduce time to onboard a new client from four weeks to four days, measured by the date of first invoice."
- "Increase the conversion rate on our pricing page from 1.8% to 3.0% over six months, measured in GA4."
- "Replace the manual spreadsheet workflow that consumes 12 hours per week of admin time."
- "Reduce monthly Zapier spend from $850 to under $100 while maintaining all current automations."
The second list has a number, a unit, a timeframe, and a measurement method. That's a goal.
The four-question framework
For any project objective, write down four answers:
- What changes? Specifically what behaviour, metric, or process is different after this is done.
- By how much? A number. Even an estimate. Without a number you have a hope, not an objective.
- By when? A date, even if soft.
- How will we measure it? Where the data lives. If you can't measure it, you can't tell whether the project succeeded.
If you can't write down a number, you don't have an objective. You have a feeling about a number.
What to do if you don't know the number
Often founders don't know the baseline. That's fine, but it's the first thing to fix. Spend a week measuring before you scope anything. Examples:
- Time the manual workflow you're replacing, by hand, with a stopwatch, for two days.
- Pull the last 90 days of conversion data from GA4 or your CRM.
- Tally the support tickets the project is meant to deflect.
- Track Zapier task usage over a fortnight.
The data is almost always findable. Founders skip this step because it feels less productive than scoping. It's more productive. It makes scoping correct.
The "secondary objectives" trap
Most projects accumulate three to five secondary goals. "While we're at it, we should also…", by month two there's a wishlist longer than the original brief. The fix: pick a single primary objective and rank everything else against it. Anything that doesn't measurably advance the primary is v2.
Communicating the goal to developers
Once you have a number, share it. Specifically write into the brief: "This project is successful if X is true by Y, measured in Z." Developers do their best work when they know what win looks like, they'll cut features, push back on scope, and prioritise correctly because they're aiming at the same target.
The bottom line
Vague goals produce vague software. The fix is a number, a date, and a measurement method. Write all three down before you write the brief, and the rest of the project gets easier.
If you want three Australian developers who'll work to a real number, not a hope, FindDevs gets you those quotes. Free, in 24 hours.