Operating a product team in areas where domain experience is needed can be challenging. A domain can be a highly specialized area or industry, like international taxation, car engineering, or content marketing. If, after a basic introduction, engineers do not see the problem at hand, you might have found yourself in foggy domain land. As a result, your core team of product manager (PM), lead designer (LD), and lead engineer (LE) may want to acquire tools and techniques to deal with this extra layer of constraints.

A couple of things upfront. Assuming that there is indeed a problem to solve with your product, the upside of an extra challenge posed by the domain you are building for means that the rewards are also higher. In addition, go into the challenge knowing that prior setups and approaches may not apply to your product. That means to favor the outcome over the process.

Here are five things that hopefully improve your chances of success:

1. Transfer sufficient domain knowledge between PM, LD, and LE in the beginning of the project. Keep two things in mind: (1) Tie relevant domain constraints to the overall vision and strategy of the company and product group and, (2) do not overload the engineers with domain constraints which could have been identified in the beginning as not important or relevant.
2. Handle the bulk of the knowledge gap implications on the product at the discovery stage and funnel only the good stuff through to the implementation stage. This means a) making sure the product solves a real need in the domain space, b) having more iterations and prototypes than for products and features without a domain layer, and c) ensuring the hand-off of what to build to engineering is solid. This is assuming the PM is the one with the domain experience.
3. Beware how domain gaps influence the four product risks (see free online articles from Silicon Valley Product Group’s thought leadership team). To ensure usability and feasability of the product by the LD and LE, respectively, it helps to specifically spend time to understand domain-specific differences of customers and solutions and how these are being accounted for in product risk management. The PM assists during this exercise as well as spends more time making sure the product is valuable and viable.
4. Your product will have certain aspects that do not need to be managed, designed, and built knowing the overall domain. For example, the domain does not always drive user management and certain workflow features. It helps to assemble teams to work on the aforementioned aspects of the product that may even profit from experiences gained in other domains.
5. In aviation there is the phenomenon of young pilots chasing the needle. It means that pilots try to correct the flight path by overly relying on instrument reading. Instead they could stabilize the flight path quicker if they focused on the horizon. The instruments here are your product requirements or constraints. Focus instead on the horizon, i.e. the outcome of your solution.