We hear it on a reliable loop. The timeline is tight. The stakeholders already agree. The designer is confident. The developer has started. User testing would be lovely, of course, in an ideal world with more calendar. At Always 49 we have an unfashionable response. You have not got time to skip it. You have got time to waste building the wrong thing, which is what “no time to test” usually turns into.
This is not a demand for a six-week research opera in the middle of every sprint. That misunderstanding is how testing gets treated as a blocker. Our rule is simpler: we cannot test too early, but we can test too late. Whatever we have, we can put in front of someone. A spoken scenario. A paper sketch. A clickable prototype. A first vertical slice with ugly edges. The fidelity should match the question. If you need to know whether the journey makes sense, you do not need a branded UI. You need a person and a task.
Project management is the discipline that either makes that happen or quietly drops it when the board pack needs a green status. We think dropping it is a failure of management, not a failure of research. Testing is how you de-risk a date. It is how you stop a sprint from being theatre. A demo to stakeholders is useful. A session with someone who has never seen the product is a different kind of truth. Stakeholders can imagine the happy path. Users will show you the door they actually try to open.
There is a people reason as well as a delivery reason. Teams get attached. Clients get attached. We get attached. Fall in love with the problem, not the solution, is easy to say and hard to do once a prototype has been praised in a meeting. Testing is a structured way to let go. It gives the project permission to change while change is still cheap. That is supportive. It supports the client’s budget. It supports the developers who would otherwise be asked to unpick a finished flow. It supports the user who never asked to be confused.
We have watched the opposite movie enough times to have an opinion. A product launches. Training documents get longer. A “champion user” appears, which is often a polite name for the person who has memorised the workarounds. Support tickets cluster around the same three screens. Someone suggests a redesign a year later, which is testing with extra steps and extra invoices. Early testing would have found the same three screens when they were still boxes on a page. That is not romantic. It is arithmetic.
Agile, at least the version we run, is supposed to help here. Two-week sprints exist so that something tryable appears while there is still room to steer. If your sprints only produce tickets closed, you are doing project accounting. If they produce something a person can attempt, you are doing product work. We would rather a slightly smaller scope that has been tried by a real user than a broader scope that has only been tried by the people who built it. Builders are the least qualified people to judge whether something is obvious.
Measurement after launch is testing too, just with a different costume. Analytics, session replay used ethically, support tags, and the courage to call a user and ask “what happened?” all belong in the same family. Upgrade without measurement is just more building. Our process names Measure as a step because otherwise it becomes a wish. Wishes do not support people. Evidence does.
So if a partner tells you there is no room for testing in the plan, hear what they are actually saying. They are saying the plan is more precious than the people who will live with the result. Always 49 will keep making room. Not because we enjoy watching people frown at a prototype, although we do learn a lot from the frown. Because the frown on Tuesday is kinder than the silence after launch, when users have already decided the software is not for them.