A few thoughts on how product managers can work more effectively with designers

Some ideas from my experience working with designers

Good product flows from healthy collaboration between product managers and designers. This article presents some ways to enhance that relationship.

🎯 First define a clear, tangible problem

Every project should have a clear reason for its existence, yet it’s remarkable how many projects start because, ‘someone told us to do it’.

It’s critical to define the problem as precisely as you can. Do not overlook this part. It’s the foundation for any work, and ambiguous definitions can lead teams down endless rabbit holes when exploring solutions, leading to completely irrelevant designs for the goal you wanted.

Clear definitions provide constraints. Constraints are vital to implementing effective solutions because they narrow the potential problem space to what’s actually relevant. In other words, they provide necessary guard rails on the scope to keep the project focused.

As a general guideline, a problem definition should have the following elements:

Be as specific as possible — specific problems get solved with a specific solution. Broad problems lead to multiple suggested solutions, many of which could be irrelevant
Relevant to a clear customer problem and strategic business issue — the problem should be linked to your current strategy, otherwise why is the problem actually important to solve now?
Supported by relevant data (if available) — there should be some evidence to show why this problem is important and relevant. Otherwise, why work on it?

❌ Define what is NOT the problem

For the avoidance of doubt, you should also be clear on what a piece of work will not entail. It’s always tempting to combine solutions together, killing two birds with one stone (or whatever else you want to call it). But this often overcomplicates the process, produces muddled thinking and causes projects to overrun.

It’s fine to mention any related problems you could solve, but will place in an 'omit' section of a product requirements doc, so you remain focused on the most important problem you're solving right now.

I don't want to be too prescriptive here, so it's worth mentioning that there are some rare occasions where two problems can be solved together — either because one solution solves both, or because solving the problems incrementally leads to a fragmented, disjointed user experience. A seat isn't particularly useful alone if you're intending to make a chair, it probably needs legs too!

🥅 Define a clear goal

While it’s not your job to recommend a solution, you can help get there by outlining the goal(s) your solution should achieve.

Essentially, this means if you successfully implement a design solution, what can the customer and business now achieve?

I tend to break this into two parts:

Define the ideal customer experience end state. Customers can now perform 'X’. Customers have less friction doing 'Y'.
State the expected impact on business goals/metrics. This is especially important if you’re operating in a commercially-focused team. Example: based on the current state of the metric, we’d expect an 'X'% uplift within 'Y' days, compared to the baseline.

🚚 Be clear on the design deliverables

How should designers supply their solutions? In some cases, it may be defining a user flow diagram, in others, it may be an interactive prototype. But it’s important to state the work expected from your designer to ensure they don’t waste hours on a needless task.

📄 Provide any additional, relevant context

There may be additional business context that’s needed to apply relevant constraints to a solution.

It could be a critical business or legal requirement that needs to be accounted for, background on previous iterations of the project or specific requests from other departments that are affected by this work.

In the instance of iterating or updating legacy work, it would almost always be useful to add historical context around why and how certain decisions were made — this could impact both technical delivery and the design direction. At this stage it's always useful to account for technical considerations too, which brings us onto the next section...

📞 Create a kick-off call to run through the project and address any questions

Before commencing any project, it's worth bringing your team together to establish its requirements and scope.

The invite should extend to any relevant party, including engineers, analysts or product marketers. Depending on the size and type of the project you may want to include other stakeholders too, especially if it impacts their department. Representatives from marketing or finance teams are common.

Ideally, you'd share a product requirements document (PRD or equivalent) before the meeting to give everyone a chance to think about the details and potential complications. The document should clearly outline the problem you’re solving and provide any relevant context – this fosters a far more productive kick-off call and the engineers can flag any technical blockers that designers should account for.

You should also leave time for questions from the team — these should help clarify any uncertainties around the problem and proceed with designing an effective solution.

Bonus: any action points in this meeting should be reflected in the project documentation or PRD. You should update the solution based on the best ideas suggested, not be dogmatically wedded to your own!

💡 Let them solve the problem, but use your knowledge to push back when needed

Whilst it’s helpful for product managers to understand fundamental design principles, it’s not your job to solve the problem (I may have mentioned this before 😅). This is both belittling to designers and a waste of your time.

But some design knowledge does help during the iteration process, where you can provide relevant feedback to your designer to converge on a more optimal solution.

People get demoralised if feedback is constantly given as a negative critique. Critique is vital to improve the quality of a solution, but it should be given from a place of positive intent and applied to specific elements of the design, not a generic commentary around 'what needs improving'.

Getting this right not only improvs the relationship with your designer, but it makes them more comfortable asking for feedback on a regular basis, which becomes a prosperous cycle of development.

The worst possible outcome is for a designer to spend weeks on a solution and produce a high-fidelity prototype, only for the fundamental structure to be changed — this is both unproductive and disheartening for everyone.

🗣️ Support with user feedback when needed

In some cases, it may be difficult for designers to be confident in an effective solution without getting feedback from your customers. Typically, a more complex or ambiguous problem means lower confidence in the proposed solution.

In this case, you should support your designer by facilitating up calls with customers who are willing to help test prototypes or early-stage designs. If possible, it helps to keep a list of customers who’ve said they’re willing to help improve the product experience — if not, the business development or support teams tend to know the best customers to speak with, given they're interacting with them on a daily basis.

🔃 Adapt your approach to the seniority and skills of the designer

Senior designers tend to be more comfortable in ambiguity, usually because they’ve seen similar types of problems before and know where potential pitfalls and rabbit holes lie.

Conversely, junior designers tend to get bogged down in a maze of ideas. It’s your job to help them by being as specific as possible with your problem definition and feedback. These constraints help deliver more faster, more effective solutions, whilst reducing the stress of the team.

🔬 Simplify whenever possible

A tendency for some PMs (🖐️ guilty as charged in the past) is to over-intellectualise problems and converge on a solution that sounds smart, but in reality is needlessly complex for what you’re trying to achieve.

This feeds into a monolithic way of product development — let’s say you spend six months locked in a room with a team figuring out the ‘perfect’ solution… then you release it to market and literally nothing happens. Oops.

In the vast majority of cases, even if the project is complicated, you can deliver solutions incrementally, because the initial versions will still have a positive impact on the user experience. If something is really bad, fixing it sooner than later is far more valuable to your customers.

It’s your job to whittle the solution down to a minimum-effective version that can be released quickly and provide immediate value. This depends on the context of your business and resources of course, but as a general rubric I've found it massively helpful in the past.