I think you only need to (and arguably only should) be familiar enough with the business side to be able to get into the business user's head. What you're experiencing isn't necessarily any fundamental difference between code and product. It's a matter of varying objectives.
Business people generally have the objective of building a product that people want. Technies have the objective of building maintainable, non-buggy code that can scale with the company.
In other words, business types will scoff at technical requirements because that's their job. They don't get paid to make sure good code gets written. They get paid to build a cool product. You, on the other hand, aren't paid to create a cool product. You're paid to ensure good code gets written.
My advice is to take a note from the business people. You need to focus on doing your job correctly. If you cut corners and put out a buggy product to suit them, you're going to get the blame. In fact, I'd argue that you deserve the blame. It's your job to stick up for technical requirements.
Now, it's tempting to blame the business people for not listening to you. They are treating you unfairly, but that's not really the point. The point is how you react to that situation. Let me share a secret of working for software companies with you: the code is the product. That might sound obvious, but we forget it so many times. Thus, the key is to realize that you're helping business people to make a better product. Once you realize that, it becomes easy to phrase things in their terms: "We can do that, but it will make a buggy product that no one will buy," or "We can do that, but it will jeopardize our ability to put products out faster in the future".
I'm not suggesting that bad work environments where you can never get the business people to listen to you don't exist. I'm suggesting that the way to handle this situation is to stick to your guns while realizing that the other side has differing goals from you. The correct way to handle it is to find a solution that benefits both sides.