Photo by Jens Lelie on Unsplash

I was not born with decision-making skills

--

but I learned it

After a few years in the IT industry, I found myself in a position where I was making lots of decisions every day.

In the first few months, I spent hours on each and every decision. I would go into google search frenzy mode to find a way to make the best decision. While other times I was not confident to make a call now VS continue gathering more evidence. These practices were

  1. Inefficient and ineffective
  2. A blocker for taking action
  3. Making me lose my confidence

After 3 months, I retrospected my past decisions and realized that there is no single best way to make decisions. Environment, nature of the project, available resources and time, plays a huge part. That was the time when I came across design thinking.

What is Design Thinking?

Understand users, challenge assumptions, redefine problems and create innovative solutions to prototype and test.

I implemented it in my day-to-day thinking process. It helped me

  1. To break down complex problems and helped to gain a better understanding
  2. The iterative approach to problem-solving encouraged me to verify and validate my assumptions and expand my knowledge continuously
  3. Generate innovative solutions that actually solved the problem

As time passed, I took inspiration from design thinking and created my own approach to solving problems. I named this framework Scodmii

Scope the problem

Define the success criteria

Map out assumptions and risks

Implement

Iterate

ScoDMII decision-making framework

The 5 steps of the framework are:

  1. Scope the problem
  2. Define the success criteria
  3. Map out assumptions and risks
  4. Implement
  5. Iterate

TLDR; Scroll to the last section of the article to look at the few problems that ScoDMII helped to solve

1. Scope the problem

Having a clear destination is an essential part of any journey. This is why you should be crystal clear on what you want to achieve.

Questions to help scope the problem:

  1. What is the goal you want to achieve?
  2. What is the problem you want to solve?
  3. What is the outcome you want to have?

Tip: Try to solve one problem at a time instead of clubbing the issues.

Frameworks to guide you define your problem statement:

  1. 5 whys analysis
  2. Means end analysis

If you want to do a sense check of the problem scope and if is it worth solving, ask another question

  1. What is the impact on users and company?

Frameworks to understand the impact;

2. Define the success criteria

Defining the success criteria will help you judge the project completion, success and outcome. While defining the success criteria, you can also include the metrics that should not be negatively impacted.

Questions to help define the success criteria:

  1. What are the indicators that I have achieved my goal?
  2. What are the queries that if resolved will indicate that I am on the right track?
  3. What user actions indicate that they are happy or satisfied?
  4. What are the indicators that will tell me that I should not spend more effort on this problem, stop and reflect back?
  5. What do I want to learn about user behaviour?

Frameworks to guide you define your success criteria:

Here are a few examples of measurable success criteria:

  1. Users can now find discounted products easily. Checking out time for these discounted have decreased from x mints to y mints and discounted product sales have increased by 3%.
  2. Impact of change in sign-up button UI — Changing the button colour increased the signup rate from x% to y%.
  3. Increase the quality of code to reduce regression bugs by 50%.
  4. Automate the testing process to reduce the manual testing effort from 4 hours to 1 hour
  5. No of users interested in tutorial guide. 75% of users went through the app tutorial guide

3. Map out assumptions and risks

The next step is to identify all the ambiguities that need to be clarified. It may seem an easy step but I think it's the most challenging step. Because sometimes our strong belief stops us to challenge “the statement is a fact or an assumption, unintentionally”.

What you consider an actual fact might just be an assumption…

Questions to help identify ambiguities:

  1. What could be the impact on the main user flow or revenue flow or business logic because of the component we are updating?
  2. What assumptions must be true in order for you to increase confidence?
  3. What factors could derail the project or block us?
  4. What are the known or accepted risk that could impact us?
  5. Do I have evidence of my statement?

Frameworks to help identify ambiguities:

4. Implement

Now the next step is to prioritize and start implementing them.

Tip: How do I make a decision that it's time to start implementation or keep gathering information?
Once I have identified the must-have, critical risks and/or prerequisite, I take it as a sign of
‘bias towards implementation’ instead of keep gathering evidence and not practically implementing it.

Prioritization is also essential in this phase to make sure blockers and critical scenarios are prioritized and agreed upon across teams and departments.

Questions to help in implementation:

  1. What are the blockers and how they can be resolved?
  2. What are the cross teams and departments that I needed to collaborate and what are their priorities?
  3. Does the team have all the required resources to do their job?
  4. Who are the stakeholders that need to be informed and consulted during the project?
  5. How does all this work fit into the company’s and team’s product strategy?

Frameworks to guide implementation:

5. Iterate

This step is dependent on how you plan the deliverables. which can be in the form of sprints, milestones, quarterly objectives or in between product discovery.

Questions to ask :

Whatever the form of delivery, you need to reflect on the journey and make the decision to

  1. Kick off the next phase, OR
  2. Stop and learn from the outcomes, OR
  3. Reiterate all or any of the above steps

because the environment is constantly changing.

Frameworks to guide you on the next iteration:

For the past 4 years, I have used this framework in my day-to-day decisions in different projects to solve problems like

💡The changes need to be done on the legacy component.

Problems:
❌ No one has touched this part of the code for the past 4 years.
❌ No documentation.
⚠️ There is an unknown risk to the business logic and user flows

💡The architecture decision to slice the development of a component.

Problems:
⚠️ The component is complicated and has huge scope.
🛑 Part of development depends on other teams and departments on which you don’t have any direct influence or authority

💡Implementing a complex Business logic

Problem:
⚠️ Risks impacting the main user flow and revenue

As I mentioned at the start, there is no one-step magic solution to help in making all types of decisions. But the ScoDMII mental model has helped me a lot and I hope it helps you in making decisions as well.

For suggestions and feedback, please feel free to comment or contact me at my email nidasaleem333@gmail.com.

--

--