This is why I keep emphasising on "domain knowledge". As an engineer my domain knowledge is zero when I wade into a new problem space. A good way to approach i

This is why I keep emphasising on "domain knowledge". As an engineer my domain knowledge is zero when I wade into a new problem space. A good way to approach is to partner with a domain expert to understand the following aspects. 1. Know about various stake holders that make up a business process. Understand each of their incentives. Some actors standout explicitly but some do not, such as regulators. 2. The value add by different player/stake holder in the chain. 3. Location of power centres. No one will explicitly call it out but you will be able to figure it out. Now pick one stake holder or actor, go deep into their problems, and see how you can make their life easier without disrupting rest of the actors. This latter part is important. If there are three actors (A, B, and C) and your solution is intended to make life easy for "A" but requires B and C to disrupt their workflow without them getting anything in return then it'll be that much difficult for your solution to be adopted. Also, at the end of the day automation is making someone (or part of someone) redundant. Make sure you identify that person and be subtle about your messaging to them. All of this takes time so in olden days there used to be a role called "system analysts". Their job was to go deep into the problem domain, untangle all the above for you and help you define product. These analysts are typically ex-workers in the same domain so they have seen everything first hand. Given the nature of their job their role is not fungible in that you can't take one person and make them move around to be system analyst in different domains. Somewhere along the way system analyst role disappeared and they were replaced by fungible "product managers". These PMs have a generic set of product development skills such as UX, user retention optimisation etc., But they lack the domain knowledge. And they are expected to be fungible. If a PM changes job once every 3 years into a different domain they can at best do a superficial job. Of the top of my head here are two examples. There's this software called Docon (https://docon.co.in https://docon.co.in) used by small-setup medical doctors and physicians. The value add for doctors is very clear. It saves them time and all the hassle. What is good about Docon is it requires zero actions by the patient or any one else. So Doctors are happy to be using it. It is a nifty little tool to automate key parts of doctors' workflow. Now let me talk about JIRA. It is mainly targeted towards management and execs. Because, let's face it, they have a genuine problem of not having clear view into project development state. They can't see how their quarterly projects are shaping up at different zoom levels. To that end I would say JIRA does a reasonably good job. Where JIRA fails spectacularly is it requires leaf level works to massively disrupt their workflow. Not only does it require them to use JIRA for daily updates and what not it also forces a way of agile development which comes with its own set of baggages.