How to Be the Favorite Engineer Among Your Product Manager and Designer
#
Excerpt #
Collaboration is hard. Especially with product managers (PMs) and designers, it’s often a difficult balance of priorities. There’s usually a deadline, a relationship, and your project impact all at play. While the above image is for fun, it’s real for many engineers.
How to be the favorite engineer among your product manager and designer #
Collaboration is hard.
Especially with product managers (PMs) and designers, it’s often a difficult balance of priorities.
There’s usually a deadline, a relationship, and your project impact all at play.
[
Semi-serious meme for this issue 😅
While the above image is for fun, it’s real for many engineers.
This can be tough. But in this issue, you’ll get a ton of actionable advice on how to make the collaboration between you and your PM or designer so much easier.
How to overcome the 2 most common challenges when working with your designer or product manager
How to build a working relationship that makes you one of their favorite engineers to work with.
This is almost guaranteed in every project. It’s pretty darn hard to catch everything ahead of time. Surprisingly, there are so many ways to work through this effectively.
There are also a couple of things you definitely shouldn’t do:
What you shouldn’t do #
Push things off as a fast-follow, then never do them.
If you make this a habit, your product manager will notice it and will start wanting to force you to do it now, since they will lose trust.
Additionally, it never looks good if you don’t follow up on something you say you will do.
Saying no by default.
We’ll talk about ways to handle this effectively in “What you should do.” In short, don’t become known for saying “no.” Ideally, you can find effective alternatives and collaborate to an agreement both you and your product manager/designer are happy with.
Realize that “not technically feasible” isn’t a solid answer. Most things are technically feasible. It’s just about how much effort it will take. If your designer knows the fancy animation they’re asking for will take 2 weeks, they’ll probably be more willing to let it go.
What you should do #
Call out as much scope as possible ahead of time.
There are 2 things you can do at the project planning phase.
Be exhaustive in what is in scope. Mainly, error states and edge cases. These may be product or technical edge cases & limitations. This will ensure these cases are accounted for ahead of time, and not afterthoughts. As you consistently ask how edge cases and error states will be handled, over time your PM and designer will begin to cover them before you ask, which will also start the scope at a more appropriate place.
Include a section for what’s out of scope. Add as much as you can that isn’t in scope. When scope attempts to get added, you can reference back to the original document saying it was agreed to not have it in scope.
Early in the project, before doing your technical design document, do a spike. A spike is where you just go through the code and spend a day starting to implement the feature without polish. Mock out method implementations, database interactions, make the frontend look ugly, and see what you run into. You’ll likely find some old code you may need to touch or an edge case you didn’t think of. When you do, you can include that in the scope early on.
Find the root of their goal, and offer alternatives that can be done in less time.
Your product manager and designer won’t know all the quirks of the system, where the legacy code is, what’s hard to modify, etc. You do. Whenever a suggestion is made by your PM or designer, try to figure out what the underlying goal is and offer an alternative that’s easier.
For example: I worked on a team where we wanted to show a pop-up modal to advertise a new feature on a dashboard. We could do this, but due to the existing infrastructure, it would have taken 2-3 weeks. However, I knew the main goal was to raise awareness for the feature. I shared that we could do the same modal, but on a different dashboard (it had a lot newer code) and it would only take a few days. Voila! They loved the idea, it saved scope, and still got us the same awareness for the feature. Similarly, I could have suggested other ideas like a banner or email.
(Quick shoutout to Gregor Ojstersek—CTO for also sharing this)
Align on a top-level metric.
Take a step back and consider what the goal of the project is. Is it dollars generated? Is it time saved for the user? If the scope-add is not adding toward the top-level metric, politely address that.
For example: “This is a good idea. It just may make sense to do this as part of a separate project.” If they ask why or push further: _“I’m a bit worried about us being able to meet the deadline on the eng side. Also, while I think it’s a great idea, I don’t know if it will move the needle on the user time-saved goal we wanted.”_Another way to explain it is, “I’m a bit worried about having our focus split trying to achieve this and the initial set of tasks. We can do both, I just like the idea of having it treated separately for now.”
The wording can definitely get tricky here, as you don’t want to sound too rigid, so take my sample wording as just a general idea. Usually use this as a last resort. The **ideal is finding an alternative or removing scope ahead of time.
**(By the way, feel free to share alternative wordings in the comments)
Accept the scope, but add people or time.
[
Time vs People vs Scope
Above is a helpful diagram (I forget the source—sorry).
Sometimes, the right move is to add scope, especially if it aligns well with the goal of the project. If this is the case, try to get more resources or time.
For example: _“This definitely makes sense to do. It just may take a bit of time. I’m thinking it could be 1-2 weeks. So if we add this in, we should adjust the deadline. Alternatively, maybe we could loop someone in to help reduce the load so we can meet the existing deadline?”_Understand that they are just trying to make the product better like you are. It’s just a matter of deciding on prioritization and scope. Try to think of it from their perspective. This aligns with Paulo Andre’s (former VP Eng) advice here.
We’ve all been there. We may be blocked, waiting on updated designs, or waiting to hear back on how to handle a particular edge case.
What you should do:
Take the initiative
One thing designers and PMs love the most is when you can take work off their plate in a respectful way. I usually do this by making a suggestion and asking if that aligns with what they were thinking.
For example: Sometimes during implementation, I realize there’s a case we hadn’t accounted for. I think about how to approach it, do it, then ping them checking if that approach works for them. 90% of the time, they say, “That works great! Thanks so much for tackling that.”
Set up 1:1s and share feedback regularly
If the response time is often slowing you down, it’s important to bring it up and have a place to address it. I suggest having a bi-weekly 1:1 with your designer and product manager to keep a close working bond. In the 1:1 you can catch up on a personal level but also exchange feedback regularly. Also, the 1:1 can be a good place to get unblocked too! It’s dedicated collaboration time if you need it.
For example: I usually ask, “Is there anything I should be doing differently or anything that is slowing you down? How did you feel X project went? Was there anything I could have done better?” Usually, asking for feedback opens the other person to ask for some too. There, you can share that the slow response times have been a blocker at times.
For even more detailed guidance, check out my article on how to handle being blocked (paid post).
Finally, I “interviewed” my girlfriend, who is a Senior Product Designer and asked,
“What did the engineers you enjoyed working with most do that others didn’t?”
Here was her answer:
They kept her up to date with progress.
- To do this, regularly show your work-in-progress to get fast feedback. For me, this made a huge difference in building a strong relationship with my designers. It shows them you value their opinion. Omar Halabieh, Tech Director at Amazon also agreed on this point.
They were willing to go the extra mile.
- They didn’t automatically reject an additional UI polish because it was out of scope. If it made sense and was reasonable to do, they tackled it. Or they said something like, “That’s an awesome addition. I’m a bit behind right now on trying to meet the deadline but I’ll try to fit this in if I can. I’ll keep you updated on it.”
They let her be the first one to test the feature (alongside the product manager).
Often as engineers, we believe we’re the ones entirely responsible for the feature. In reality, we’re mostly responsible for “it not breaking.” Your designer and product manager are judged by how it looks and feels; so it’s important they have a chance to verify it since they are held accountable.
A way to really mess this up is to ship to production without letting your designer double-check it. I’ve seen cases where designers were held accountable for features they knew nothing about 😬.
When your PM or designer suggests additional scope…
Minimize the problem by calling out as much scope as possible ahead of time.
Find the root of their goal, and offer alternatives that can be done in less time.
Align on a top-level metric. Use it as a reason for if it should be included.
Accept the scope, but add people or time.
When your PM or designer is slow to respond…
Take the initiative - Take a best-guess approach and check if it works for them.
Set up 1:1s and share feedback regularly - Share where each of you are slowed down. Make it mutual.
General tips for building a good relationship…
Regularly share work-in-progress and get feedback.
Go the extra mile when it makes sense. Do the additional polish.
Ensure your designer & PM can test the feature before going to production.
As always, thank you for reading.
- Jordan
P.S. You can reply to this email; it will get to me, and I will read it even if I can’t always reply in a timely manner.
Did you find this issue valuable? If so, there are two ways you can help:
You can also hit the like ❤️ button at the bottom of this email to help support me. It really helps!
Create your profile #
Only paid subscribers can comment on this post #
Check your email #
For your security, we need to re-authenticate you.
Click the link we sent to , or click here to sign in.