My take on how to deal when someone tell you "build this like xxxx"


Sometimes, we do face a situation where your manager/supervisor/teammate instructs you to build a feature like xxx. Saying something like:

Our checkout flow is not the best, lets redesign our checkout flow like Spotify

Spotify's checkout flow is interesting, we should do something like this

Taking some time to think about this as I am able to relate to this, and this happens quite often for a product team I believe. Personally, I made some wrong decision, reflected and trying out different ways handle this situation better. Writing this to share my thoughts on how we can handle this situation better.

What I did before is digging into the experience, and getting excited that this experience is good. Then, further decide on more detailed user flows, stories, and last, implement them.

Will it works? Maybe? But I do think this is a risky move by blindly getting into the work without further questioning.

But why?

  1. Same experience/flow might not applicable for different product natures, user targets, etc.
  2. Doing it like xxx might not actually solve the problem (or even the problem does not exist)
  3. Doing it like xxx might not actually lead to the goal we want.

Therefore, there shall a better approach to deal with it to ensure we can deal with a better approach.

After more thoughts, I am thinking of a better way to approach this with three main steps:

  1. Dig deeper to understand the "why"
  2. Explore other ideas
  3. Share your ideas with them (alignment)

Dig deeper into the "why"

Usually, there is a problem, painpoint, or story behind his/her thoughts. They are expecting some outcome (eg. improved checkout flow, increase MAU, improve internal tooling process, etc) that could solve some problems, painpoints, and meet some goals they had.

Some example scenarios:

"Let's redesign our checkout flow to be something like xxx"

The reason behind this could be — the checkout flow completion rate is low, there are missing opportunities there.

"Build this feature like xxx, I think users will like it."

The reason behind this could be — due to the recent recession, no. of active users decreased which could affect the company's revenue, therefore, they are exploring "killer" features that could help them to regain active users.

"Can we add this feature like xxx for our internal tooling?"

The reason behind this could be — due to stakeholders finding the internal tool hard to use for this situation, they are inspired by the features from other tools that could potentially solve their problem.

Here are some example questions we can ask (or frame them better based on situations):

  1. What do you like about it?
  2. How is xxx doing better than us? (improvements features)
  3. Why do you have this idea in your mind? (new ideas)

Overall, what we need to do is discover what outcome or goal they aim for at first.

Explore ideas to achieve the goal

After we know what the goals they wanna achieve. We shall explore different ideas and solutions to achieve the goal.

Some questions we can ask ourselves

  • Is the solutions proposed the best solution?
  • Are there any ways to achieve it?
  • Among the solutions I explored — which one do I have the most confidence

In this stage, we shall explore solutions through users' journey, interviews, and also dig into the data. Basically doing more meaningful research to explore different solutions available.

So after you explore your solutions, also briefly think about how we gonna implement them. Will be great if we can slightly shape the solutions — so at least we have a good idea of how this solution gonna look like and foresee any future challenges.

Share your ideas with them!

Time to get back to them and share your research findings! It is important to check with them on whether it will solve their problem. As we are solving problems with them not only by ourselves. Therefore, aligning with them before implementation is important.

Reactions: 0 ❤️View on Github

No Comments Now