Defining a product comes down to specifying its requirements. But what happens when the business is unable to define its requirements?
When there are no business architects or analysts, IT staff will assist in the requirements gathering process where they help in structuring the thoughts of business people. This could be done in workshops with various business functions like sales, marketing, finance, legal, etc.. Going down to the level of detail that is really helpful for IT will take a few iterations. After the first round we can produce conceptual requirements that become the basis for more detailed requirements later on.
One possible way, that worked out for me, was to define the conceptual requirements in a format as if I was reading a commercial data sheet from the ideal product in mind. It would describe features and benefits of the super system that would fall down from heaven into our laps. It would contain a lot of open ends and simple examples to give a lot of room for brainstorming, but at the end of the day, it will deliver ourself a way to define the scope of the project.
The conceptual requirements can eventually be used in various ways, either they will be refined in more detailed requirements for a procurement process or they can be used as first input in the product backlog of an agile development team. High level requirements, feasibility studies etc. can all be subject to the initial concepts.
For the architect, it will lay down the areas of concern, the directions where extensibility is key, areas with high scalability or security needs. Conceptual requirements usually fit perfect in the mind of the architect who is usually the person with "more or less going 17 degrees north direction over the coming years"-insight.