“Are you deprioritising design?”

As a product manager have you faced the question, “Why are you deprioritising design?” from your designers? If yes, then it is a symptom of a broken process. You are probably facing at least one of the below issues.

  1. Your product delivery value stream is not lean. There is a disconnect between the design and the execution.
  2. Your MVP is not delightful. This means your product is looking to be functional without being usable and delightful.

For the purpose of this blog, I want to look at the first issue as the second one is easier to deal once we handle the first.

The concepts of lean, customer-centric design and team collaboration have existed for decades now. However, I still see companies struggle to put them to practice. So, most of what I say is going to be well known from a theoretical standpoint. The theory suffers to give people tools to identify when practices are corroding the intent. I will take an example to drive my point here.

The ‘every product’ story

Eric and Evan are the founders of a startup which develops products to educate people in the field of psychology. Their latest in that list is an online quiz product. Jim is the product manager of the product and Joan is the product designer. Both Jim and Joan are avid practitioners of lean product management and customer-centric design. Who is going to argue against both those concepts? At least, Eric and Evan are not going to do that.

Through their research, Jim and Joan have validated the need for the product and tested the solution through their product. Eric and Evan were very happy with the designs they saw. The mockups had 4 screens.

  1. Signup
  2. Select a test
  3. Take the test
  4. View results and post them

The designs had fancy breadcrumbs which will help the customers navigate. Now, Joan’s role in the team was reduced to support the engineers with the designs needed. Jim, on the other hand, decides that the MVP is just a set of questions and answers on the same page. This will give him learning on framing of the questions and structuring. It eliminates all the features on the screens which don’t address this problem. It also merges the steps 3 and 4 given above. The team follows the best practices of agile software development to deliver a good working software.

Joan looks at the output at is not impressed. She feels her work has not been respected. It opens up a lot of disgruntlement. She goes to Jim and asks the million dollar question “why have you deprioritised design?”.

What happens next is called damage control in corporate terms. Eric and Evan are involved in discussions with Jim and Joan. After discussions, they will invariably reach one of the below conclusions.

  1. Joan will be asked to stay quiet and respect the role of PM.  Jim takes the call.
  2. Eric and Evan (as sponsors) will take a call balancing Jim and Joan wishes. They reach a settlement between Jim and Joan.
  3. Jim will be told that Joan has the full control of the design. From now onwards, Joan will be the gateway for design. The design will go through her review before it goes to the customer.

I have been Jim, interacted with Jims and Joans and have also seen the legacy of Jim and Joan in a company. Waterfall design using the customer-centric design techniques and agile delivery seems to be the latest amongst the smart-stupid mistakes in the product development space.

Does any of the above three points actually solve the issue? No, almost never.
Is it the fault of either Jim or Joan? No, it is a collective failure. From the individual vantage point, they might look right.

So, why did this happen and how to address this?

Mistakes made

Mistake #1: Why did we design those screens?

The first mistake made is to design those four screens. They solved multiple outcomes.

  1. The customer can take a quiz to see the result
  2. The customer can choose a quiz to take
  3. The customer can signup so that they can get the result over email
  4. The customer can post the result

Which is the most important point outcome to solve? If Jim’s answer to this is the first, then Joan and Jim should have collaborated to solve for just the first one. Once Joan has solved for all four and shared it, it is hard to take something out.

Mistake #2: Why did we move the designer to a support role?

The designer is an integral part of the team. By moving them to of the core product team, their role is reduced to support. This leaves them in the capacity of either a powerless contributor or a powerful gatekeeper. Either of these two is not collaborative.

Mistake #3: Why is the team not aligned on MVP?

The team is not aligned on the MVP. Assuming the first two mistakes have already happened, it is paramount to have got an alignment on the MVP and the resultant impact on the design. This means the designs reflect what needs to be done for MVP, the MVP is shared with the sponsor and validated with the customer.

Mistake #4: Why were the symptoms addressed instead of the cause?

None of the three proposed solutions has actually addressed the core issue in the process. Eric and Evan should have reflected on how they reached this stage and fix the cause instead of addressing the symptom.

Learnings

Here are my learnings from this approach.

Learning #1: Solve for one problem at a time

Identify the outcomes which have been validated, then prioritise the outcome which has to be solved. The prioritisation, though a product management function is best done as a team. The designer can solve for the prioritised outcome.

Learning #2: Easy to add features than remove

Even while solving for one problem, it is important to think if the features are important for achieving the customer outcome in question. It is always easy to add features later than removing something which has been done.

Learning #3: Design to a team is just as vital as development

The design is how the product helps achieve the customer outcome. So, the designer becomes a vital part of the team. It is always strange that even the team claiming to be extremely agile, always end up having designer outside or even outsourced.

Learning #4: There is no alternative to team alignment

Teams have to be aligned with the goal and the outcomes they are trying to achieve. If the three critical functions (product management, design and development) are not aligned, then the decisions are going to drive discontent and inefficiency.

Leave a comment