Should Product Managers design?
A recent post , where I suggested that PM mockups are counter-productive, triggered a debate amongst folks on either side of the argument. I realized that this needed a deeper conversation on what should be the Product Manager’s role in the design process.?
In this blog, I would like to use the double diamond design process to answer this question. If you are familiar with this framework, please skip ahead to the last section.
The Double Diamond design process
Design process is the systematic approach to tackling a problem. The typical steps of a design process consist of the following:
Identifying the problem -> Identifying the solution -> Building and releasing the solution -> Measuring impact
In my experience, I have found the Double Diamond design process the most helpful in dealing with ambiguous problem areas. This framework was first introduced by the Design Council in 2004 and has been widely used by various kinds of organizations.
The two key elements of this design process are:
Discover
The objective of the discovery stage is to comprehensively understand the problem or opportunity.?Team members in this stage try to uncover different aspects of the user’s problems through primary and secondary research.
The team members need to think broadly (divergent thinking) without limiting their options.
Define
The objective of the define stage is to synthesize learning from the discovery stage and articulate the problem/opportunity that the team would like to focus on.?
In this stage, team members need to evaluate all the different problem areas identified in the previous step and narrow them down to specific problem statements. It’s really important to ensure that the problem is not defined based on a solution. (For example “The user has a headache” is the right problem statement. “The user needs an aspirin” is not.)?
The team needs to exercise convergent thinking to eliminate distractions and focus on specific problems.?
Develop
The objective of the developing stage is to generate as many numbers of solution ideas as possible and test these ideas (prototypes) with end-users and also check the viability of these ideas.
In this stage, the team members build prototypes and do research with the users to identify their preferences. They also evaluate the viability of building each of these solutions at scale.?
Like discovery stage, the team members need to think broadly (divergent thinking).?
Deliver
The objective of this stage is to narrow down the solutions identified in the development stage and articulate the solution that the team builds. This stage can also include the building of the solution.
Teams in this stage evaluate the inputs received from user testing and the effort it needs to build a solution and arrive at the one solution that they end up building.
Like the define stage, the team needs to exercise convergent thinking to eliminate distraction and focus on arriving at a specific solution.
领英推荐
All this sounds great, but what does this tell us about mocks created by PMs??
The problem with PM Mock-ups
When a PM creates a mockup to drive towards a solution, they inadvertently end up clubbing the first three steps of good product development and directly land at the start of the delivery phase. This uses the solution as a way to explain the user problem, inherently biasing everyone to the preferred approach.
This leads to limiting the role of a designer by intentionally or unintentionally biasing/forcing the designer’s solution. This approach results in a shallow understanding of user need by settling on a ‘good enough’ solution which has less likelihood of success.
BTW, here is a really well-written Twitter thread by John Cutler which introduces the concept of “Mandate Levels” and how PMs, designers, and developers should think about their collaboration.
What’s a better model of engagement?
A balanced approach across all functions with PMs taking the lead on the first part of the diamond and designers taking the lead on the second part.
This should happen in conjunction with the engineering team actively involved and participating in all these phases
Key objections
A lot of you shared very valid objections/comments on the post and I would like to address a few of them.
1. We use mockups to spark a conversation or share ideas with the leadership team.
Using mockups to aid your conversation might help as long as you are aware of the following:
2. We don’t have enough designers on our team and need PMs to design
PMs can help out in case there are no designers on the team. But you should ensure the following:
3. An elaborate design process is slow and not agile enough for a startup
Every organization should find the pace and process that works best for them. It might be a good idea to deliberately think of the time that you and your team are willing to spend on each step of the process. Skipping steps altogether, without good reason, does more harm than good.?
Coming back to the title of this blog post - Should Product Managers design?
If you have a narrow interpretation of the word ‘design’ to imply mockups, then I would recommend that PMs should not design.?
However, design is so much more than just making mockups, and PMs should definitely engage with their designers throughout the process.?
Product Lead | Mentoring Lifelong Problem Solvers in Product Strategy and Discovery
1 年Really interesting reflections here, what about co-creation of wireframes with a designer? It’s a really cool activity to make together, you can brainstormnsolutions together and thennthe designer can create an approach based on that exercise. I would also recommend continuous feedback loops on the process of creation instead of waiting to have a complete design.
?? Ecosystem Growth. Building Cardano, the world's largest DAO. Scaling human interoperability in Web3. Building decentralized networks through community governance.
1 年CC Matthew Capps Tim Harrison
Collaborative Problem Solver | Empathetic Leader & Customer Advocate | Awesome Dad | All Things Product
2 年Great write up!!!
Product @ Ring | Ex-Airtel, EY, PwC | IIM Ahmedabad | CA
2 年Very well explained Sushant Koshy