I’m assuming by “your team” you mostly mean the engineers you work with. Here’s a few ways to show your team that PMs are helpful:

• (Most Important) Be a customer expert. Become known for deep understanding of your user base. Whenever anyone (developer, salesperson, support, etc.) has a question about what your users want, you should be able to answer it… or to figure out who can answer it. Spend as much time as possible learning about your customers via visits, surveys, market research, usability testing, A/B tests, etc. If the team knows they can trust your judgement about what the customer wants—and if you can prove it when needed!—then they’re more likely to enthusiastically support the roadmap you come up with.
• Know the business and market. In addition to understanding your company’s customers, you also must know the competition, how products are sold and promoted in your industry, what industry trends are happening, and other details about how to maximize the revenue that your team brings in. You should periodically discuss what you’ve learned (at a high level) with your engineers. That way they’ll always know *why* they’re being asked to build all this cool tech.
• Write specs with the right level of detail. Every engineering team has their own preferences for how much detail they need from PM to complete their work. Some teams like only high-level requirements or user stories that they will flesh out on their own. Others like very detailed specs with every UI element and behavior carefully specified. Some like to work directly with designers, others want PM to do that. Learn what your engineers need to be productive, and give it to them! FWIW, “writes bad specs” (or user stories, or requirements, etc.) is the #1 complaint that I’ve heard from devs about PMs.
• Shield your team from randomization. Developers hate being distracted by 1,001 questions or requests or meetings from marketing, support, sales, execs, end-users, etc. A good PM will figure out how to get all that communication pointed at yourself so you can triage the easy stuff and turn the hard stuff into more efficient formats (e.g. bug reports with clear repro cases, or feature requests with clear business context) so your technical team can focus on building cool tech. Especially important: minimize the number of meetings that you drag developers to that they didn’t really need to attend.
• Stay ahead of your team. There is, IMHO, no greater process failure for a PM than having your dev team run out of work to do. You should always try to stay a few weeks ahead of your dev team. You should always have the next sprint’s backlog clean and ready in advance. You should always show up to meetings you accepted. And so on. You’re the PM, so it’s your job to make sure that the trains all run on time. If you find yourself designing features on-the-fly in a sprint planning meeting, then you’re doing it wrong!
• Avoid throwing away developers’ work. Developers hate working hard on projects that never actually get shipped or that don’t get used afterwards. Your goal is to minimize this happening by doing your homework on the business value, costs, risks, etc. for new features. My rule of thumb is that a task shouldn’t make it into a sprint unless I’m at least 95% sure that the feature behind that task will ship, and I’m at least 80% sure that it will be used by a significant portion of target users. If you need to run spikes or experiments to determine user interest, then be explicit with your team that this is a test, which will help avoid grumbling if it doesn’t pan out.
• Take responsibility for problems. Never scapegoat. Never blame developers for things going wrong. They’re just following the priorities and direction you asked them to, right? If the release took too long, think about and discuss what *you* could have done to reduce scope, to anticipate problems, etc. If the code shipped with too many bugs, think and talk about how you (and the team too) can do better next time. Never, ever throw developers under the bus, even in private— it will get back to your team and they will shun you. Enthusiastically participate in sprint retrospectives or other post-mortems where you and your team can learn from mistakes.
• Be a highly-responsive “unblocker”. In any complex tech project, developers will frequently have questions or concerns about even the most simple features. Your job is to get those blocking questions answered as soon as possible so they can finish what they’re working on. Think of yourself as the JIRA of developer questions; it’s not your job to answer all questions yourself but it *is* your job to ensure that those questions get answered quickly. Especially important: don’t “go dark”. If you’re traveling or are so busy that you can’t reply, let folks know when you’ll be back online and what they should do if they get blocked while you’re out.
• Be a bidirectional business<->engineering translator. Non-engineers and engineers often struggle to understand each other. As a PM you straddle both worlds, so you’re uniquely positioned to translate engineering communication and terms into language that the rest of the company (and your customers!) will understand. Similarly, your developers will often misinterpret what business folks want. They’ll have a much easier time if you can explain business requirements with enough context and detail that they can see how to write code to satisfy those asks. I’m not saying that devs should be isolated from the rest of the business, only that helping devs *understand* the rest of the business—and vice versa—is partly (mostly?) your responsibility.
• Internally promote your team and their work. It’s your job to let the company know what amazing things your team is doing. In most companies, most non-technical employees don’t understand exactly what developers do. So it’s your job to explain why all those expensive developers deserve those fat paychecks! This can include recognizing specific developers or teams when a cool feature ships. It can mean explaining a technical improvement in business terms. It can mean inviting developers to give demos or otherwise get visibility with management. One easy piece of advice: whenever *anyone* compliments you about product changes, you should immediately and publicly call out and compliment the engineers, designers, and others (ideally by name) who built the thing. Don’t let your team feel that you’re taking credit for their work. Instead, your team should think of you as their “agent” who’s always supporting and hyping them within the company.
• Take engineering debt seriously. You’ll probably want engineers to spend 100% of their time building new features. Resist this impulse. The team needs to refactor old code, to upgrade tools and platforms, to automate manual tasks, and other stuff that customers don’t see but which makes engineers' work much easier. If you defer this maintenance too long, your team’s productivity and morale will suffer. My suggestion: carve out a percentage of your budget (sprint points, hours, whatever) and hand that portion over to your dev team so they can triage engineering debt tasks and work on the ones they think are most important. Ideally, PM should not be involved with this triage—just give your engineers a consistently predictable portion of time. They’ll do the right thing. In my experience, 20%-30% is probably the right range for most teams.
• Encourage product feedback. Developers often have great product ideas but they may not always feel comfortable sharing, so it’s good to encourage dev teams to give product feedback and to treat it seriously. Often this is easy and natural during sprint planning or spec review meetings, because you can ask for concerns or suggestions with the feature while you’re describing it to the team. The key is to be proactive about asking for feedback. Another caveat: lots of internal feedback will be bad ideas. This is OK. I’ve found it helpful to start with praise and then ease into honest and clear feedback that sets realistic expectations about the likely priority of the suggestion. For example: “You’re definitely right that adding mouse-wheel support would make it easier for power users. I’ll add that idea to the ranking question in our next quarterly user survey. That said, only about 20% of power users log in on PCs; the others use iPads or phones only. If the survey doesn’t show big demand for this, I think we’ll probably want to focus on features that don’t need a mouse.”
• Persuasion is better than force. Don’t yell at your team. Ever. Also, you should almost never force your team to do something that they strongly don’t want to do. It’s almost always easier to get humans—engineers included—to do what you want if they also want it. That means it’s your job to persuade and convince, not to “pull rank” as a senior person. Even if you have decades of experience and they’re just out of college, it’s still smart for you to spend the time to make a convincing, evidence-based case for your opinions, and to respectfully engage with theirs. You’ll win more respect that way, and you might end up avoiding a mistake if they’re right!
• Like and respect engineers. This one is intentionally vague, but the basic idea is to ensure that your team knows that you like them and respect their work and their time. Get to know team members as people, not just “resources”. Hang out with the team, especially when you don’t need anything from them. Do favors for the team (e.g. bringing coffee in the morning, or dinner if they’re working late). Give away your conference swag. You get the idea: find ways to show how much you care. Some PMs (often those infected with a “CEO of the Product” mentality) treat developers imperiously as if the PM job is more important or more prestigious than the people who actually build the product. The best PMs are humble and helpful—they serve their teams rather than the other way around.

There are lots more techniques like these. Most of them come down to simple common sense: if do your job effectively while treating your team well, then they’ll like working with you!