[caseymarquis]

Everyone's talking about sharing how your own business operates (as OP asked). I think of that as onboarding. I work in B2B, and the question I was hoping to get answered is how to share how your customers' businesses operate. In my case domain knowledge means things like: What are the differences in how an OEM vs a Job Shop operates. What departments does a manufacturing organization of different sizes typically have? How is our product perceived as providing value in each of these scenarios? How does our product actually provide value in these scenarios? Who gets extra work in the company because of our product? What's the benefit to them? Knowing these things is what allows us to bring value to different kinds of customers. This is really hard knowledge to transfer though, because you aren't living it every day. That's the kind of knowledge that's going to make a developer (, or service staff, or sales person) highly effective though.

[susiecambria]

I worked in a completely different world my entire career but I see something familiar with your questions. (I was a policy and budget wonk, a child advocate, basically a lobbyist on local government issues in DC.)

I successfully brought on one new staffer by having her shadow me (in formal and informal meetings with decision makers, community meetings, telephone calls, document prep) for a month and do a TON of grunt work, things like making lists of the various organizations working on a particular issue, what their viewpoint was, identifying DC Council staffers working on the issue, identifying their interests and learning styles.

I know the staffer felt somewhat constrained on the leash, but she ended up being so much more successful than other policy staff who did not go through this and do the grunt work. Though, thinking back, success may have had much more to do with my having conveyed a specific approach to the work, goals for the work, etc.