Collaboration

Being a Product Engineer isn't just about writing beautiful code or solving tricky technical problems. It's actually, like, mostly about people. And sometimes, if I'm being honest, that's the part I find the trickiest. I've spent years figuring out how to collaborate well, and I'm still learning. But there are a couple of things that have become totally crucial for me.

Working with the Team

It Starts with People (Duh, Right?)

Look, it sounds ridiculously obvious, doesn't it? "Personal care." Like, of course we should care about the people we work with. But in the daily grind, especially when deadlines are looming and bugs are popping up, it's so easy to forget that we're all just… humans. Humans who aren't going to be around forever, sharing this weird little slice of time together.

And honestly, when I think about the end of the road, I seriously doubt I'm going to be kicking myself for not shipping that one feature, or for losing an argument in a product review. What will matter, I think, are the relationships.

That's why I've come to believe that personal care is the absolute bedrock of working well with any team. Am I actually asking people how they're doing? Do I notice when someone's going through a rough patch? And am I being mindful of my words making sure my communication is clear and kind, not just efficient? Because words, man, they have the power to build up or tear down.

The single most effective thing I've found for building those real connections? Just… talking to people. Scheduling 1:1s, even with people who aren't your direct reports. Yeah, I know, more meetings. But these aren't your typical status updates. They're chances to just connect. Maybe grab lunch together, or take a walk in the afternoon if the office air is getting stuffy. Figure out what works for you and for them. Maybe block out Monday afternoons for relationship-building—whatever works! Because when you have genuine trust, everything else gets easier. Especially the next point...

Share Honest Opinions (Without Being a Jerk)

We've all seen that person at work. The one who just yells and bulldozes everyone. So it's easy to fall into the trap of thinking that being "nice" means never sharing anything critical. But that's actually the opposite of helpful. Kim Scott calls it "ruinous empathy" in her book Radical Candor. Imagine you see a teammate about to present a feature demo that's clearly buggy and confusing. Ruinous empathy would be saying nothing because you don't want to stress them out before the presentation. But the kinder thing, the caring thing, is to pull them aside and say, "Hey, I noticed a couple of things in the demo that might confuse people. Want to quickly walk through them before you present?" That's caring personally and challenging directly.

Learning to give honest feedback kindly has been a game-changer for me. And it's essential for building strong relationships and ultimately great products. Because when everyone feels safe to share their real perspective—product managers, designers, engineers—that's when you get all the angles on a problem. That's how you catch risks early and come up with solutions that are actually robust.

Who You're Working With

The Product Team Lineup

Okay, so who are these people we're collaborating with day in and day out? In a typical product team, you'll often see these roles:

• Product Manager (PM): Think of them as the product's north star, the vision holder. The PM is deeply accountable for the value and viability of the product. They deeply understand the users, the market, and the business strategy, and then define a product vision and strategy that truly solves user problems and drives business results. They say "no" to things that don't align with that vision. They are the voice of the customer and the business, constantly learning and adapting the product strategy based on new information. They don't just hand down requirements; they paint a picture of the desired outcome and context, empowering the team to figure out the best way to get there.
• Product Designer (PD): These are the user experience champions, so much more than just visual stylists. They are user advocates and experience architects. They're obsessed with how people actually interact with our product. They are responsible for the overall user experience—ensuring the product is not just functional, but also usable, accessible, and even delightful. They explore different design solutions, prototype and test ideas, and bring a deep understanding of human-centered design to the team. They don't just create mockups; they design holistic experiences that solve real user problems in elegant and intuitive ways.
• Product Engineer (PE): That's you (and me!). We're not just code implementers; we are the innovation engine and feasibility experts. If you have more than one engineer, you often have a Tech Lead. Think of the Tech Lead as the engineering architect. They take the high-level product vision and make sure the technical pieces fit together, that our engineering decisions are sound, and that we're building things in a consistent and scalable way. But Tech Leads are neither dictators nor superior to others—we should all share the responsibility of delivering great products. Tech Leads should help the other engineers see the big picture, and engineers should help Tech Leads consider the details. Making engineering decisions should be done collaboratively after weighing both high-level and low-level considerations.
• Other Roles: You might also work with Project Managers, QA, Data Scientists, SREs, and more. However, not every team can afford to have them, and there are plenty of great resources available on those roles. For now, we'll focus on the product trio.

Healthy Negotiation

Collaboration really shines when all these different roles bring their unique superpowers to the table and we figure out how to balance them.

What to Negotiate About

Here's what we're often "negotiating" (in a good, healthy way) about:

1. Urgency

Product Managers are usually driving the urgency. They're tuned into the market and the business pressures. But good Product Managers aren't dictators. They understand that deadlines are rarely set in stone. Even when timelines are tight, they work with the team to figure out the Minimum Viable Product (MVP)—or maybe even Minimum Lovable Product (MLP)—what's the smallest thing we can build that still delivers value?

Engineers play a key role here in estimation and shaping solutions. We need to explore different technical approaches, understand the trade-offs, and help the team make informed decisions about scope and timelines.

2. Usability

Designers are the guardians of user experience. They're constantly pushing for intuitive and delightful interactions. Engineers, naturally, often think about reliability and clean code. Sometimes, these perspectives can lead to different ideas about the exact implementation of a design.

As engineers, we should absolutely give constructive feedback on designs. We know how the underlying systems work and how different platforms behave. We can spot potential gaps, like, "Hey, this design only shows the happy path. What happens when the user is offline?" or "How will this work on a tablet in landscape mode?" We also know engineering best practices and can often suggest simpler ways to achieve a similar user experience.

Don't get hung up on pixel-perfection if it's not adding real value. I once worked on a project involving both iOS and Android apps, and initially, we had a single design for both. The contractor at the time faithfully recreated the iOS dialog design on the Android app, spending a significant amount of time on it. It could have been an easy task if they had simply asked whether we wanted to use the Android system dialog instead—which, of course, would have been an easy yes.

3. Maintainability

Product Engineers are responsible for delivering features with a maintainable structure. The word software is composed of “soft” and “ware.” “Ware” refers to a vessel or tool that can be used to achieve a goal such as adding new features. “Soft” indicates flexibility, unlike hardware, which is rigid. This flexibility means that software can be adapted or tweaked with a relatively small amount of effort. Advocating for a flexible codebase is a core responsibility of product engineers because no other roles will do it for you. By nature, Product Managers and Product Designers prioritize other concerns. The beauty of product development lies in the balance between conflicting priorities and their resolution.

Most of the time, we try to be helpful and nice. We try to deliver what we set out to achieve as a team. However, if we don't proactively speak up for the need for simpler solutions, we end up making the product full of technical debt. At that point, making any changes takes too much effort, ultimately not helping the team at all.

How to Negotiate

Here are some tips for negotiating effectively to reach a constructive outcome

1. Do Your Homework

Before you jump to "no" or "that's too hard," really try to understand the other perspective. When processing product requirements, don't just skim them and say "nope, impossible." Actually figure out how you could make it work. Explore different technical approaches. Even if you don't end up building everything exactly as initially envisioned, the act of trying will give you valuable insights and options. And those options are what you bring to the table for a real discussion. Show people what's possible, what the trade-offs are, and what the effort would be for different approaches.

2. Numbers Talk

When you're suggesting tweaks or simplifications, back it up with data and estimates. Say you see a design detail that's going to take a ton of extra engineering effort. Quantify it. "Hey designer, I love this animation, but implementing it exactly like this will take us an extra week. If we simplify it slightly, we can get 90% of the visual impact in just a couple of days. What do you think?" Without the numbers, designers (rightly) will advocate for the best user experience. But when you bring in the effort estimations, it changes the conversation. Suddenly, that "100%" design might not be worth the extra time and complexity.

Numbers are also crucial for defining MVPs and managing scope.

When shaping a new solution, start by dreaming big. Then, break down the features into smaller stories and estimate them. Based on business value, user value, and engineering effort, the team can prioritize and adjust the scope to meet realistic timelines.

Especially when projects are running late, cutting scope is often the only effective way to get back on track. Adding more engineers to a late project? The Mythical Man-Month taught us that's a recipe for disaster. Instead, ask: "Can this be a follow-up? What's truly essential for the first release?" You'd be surprised how many "must-haves" become "nice-to-haves" when you start talking numbers.

3. Boundaries

When collaborating, it’s important to consider concerns beyond your own expertise. Everyone can share insights on usability and user experience. Likewise, Product Managers can offer thoughtful engineering perspectives; some of the best PMs I’ve worked with have an uncanny knack for technical details. Still, boundaries matter. For example, it’s inappropriate for a Product Manager to insist on a specific programming language, like Objective-C, for iOS development, and engineers shouldn’t dictate precise design elements. Mutual respect fosters effective collaboration, just as it does in any successful team effort.

Conclusion

So, yes, being a Product Engineer is deeply about collaboration. It's about caring for the people you work with, being honest yet kind, and bringing your unique engineering perspective to the messy, but ultimately rewarding process of building something valuable together. And honestly, I think that's the real product we create: not just the software itself, but the way we build it, together.

Disclaimer: This post contains affiliate links. This means I may earn a commission should you chose to sign up for a program or make a purchase using my link.