Everything has a structure, thoughts on problem solving structure

# Structure in general

Almost everything in our daily life has structure 😲! Starting on the human body that consists of a specific skeleton structure to protect and support us, cars generally have 4 wheels as the standard structure to move well, programming languages have their own syntax structure, and many more. Having a structure will guide us to execute methodically and effectively, especially in high-pressure situations where sometimes it's not optimal to just rely on our instinct.

There were small-medium initiatives/problems in work and life that I solved just based on my instinct. After some iterations, there's a noticeable common pattern in problem-solving and execution. Using just instinct is actually ok, but having a structure would make it easier to document, distribute/share and extend the approach. Problem-solving structure is also useful in high-pressure situations to greatly reduce the chance of missing a step or two.

Nowadays, my default would be to try to structure everything, this applies in life not just in a work environment. I'm sharing what I currently have in mind regarding this, I hope this post can help you to structure executions and be more effective.

# Structure in Problem Solving

# Initial thoughts

We can set a structure for problem-solving approach, though it might differ for everyone because everyone has different problems with different patterns. Just for example, a simple problem-solving structure could look something like this:

1. Problem background, we need to understand the context and the problem first, and make sure it actually exists, this can be done by reading user feedback, looking at the data, etc.
2. Problem priority, the problem may exist but it's better if we evaluate whether it's worth it solving or not. After all, we already have many problems to solve right? If it's worth it then evaluate and set the problem priority. Typically we want to solve the higher priority problems first, starting with the easiest ones if there are problems with the same priorities.
3. Problem delegation, suppose we decide to solve it, do we have the capacity? Can it be delegated?
4. Plan for solution, is the problem quite common? Do we have existing solutions that we could use or should we formulate our own solution?
5. Execution, just get it done.
6. Monitoring, how do I know the problem is solved? Can we monitor the data?

# Decompose the problem

Unless it's straightforward, a problem typically can be decomposed into simpler subproblems. Those subproblems probably can be broken down again, the depth depends on how big the problem is and how would you balance it. Decomposing a problem makes it easier to delegate and find a specific solution to the subproblems. Try to find the balance, if it's too small then probably we'll end up spending unnecessary time breaking it down instead of actually solving the problem, if it's too big then the execution might be suboptimal due to overwhelming assignment.

What I find is, generally it's easier to break down problems based on the skillset required to solve them because it'll be easier to delegate to a team/people of a specific role.

# Attempts to apply structure on other cases

We're going to go through some examples outside of general problem-solving structure, we will try to apply structure to each case. I encourage you to try to make your own examples at the end.

# Example: Launching a new product

Suppose we have evaluated that it's worth it to launch a new software product (a problem worth solving), the assignment structure could be divided into:

• Product management -> assign to the Product team
• UI & flow component -> assign to UI/UX team
• Development component -> assign to the Engineering team
• Marketing component -> assign to the Marketing team

Each of the team could break down the assignment into multiple subproblems until we think it's quite optimal, the development team could divide development effort into:

• Backend Team
• Android Team
• iOS Team
• Engineering Infra Team, maybe we need to spin more servers.

Following up on the assignment structure, each team could have its own execution structure, it doesn't have to follow the same structure because the way to solve the subproblem could differ. Engineering teams typically use agile methodology meanwhile marketing might use other approaches.

# Example: Covering to lead a meeting

There's a product-themed meeting coming soon, but the lead product manager that's supposed to lead the meeting was on sick leave on that day. I was asked to help lead the meeting since the other person that knows the high-level details was only me, I was kind of nervous because I'm more accustomed to leading engineering-themed meetings.

Please note I'm not talking about meeting structure, we already have it and we can just follow the usual meeting structure, but my goal was to up my understanding and confidence level leading a product-themed meeting. Let's try to structure it:

• I think it's best to write down the meeting objectives first with our own sentences.
• Then break down what would be the key points/outline needed to be discussed to meet the objectives.
• Try to visualize how would the meeting run with the above key points.

# Example: Going for a vacation

I would like to have a vacation in Japan with my family, the top level structure to get to the goal would be:

• Vacation dates
• Itinerary
• Budget planning

Same with other problems, we can break each point into subproblems/checklists, vacation dates could be broken down into:

• Find out the date ranges with low workload so we can have vacations stress free
• Get buy-in from family
• Get annual leave approval

The itinerary is probably the easiest to delegate, if I don't have time I'll just reuse itineraries made by other people.

# Key takeaways

• Not every problem is worth solving, try to prioritize.
• When there’s a problem try to think about the problem structure first then break it down into subproblems until it's quite optimal, follow the structure and move towards the solution.
• If it's too much for you, always consider delegating the subproblems, especially the ones that can be run in parallel.
• Structure can be applied in many cases.