Write the Press Release First
Before a single engineer touches the keyboard, write the launch announcement. Not the spec, not the ticket, not the slide deck. The press release. The one you would publish the day the thing ships, describing what it does and why anyone should care. Amazon has done this for years, and it is the single cheapest way I know to find out whether an idea is real.
Here is the trick. A press release forces you to start from the customer and work backwards. You cannot hide behind architecture diagrams or roadmap arrows. You have to say, in plain language, what changes for a real person on the day this exists. If you cannot write that paragraph without it sounding hollow, the problem is not your writing. The problem is the idea.
Most weak features die quietly in this exercise, and they die early, before they have cost anyone six months. You sit down to announce the brilliant new dashboard, and you realize the only honest headline is "We added a thing some users asked for." No customer benefit you can name. No before-and-after worth describing. That silence on the page is the feedback. Listen to it.
The good ideas behave differently. They write themselves. The headline lands, the customer quote sounds like something a customer would actually say, and the "why this matters" section practically argues its own case. When a press release comes easily, it is usually because the underlying idea has a clear shape and a clear beneficiary. That is information you want before you commit a team, not after.
The discipline goes deeper than marketing copy. Writing the announcement first surfaces every fuzzy assumption you were planning to resolve "later." Who is this for, specifically? What did they do before, and why was that bad? What is the one sentence that makes them care? Each of those questions has to be answered to write a single honest paragraph, and answering them is the actual work of defining a project.
I will go further. Add the frequently-asked-questions section that Amazon pairs with the release, and write the hard questions, not the soft ones. What will skeptics say? Why has nobody built this already? What are we deliberately not doing? The FAQ is where the project's real risks live, and writing it in advance means you confront them while they are still cheap to confront.
None of this guarantees the idea works. A beautiful press release can still describe a product nobody buys. But it shifts the argument to the right ground, the customer's, and it does so on a Tuesday afternoon for the cost of an hour, instead of after a quarter of engineering. That is an extraordinary return on a page of prose.
So before you build the thing, write the news that says you built it. If the news is boring, you just saved a quarter.