Not sure if this is what you are after, but we run the following process for user facing features & apps:

1. Product Owner creates mockups of desired flow/functionality in Balsamiq. Including acceptance criteria for QA.

2. Architect questions, reviews mockups, annotates with API calls (existing or new)

3. Mockups passed to UI designer who provides design and resources for developers

4. Development

5. Release, QA & UAT once passed

Key to this approach is (a) a product owner who is has a technical background so you start from something sensible, (b) not letting the product owner build UIs but rather flow & functionality (so the designer has free reign), (c) not taking on too much within a single project (eg a fully fledged app from scratch would be multiple iterations of this).

If it is an incremental change or a change related to a growth experiment, during step (1) we set the hypothesis (Eg increase conversion rate through funnel X) and on deployment is evaluated.

If the change has significant architecture / backend implications the architect specs these out separately using either a checklist or a functional spec which is then broken down into JIRA tickets.

We are a small team, but I have found this approach works in larger orgs too. Any time we have started with BRD/PRD etc I find they get outdated fast. Documentation heavy methods have been helpful work for architecture backend changes though.

Thank you for your insightful comment!

1. Find out what the customer really wants.

2. Try to hack it with as fast as possible - Google Forms, spreadsheets, PowerPoint, Evernote, WordPress. For a lot of things with a database, you should be able to prototype faster with a spreadsheet.

3. At some point, it will fall apart. Design a disposable prototype. Plan to throw this prototype away completely.

4. Hack away at the prototype for max 1 month. This should be enough to present to a investor or even release to a customer. (one of my prototypes got 10k downloads, good cash flow, crashed on average 3 times a day)

5. Build a proper design around this. If you have released your prototype to the client, you know clearly what they want.

6. Break down customer requirements into test cases. As in plaintext tests, not code or Word documents.

7. Design a plan for development to launch. Try to launch as soon as possible. Cut features out ruthlessly.

8. Launch. Iterate.

In the early stages, pick the fastest tool. Pick a tool you know or can learn fast.

Every design, scale up 10x. Your spreadsheet might handle 10 customers. Your app prototype might handle 100. Your first non beta release might handle 1000 customers. Future releases handle 10000, 100k and so on. Don't scale too early; tools that scale well are generally less efficient, and this includes marketing.

Thank you for your insightful comment!

Not contributing to the answer but a related question: Also when you start afresh on a new web/mobile app, do you use in trend technologies or the ones you (team) is comfortable with. Is there a process / guidelines to this?

usually, the fastest route between two points is... the one you are familiar with. I always go with the stack i'm comfortable with. If i want to try something new ( lately, flutter.io and dart2 ) i build a proof-of-concept / side-project / toy. Won't bet my living on trendy tech... i'm all for "boring proven stuff".

Off track answer still worth focusing on modern web applications. I see some companies use pre built common services (for example identity service, notification service). Product companies now using micro service architecture to achieve product development seamlessly and in time. This helps developers to focus on pure business logic. Try to evaluate this approach as well if you think single company sells multiple product under same umbrella.