A project in the Atlas team was considered done when a Shipped email was sent. ... It’s not uncommon for a project to begin with writing (but not sending!) the Shipped email, serving as a north star for understanding the scope and goals of a project.
This is The Correct Answer™.
Front load as much as possible. Transmute product releases from fire drills to just another boring day at the office.
Back in the day, my team's first (draft) deliverables, in rough order, would be press release, release notes, demo, installer, misc docs, .ISO image.
The press release and release notes would be socialized to all stakeholders at project kickoff. Early feedback, expectation setting.
The (scripted) demo would become "more live" as features were implemented (merged).
Our docs were part of the build process. eg Automatic screen shots. As the UI firmed up, the manuals, training material, etc. were always current (ready to ship).
Direct user feedback
Again, The Correct Answer™.
I've only experienced problems when "business analysts" fully mediate between customers and teams. Something always gets lost in translation. aka Game of Telephone.
Additionally, everyone on my teams would rotate thru every other role, over time. So (most) anyone could build the product, run meetings, do a demo, answer tech questions, etc.
This started as a way to bridge the gulf between developers and tech supp/QA/test. But it evolved into something fun, cross training, and career building. Like having a marketing person run the Go-NoGo meetings for a release, or a tech supp person running a release's post mortem.
Empowered everyone, built trust, created high emotional engagement, greatly reduced drama. Compared to our other product teams/groups.