From chaos to clarity
Design thinking
Chaos is everywhere in the tech industry, especially for creative and innovative work. When a problem comes, it is always ambiguous and large. How do you find the actual need in the problem and maximize the value?
Given that you don’t know whether your idea is right or not. In a large problem, should you focus on a small part or target the whole problem in one go?
My choice is to focus on a small part at first and iterate it to validate the idea. You never know whether your idea will work or not without validating it. By focusing on a small part, we can keep the idea simple and keep iterating the idea to create the best solution for the problem.
To maximize the value, you need to know whether you are solving the right problem. With experiments, you will make the ambiguous idea clear and create the best value.
Personally, I will focus on the following 3 parts when I get a problem.
Understand the problem
Before designing a solution, we need to understand the problem first. Sometimes, when the product manager gives you a requirement, it is not concrete enough. Engineers even didn’t know whether it is actual user needs and what problem they are solving. To solve a problem, you need to know what is the problem. Working with a product manager, we need to learn how to ask questions. By asking the right questions, we will catch the nature of the problem.
Also, we can narrow down the problem and filter out unnecessary requirements. Using this approach, we can fill the gap between tech and product and it helps the tech team to create the right solution for the right problem.
If you don’t ask questions, sometimes you can’t understand the correct requirement from the product team and the product manager does not know the concerns of the tech team. Running this approach between tech and product, both parties might not know each other’s concerns. For example, the tech team does not know the value of the product, and the product team does not understand the architecture limitation of tech. They are both executing commands without knowing the current foundation of the product no matter from tech or product.
Define scope
After we know the problem, we need to define a reasonable scope for the requirement because the problem might be large. The big scope will create a big problem because there are a lot of uncertainties and it is hard to control the quality, timeline, and efficiency. If we start working on the solution without breaking down the problem into small scopes, it might cause an uncontrollable timeline and incorrect user needs. Working on a solution, we might have unknowns/accidents that need to be solved during the development phase. If the scope is super big, it is hard to measure the workload and timeline.
Also, working on a big scope will delay the time that the work actually goes live. We never know whether our product is good or not without letting real users use the product.
Everything is just imagination before the work goes live.
To validate our idea, we should break down the problem and validate the idea one by one in production. So, breaking down a problem into different subproblems is super important when building a product. By validating our work, the direction will become clear and we can know how many values we created from our work more importantly we know whether our work is actual user need or not.
Iterate the solution
Iterating the solution is super important since we broke down the problem into subproblems. We can roll out our solution to production and get feedback from real users to see if we can improve our solution.
Also, if there are any issues in production, we can correct them more quickly. By iterating the solution, it can also give us to control the issue that might have in production because the scope is small. That said, we can better control the impact on production and validate our architecture on production.
When we get a problem in production, we iterate the solution.
By using this approach, the architecture/solution will get better and better and also we don’t need to deal with a lot of unknowns at the same time.
This can also lead to a better MVP solution and better utilize team resources.
To wrap up, never dive into a problem without asking questions to understand the nature of the problem and its scope. Instead of dealing with a large problem, try to break it down into different subproblems and iterate your solution to validate your idea.