Product designers and product managers working together

I’ve been a product manager and a product designer, and sometimes both at once.

Because of this I’ve had the privilege of looking at the role from multiple angles and seeing where it helps and where friction can cause problems.

Some companies eschew the role of product manager and leave it up to the designers and engineers to figure it out while the primary stakeholders support where they can.

Other companies setup teams with a product manager, designer, and engineers to work together against set goals of the team at large.

Again I’ve done both and seen the benefits and challenges in each area.

Adding a product manager to the team requires an extra body, but it also can point the projects in the right direction and save time in the long run while helping everyone maintain focus.

So, with that said, here are the team structures that I’ve seen work and that I appreciate working in the most.

Designers + Engineers + Stakeholders

A designer, alongside several engineers, works on features and pushes projects forward against metrics they’ve decided or assigned to them by the company. They sync up with the head of product, or equivalent role, and regularly checkin on progress against company goals.

This can work well if the team is given full autonomy within a predefined scope. That may sound like an oxymoron, but I’ve seen it work really well, and read a whole book on just this method.

The challenge with this is the team needs to be good. They need to understand the goals of the company, and they need a checked-in leadership who will ensure that the predefined scope is solid.

I’ve been on some projects with no autonomy and no predefined scope, and they were doomed to fail from the beginning.

This works best if design and engineering aren’t siloed, work very well in concert, and if the designer either understands frontend code well, or is a coder themselves.

Also, it works best if the designer specifically is comfortable with collaborating with engineering before the design is fully baked. On the engineer side it works best if they want to dive into the details as well and help shape the product.

Without those specific skillsets things can quickly devolve into designers and engineers chucking requirements over proverbial walls and quickly pointing fingers the moment the project goes south.

Projects like this tend to be scrappy, and can bring the greatest level of joy to the team when they go right. They should go on too long though. Limit your projects to less than two months, and force the team to move onto new things after that.

I’ve seen multi-month (or year) projects go south and heads role as a result.

Product managers + designers and engineers

This is the more typical route that I’ve seen startups go.

The product manager works with the rest of the team to define the project roadmap, and works with stakeholders to ensure the features line up with company goals. This person is a bit of a liason, and helps keep the team from getting distracted on things outside of what they are planning to tackle.

This works well if the product manager is data focused, and understands what engineers and designers go through daily (but doesn’t need to have been either of those). It works less well if they come from those backgrounds and try to keep pushing code or creating designs.

I’ve worked with product managers who are trying to do all three, and end up limiting autonomy for the engineers and designers.

That’s not to say the product manager couldn’t code or design, but they need to have clear handoff points where they can trust the rest of the team to own their parts. Actually.. I’ve rarely seen that work. It’s hard for a product manager from those backgrounds to truly let go.

Projects setup like this, with a good product manager in place, can be such a joy to work on. The engineers and designer connect regularly with the product manager, and help shape and vote on where features go. They all understand that the product manager ultimately is responsible, but will rarely call veto power. Done well they are all peers and helping to define and shape the product, each feeling ownership and autonomy on the tasks they tackle.

The biggest risk here can be when each team member feels too disconnected, and works on things not in alingment with the rest. Regular checkins can help, but there should be enough time for thinking and working in quiet.

This is the type of team I’m currently on, and I’m having a lot of fun with it.