Hi, Have some experience in this area. As we often build apps that are used internally for customers. What @selmet said hits the nail on the head "From my exp

Hi, Have some experience in this area. As we often build apps that are used internally for customers. What @selmet said hits the nail on the head "From my experience, requirements don't come from bottom but it should. Initiator is almost always manager who might have some idea or vision but it's not right originator." Having said that, the same principals that apply for "consumer apps" would apply to internal enterprise tools. Here is some of what i do when consulting: - Start with "what is the problem you are trying to solve?, what are you trying to achieve?" - Is the envisioned tool/app/software going to actually solve this problem? - How can we get more data to validate or disprove this? - What are the minimum set of features needed (MVP) to get it in front of users? - If the sponsor/initiator is not the actual person the software is targeted or is far removed from the actual problem. Speak to the actual users on the ground, the people who are trying to solve this every day. Effectively do customer dev with them (from startup world) - Depending on the organization, you may find some resistance if you focus on user needs. This is usually driven by "bigger pay checks = better opinions" type thinking. What you need to do here is get people to understand the problem, and how the features being added are specifically towards solving them and nothing else. The knowledge gained, and paradigm shift you get having been in a startup, even a failed one is tremendously useful. You will find when you get into more traditional enterprise you are thinking different to most people there, you see things in a different light. Always looking for the quickest path to validate, and ensure you are heading in the right direction.