Series 2: Connecting the Dots - Part 2: Design
3 Tips and tricks for PMs to work more effectively with Designers
In the second interview for this series I caught up with my close friend Dima. He’s currently a Product Designer at Ziina, a UAE-based Fintech startup, as well as a Design Mentor and Consultant.
With 5+ years of experience as a Product Designer across multiple continents, industries, and sizes of companies, he has a keen sense for what makes a great product, and how to work with a team effectively to build one.
We talked about the challenges of working in a startup environment, the idiosyncrasies of doing business in the MENA region, the core skills he looks for in Product Designers, and more, but the main focus was on how PMs can collaborate better with Design teams, and I have tried to distill my three main takeaways in this post below…
1. Build a process to stay aligned with your Designers
Alignment is the cornerstone of effective collaboration between product managers and designers, and is really the running theme of this entire post. Both parties need to have a mutual understanding of the goals, constraints, and the ‘why’ of a project, in order to create a shared vision that guides the process from start to finish.
However, there are some challenges that can hinder this alignment, and if you fail to acknowledge and understand these as a PM, you’re in for a world of fun pain.
The most common alignment problem is around conflicting goals and motivations. Product Designers can often be self-described perfectionists, which can cause conflicts with PMs who are generally focussed on value/effort tradeoffs and what they perceive as ‘critical paths’. It is understandable why Designers are aiming for perfection - they have spent all their efforts to develop an optimal solution for the problem you have briefed to them! Moreover, Dima discussed the importance of a portfolio for Designers, and who’d want to showcase something that they aren’t happy with the execution of!
On a similar note, a second common alignment problem we discussed was around knowledge asymmetry. Often PMs have deeper context of a project than other stakeholders, including Design, as they sit ‘in the middle’ of the Venn diagram between the business, engineering and the customer. If the broader goals, internal politics, time sensitivity, other roadmap projects etc aren’t shared knowledge, PMs and Designers will likely find themselves butting-heads over scope and importance of different features.
Every company is different, and every project can be different too - as a PM, it is well worth the time to engage your Design (and Engineering!) peers to ensure you have a process that effectively facilitates alignment. You need enough touch-points to ensure alignment without micromanaging, effective methods and artefacts for documenting decisions, and a PRD/brief document that answers all of the important questions your Designers and Engineers need to know, or that influence how you’re thinking about this project.
None of these have to be overly complicated - you can do things like…
Using the MoSCoW method (Must have, Should have, Could have, Won't have) to clearly explain the priority of features/problems/JTBD in your brief/PRD
Implement a "Three Amigos" approach with regular meetings with the lead designer and lead engineer to discuss project goals and progress in depth
Make sure you are using communication channels/tools/methods that suit your teams’ needs.
The key is to find a process that works for your team and ensures all voices feel heard!
Dima highlighted that the relationship between PMs and Designers is highly correlated with the likelihood of a team’s success. Since so much of this relationship is based on ‘alignment’ (as this will reduce conflict) - measure this as a KPI by collecting regular feedback from your designer(s), and iterate on your process, methods and artefacts until you see this ‘KPI’ improve.
2. Let Designers own the feedback process
One of the major pain points in the Designer-PM working relationship can be around design feedback. We interact with digital products all day, every day, and if you care enough about them to be working in the industry, and you care about your product, you probably have an opinion on user experience. This is a great thing, but it can be a tough gig for a designer; it’s rare that non-technical stakeholders would critique an Engineering solution, but when it comes to design, everyone has thoughts, and they aren’t afraid to share them!
Dima highlighted two key ways to avoid feedback-related pain points:
Firstly, ensure the stakeholders involved in the feedback process are all aligned around all the key areas mentioned above; if they don’t deeply understand the nuances around the goals, time sensitivity etc of the project, the feedback isn’t likely to be particularly constructive, and it can frustrate all parties involved. As a PM, you should be owning the artefacts that can be used to align these stakeholders - and your PRD/brief, in particular, is your key defence against a HiPPO (“highest-paid person in the room’s opinion”) attack on your designers.
Secondly, Designers should own the feedback process. It's crucial to ensure that feedback is given at the right time, allowing designers enough opportunity to act on it, and that they get feedback from the right stakeholders.
Product Designers should ultimately be responsible for organising, facilitating, and managing how and when design feedback is done. Let them digest the outputs, and come to you when they’re ready to discuss next steps and re-align.
As a PM, you should play a supporting role to the Designer here - you (should) have artefacts like briefs and decision logs that can be distributed before the sessions, and the relationships with stakeholders to ensure they come prepared to have a productive meeting.
This approach fosters a more collaborative and efficient workflow, leading to better outcomes for the product and improved morale.
3. ‘Vision’ design work can be extremely valuable, if done with a measured approach
A final takeaway from this discussion was around how to manage ‘vision work’. By this, I am talking about, essentially, design R&D - time spent thinking about long-term, blue-sky vision. This kind of work is extremely valuable for design teams to be conducting - it can be a source of inspiration for new features and expedite future projects, level-up the skills of your designers, and as a PM, having illustrative mockups etc can be great ways to communicate your vision with stakeholders. It’s also, understandably, some of the most exciting and interesting type of work for many people!
However, it can also be a source of frustration between PMs and Designers - if outputs are misaligned with a PMs vision, these can be dangerous if shown to stakeholders - anchoring them in a particular solution, or distracting them from more important/pressing priorities. Moreover, PMs can sometimes feel like there are more pressing, near term projects that resource could be put towards instead, especially if they haven’t had a say in the R&D’s direction.
Dima provided a few top tips here, to help your designers take a measured approach to ‘vision work’:
Demonstrate you understand the value of the work by pitching these kind of projects into Design leadership - try to talk to them regularly about the ‘long term problems keeping you up at night’, helping to set the challenges/focus for future research
Make sure to break vision work into stages and set clear deadlines, to ensure that it doesn't get overshadowed by immediate product needs, and to keep you in the loop with outputs/direction
Help with scheduling: maybe you know a quiet sales period is coming up, or the Engineering team is going to need to focus on tech debt for a sprint or two - let the Designers know early, so they can use this time for a phase of a vision project
Once again, thanks Dima for the great chat and taking the time out of a busy day to share your wisdom! If you’re interested in getting in touch with him, check-out his website here - you won’t regret it! I’m sure we’ll be hearing more from him on this blog in the future too.
Next post will be coming in a few weeks- part 3: The Business