if we were to become middle-big sized company at some point, one might consider the following flow:

1. business formulates & agrees on the requirements (founders, curators etc)
2. escalates the issue down to IT department via project manager(s) to a business analysis dpt
3. SA/BA review the requirements to prevent contradictions, discrepancies. how these requirements correlate with existing processes. solves the arisen issues/questions with PO or via PM
4. if required, business gathers once(or as many times as needed) more, so that its clear to everyone in the chain as to how to dodge those, possibly arisen, pitfalls
5. as soon as all the review iterations have successfully passed and BA doesn't see issues anymore, he breaks the objective into several features(functional units of business value). provides a first approximation description of the aforementioned requirements and which scenarios these features will affect. will provide the understanding as to which brand new scenarios would need to be added to the project
6. the result of the above is then being sent to the solutions analytic. that person describes implementation requirements and use scenarios(interactions between the enduser and system) in maximum detail. draws scenario and fork steps on a diagram
7. result of SA work is, in turn, then being provided to the solutions architect or the arch consilium. he(they) reviews & evaluates, as to which product modules will be affected. which connections will be changed, possibly some new will appear. is that even DOABLE? :) because, sometimes it might not be, or not be a good idea at all
8. if the arch-firewall been successfully passes, systems analytic for the product in question using a solutions analytic data, writes the specification for development team
9. then he gets a dev or a group assigned to this feature. they discuss between eachother, solve all the remaining pieces. here the initial codebase for the feature is being born
10. after "local" development the push/merge request is being sent to the centralized SCM server. teamlead has to review/refactor and merge it into a DEV environment
11. then, upon reaching a known checkpoint, the batch of several commits finds its way in a bigger merge to the UAT env
12. qa/automation engineer works happens here. some manually, some automagically
13. if everything went OK, our happy code reached the STAGING env in a similar batch merge manner
14. then the deploy/release part. I don't know much about it, I am a devops .. come on. but rumors have it, might be a good idea to initially deploy to locals, company internal personal to test the new functionality via blue-green depl pattern. then to a small group of loyal external users and only in 3rd iteration to the rest of the world(at least, that's how facebook does it and .. they're still in business)
15. FIN. made technical part of this "pipeline", bless the mark, document less informative, since we already have a strong performer setup and it has obviously been done/planned. heard, we even have precise roadmaps, but never saw those yet

obviously, if we were to put the question "what our product-enhancing machine is currently missing", those would be, by a position/role:

- PO
- PM
- SA(systems & solutions)
- BA
- DS(data science. this could be tricky, due to the specifics of our business. but it might work wonders. if one could be further interested in my view, that would honestly be simplier to discuss verbally at some occasion. with examples)
- math-person(fbprophet & such, business specific)
- integration & solutions architects
- java teamlead. or maybe Sam? I'm simply not sure yet

questioning the lack of that whole squad, described above, would be silly. we're a startup, there's a roadmap for hire(remember, the one I never saw). there's a budget, that I've no idea about. only 2nd week into the work for US. but, barely having any required information, based on the previously gathered experience & general understanding, to make some sort of conclusion, I can easily assume as to why it is that way today. and it definitely is normal. doing things that don't scale on start is alright. have no doubt, we are heading this direction of a bigger, more mature company