Explain the product

Apart from giving it a name #105, another crucial thing is to explain the product(s).

Currently, the FaaS with multiple distributed instances is described on the website like this:

- “A Globally Distributed JavaScript VM”
- “[..] a distributed system that runs JavaScript, TypeScript, and WebAssembly at the edge, worldwide.“
- “[..] a distributed system that allows you to run JavaScript, TypeScript, and WebAssembly close to users, at the edge, worldwide.“
- "[..] code is run in different data centers around the world in order to reduce latency by servicing requests at the data center nearest to the client"
- “[..] deploys your code throughout the world. Each new request is served from the closest region to your user.”

From the above definitions, the last ones have arguably the most meaning to your customer. It’s unfortunate that they're deeply buried in the documentation. The difference is describing what the product *is* and what it *does*. The customer cares what the product *does*, because that's what they pay for. “What do I get from using it?”. The engineers care what the product *is*, because that's what they are payed for. “How is it built?”.

It's fine if the product description is written by an engineer for now. Though if you want to grow the customer base then you'll want to understand this difference eventually.

Start with the product descriptions on the website and the existing documentation passages quoted in the issue. Clarify what customers get from the FaaS, then replace or consolidate the buried wording with a customer-focused explanation that distinguishes the product's benefits from its implementation.

Written by the indexing model from the issue text.