Working with developers when you don’t come from a technical background can sometimes feel intimidating. It’s not always clear what’s possible to build, how long things should take, or what’s considered a simple request versus a major request.
The good news is you don’t need to be technical to work well with the developers in your team. You need to be thoughtful, clear, curious, and most importantly, respectful of their work and the input they bring.
This article is about building this kind of collaboration, even if you’ve never written a line of code.
Clarify Your Role and Focus on Outcomes
The job of product managers isn’t to write code. It’s to help the team understand what to build, who it is for, and why it matters. That means you’re responsible for clarity, outcomes, and alignment, not implementation details.
In some ways, not being technical can be an advantage. You’re less likely to over-specify how something should be built and more likely to focus on the user problem and desired result. That gives developers space to bring their own ideas and often leads to better solutions.
I was working on a new area in a product where subject matter experts within the company could propose to hold courses in various product areas, such as product management, UX, software development, project management, and so on. The idea was that other users (also employees of the same company) could see these announcements and register if they were interested.
A more technical version of a solution we were working on might have sounded like this: “Let’s build a secure form that sends data to a new internal API. The payload would include fields like title, description, and course”.
That kind of framing is something I’ve seen from product managers who have a technical background. And it makes sense, because they naturally think in terms of system architecture and endpoints.
While I do understand how some of these things work behind the scenes, and the years of experience in this area have made me understand more of the technical language, I am not a technical PM myself.
So here is how this sounds in a non-technical language. “Experts in our community want to offer courses, and other users are interested in joining. Right now, there’s no good way to surface these opportunities. I’m thinking we need a form for experts, some kind of review process, and a section on the dashboard where people can browse and register for sessions.”
That version communicates the same core idea, but it invites collaboration. It acknowledges the product direction while leaving space for technical insights.
You don’t need to speak in technical jargon, but you do need to show you’re thinking critically. When developers walk through a proposed approach or point out complexity, ask what’s making it complicated. Ask whether parts of it already exist elsewhere. Ask what would make it simpler or safer to deliver.
Even something as simple as “Is there a low effort version of this we could test first?” can spark a valuable conversation. Developers appreciate it when product managers show interest in their thinking and constraints. It signals partnership instead of handoff.
One common concern I hear from non-technical PMs is that they’re afraid of asking the wrong question. But the risk isn’t asking. The risk is not asking and letting assumptions drive decisions. Your questions don’t have to be perfect. They just need to come from a place of wanting to understand.
Build a Collaborative Dynamic
Developers work best when the problem is well defined. What’s frustrating is when the ask is vague, the requirements are constantly shifting, or the real user goal is unclear.
Talk about what users are trying to do. Where are they dropping off? What complaints are showing up repeatedly? The more grounded your problem statement is, the easier it becomes for the team to explore options.
At the same time, try not to lock the team into a single solution too early. You might have an idea in mind, but the best approach often comes from dialogue. If you’re clear about the outcome you want, and open about how you get there, you give developers room to build something better or faster than you originally imagined.
It’s perfectly normal not to follow everything in a technical discussion. What matters is what you do in that moment. If you don’t understand something, ask.
You can say something like “I’m not sure I followed the last part. Can you walk me through it again?” or “What would that mean from a user perspective?” Most developers won’t mind explaining things when they see that you’re engaged and trying to understand.
Stay Consistent, Communicate Clearly
A polished user story doesn’t guarantee shared understanding. Instead of focusing on formatting perfection, focus on clarity. Write stories that include the context behind the request. Why are we doing this? What problem are we solving? What should success look like? You can keep it simple with a few sentences and clear acceptance criteria.
Whenever possible, involve developers early in the process. Discuss user stories together. Review your draft collaboratively before it is picked up. Include space in the ticket for developer notes, dependencies, or suggestions that may not be obvious to you.
When stories feel co-owned, developers stop treating them as chores and start treating them as design problems.
One of the biggest frustrations developers express when working with product managers is inconsistency. A story gets assigned, and the PM disappears. Priorities shift, but the backlog isn’t updated. Feedback comes in late, after the work is already done.
Consistency builds trust. That doesn’t mean hovering or micromanaging, it just means staying close enough to catch issues early, communicate updates clearly, and celebrate progress.
If a developer flags a blocker, follow up on it. If the team delivers a tough feature, make it visible to stakeholders. If something launches, share the outcome even if the results are still early. Developers notice when their work is appreciated, and they notice when it isn’t.
Small, reliable habits make a big difference over time.
Learn What Matters
You don’t need to learn how to code. But learning some basic concepts can help you have better conversations, make smarter tradeoffs, and avoid unnecessary confusion.
For example, understanding the difference between back-end and front-end work helps you ask the right people the right questions. Knowing what an API is helps you follow discussions about integrations. Getting a sense of how your team handles releases can help you better time the announcements.
You don’t need a course to get started. Ask your team if you can sit in on a release. Read through a pull request together, even if you don’t understand every line. Look up a few terms next time something sounds unfamiliar.
Learning like this doesn’t just build fluency. It shows your team that you care about what they do and that kind of effort doesn’t go unnoticed.
Focus on Trust, Not Technical Skills
If you ask most developers what they want from a product manager, you’ll hear variations of the same themes.
- They want someone who provides clear context, not just what to build, but why it matters.
- They want someone who respects their time and work
- They want someone who can prioritize well, protect focus time, and make decisions based on real user needs
- They want someone who communicates openly, especially when things change
None of that requires being technical.
It requires being thoughtful, trustworthy, and committed to building the best product together.
If this feels like a new territory, you’re not alone. Many product managers start in this exact place. The good news is that collaboration is a skill, and like any skill, it gets better with practice.
Begin by staying curious and honest. Ask questions when you don’t understand something. Give developers space to come up with ideas and focus your stories on outcomes.
You’ll learn what works as you go. Your team will notice your efforts, and with time, your confidence will grow.
Final Thoughts
I’m not saying it’s not helpful to pick up some of the language developers use, it can help. But you don’t need to know how every part of your product is put together.
What really matters is learning how to work with the people who do, how to support them, ask the right questions, and build trust. That’s what makes the difference day to day.