Author: Nikolas Terzoglou
Do we really know what we're aiming to build and achieve for our clients before we built it?
The short answer is yes.
We start every project by writing about the ending. This keeps us focused on our customer, and at every step, we keep citizens in mind.
The more useful answer is this: before a single line of code is written or a single workshop is booked, we ask ourselves and our team to imagine the project is already finished. Then we describe what that looks like, in plain English, as if we were announcing it to the world.
This is the Working Backwards methodology, and at Symphony3 it is one of the most important tools we use before we deliver a project.
Where It Comes From
Working Backwards was pioneered inside Amazon, and AWS describes its key tenet plainly: start by defining the customer experience, then work backwards from that point until the team is clear on what to build and what value it adds (AWS Smart Business Blog).
The mechanism is simple to describe and hard to do well. Before building anything, teams use the Press Release and Frequently Asked Questions document, to work backwards from customer needs, a practice AWS ties directly to its Leadership Principles (Innovation and Transforamtion - Working Backwards AWS).
What Working Backwards Means to Us
At Symphony3, we work primarily in local government. The stakes are real, and the outcomes often involve a direct impact to the lives of every Australian Citizen. So before we scope a project, we write its ending.
For us, Working Backwards means three things.
First, defining success in the language of the people who will live with the result. The idea is to imagine what a ratepayer, a council officer or a case manager will actually be able to do once the project is delivered, that they cannot do today. Every customer-facing product or service developed across Symphony3 uses the Working Backwards process. We use this mechanism to make sure that we are build the right thing for customers and that we are customer obsessed from the very beginning of any idea.
Second, we use that future picture to shape the project scope from the start. If the ending doesn't sound worth building, we'd rather find that out now than halfway through the project.
Third, handing that same discipline to our project delivery team. As part of the handover process, the Working Backwards document goes to the team who will run the project, giving them a plain-English description of the goal so they can establish and communicate what success looks like to the client from day one.
Technology projects rarely fail because the technology does not work. They fail because nobody agreed, in specific terms, what success was supposed to look like. Working Backwards is how we force that agreement into the open, early, while it is still cheap to change.
How We Use It Before a Project Starts
Before we commit to delivery, we sit down, often with an empty chair in the room, imagining our clients are in the room with us, a practice with the same roots as Jeff Bezos's own habit of leaving a chair open at the table to represent the customer (Forbes). That chair is by far the most important person in the room, and we draft the announcement for a project that has not started yet with them first in mind. What would we tell the council, what would the benefit be for the community or the leadership team once it is live? What changed for them? What can they now do that they could not do before? Moreover, what opportunities may this bring for other councils across Australia and New Zealand?
As part of that draft, we also write a quotation from the client's perspective, the kind of thing we would want a council leader to say once the project is done. We deliberately frame it around what they are now able to do that they could not do before, not around the technology itself, so the goal stays about capability and customer outcome rather than features.
If that draft feels flat, generic or hard to write, we treat it as a signal. It usually means the scope is unclear, the outcome is not compelling enough, or we are solving the wrong problem. Better to find that out in a working session than weeks or months into a delivery. It is easier to change on paper, than after 2 months of software development.
If the draft is compelling, it becomes the target we build the plan around, and the reference point we return to whenever scope conversations drift.
Why This Matters
When we know what we are aiming for before we start, delivery risk drops, alignment is founded early between the clients and ourselves, and teams stop guessing about what “good” looks like. Everyone, us and the client, is building towards the same ending.
When projects skip this step, ambition gets vague, scope creeps, and the ending gets defined by whatever was easiest to build rather than what was most valuable to deliver.
So, do we always start with the finish line?
Yes. Because in local government, an unclear ending does not just cost a vendor relationship. It costs the community from being able to receive the services that they deserve.
That is why Working Backwards is not a formality for us. It is the target we hold ourselves to, before the first workshop, before the first line of a statement of work, before anything else.