The full answer
Many of the best products we have built started as a conversation rather than a document. Founders often know their market deeply but have not translated that into features and screens, and that translation is part of what we do.
During discovery we help prioritise: which features belong in the first release, which can wait, and which assumptions need testing. For less certain ideas, our product strategy and prototyping work can produce wireframes or a clickable prototype before full development.
If you already have a specification, designs or a requirements document, that is useful too. We will review it, ask questions, and point out gaps or risks, such as missing edge cases or integrations that are harder than they look.
Either way, the output of discovery is the same: a scope both sides understand, documented in the proposal, so the build starts from shared expectations.
Starting without a fixed specification also leaves room to change direction cheaply. It is far less costly to discover in discovery or a prototype that users need something different than to find out after months of development, which is why we invest in getting the scope right first.